Difference between revisions of "Reusing a nonce, key pair in encryption"

From OWASP
Jump to: navigation, search
 
(6 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
+
{{Template:Vulnerability}}
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
  
==Overview==
+
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
Nonces should be used for the present occasion and only once.
+
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
==Consequences ==
 
  
* Authentication: Potentially a replay attack, in which an attacker could send the same data twice, could be crafted if nonces are allowed to be reused. This could allow a user to send a message which masquerades as a valid message from a valid user.  
+
==Description==
 +
Nonces should be used for the present occasion and only once.
  
==Exposure period ==
+
'''Consequences'''
  
* Design: Mitigating technologies such as safe string libraries and container abstractions could be introduced.
+
* Authentication: Potentially a replay attack, in which an attacker could send the same data twice, could be crafted if nonces are allowed to be reused. This could allow a user to send a message which masquerades as a valid message from a valid user.  
  
* Implementation: Many traditional techniques can be used to create a new nonce from different sources.
+
'''Exposure period'''
  
* Implementation: Reusing nonces nullifies the use of nonces.
+
* Design: Mitigating technologies such as safe string libraries and container abstractions could be introduced.
 +
* Implementation: Many traditional techniques can be used to create a new nonce from different sources.
 +
* Implementation: Reusing nonces nullifies the use of nonces.
  
==Platform ==
+
'''Platform'''
  
* Languages: Any
+
* Languages: Any
 +
* Operating platforms: Any
  
* Operating platforms: Any
+
'''Required resources'''
 
+
==Required resources ==
+
  
 
Any
 
Any
  
==Severity ==
+
'''Severity'''
  
 
High
 
High
  
==Likelihood   of exploit ==
+
'''Likelihood of exploit'''
  
 
High
 
High
  
==Avoidance and mitigation ==
+
Nonces, are often bundled with a key in a communication exchange to produce a new session key for each exchange.
  
* Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
 
  
* Implementation: Refuse to reuse nonce values.
+
==Risk Factors==
  
* Implementation: Use techniques such as requiring incrementing, time based and/or challenge response to assure uniqueness of nonces.
+
TBD
  
==Discussion ==
+
==Examples==
 
+
Nonces, are often bundled with a key in a communication exchange to produce a new session key for each exchange.
+
 
+
==Examples ==
+
  
 
In C/C++:
 
In C/C++:
Line 93: Line 89:
 
</pre>
 
</pre>
  
==Related problems ==
 
  
Not available.
+
==Related [[Attacks]]==
  
==Categories ==
+
* [[Attack 1]]
 +
* [[Attack 2]]
  
[[Category:Vulnerability]]
 
  
[[Category:Protocol Errors]]
+
==Related [[Vulnerabilities]]==
 +
 
 +
* [[Vulnerability 1]]
 +
* [[Vulnerabiltiy 2]]
 +
 
 +
==Related [[Controls]]==
 +
 
 +
* Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
 +
* Implementation: Refuse to reuse nonce values.
 +
* Implementation: Use techniques such as requiring incrementing, time based and/or challenge response to assure uniqueness of nonces.
 +
 
 +
 
 +
==Related [[Technical Impacts]]==
 +
 
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 
 +
 
 +
==References==
 +
 
 +
TBD
 +
 
 +
 
 +
__NOTOC__
 +
 
 +
 
 +
[[Category:OWASP ASDR Project]]
 +
[[Category:Vulnerability]]
 +
[[Category:Cryptographic Vulnerability]]
 +
[[Category:OWASP_CLASP_Project]]

Latest revision as of 10:43, 28 February 2009

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.



Last revision (mm/dd/yy): 02/28/2009

Vulnerabilities Table of Contents


Description

Nonces should be used for the present occasion and only once.

Consequences

  • Authentication: Potentially a replay attack, in which an attacker could send the same data twice, could be crafted if nonces are allowed to be reused. This could allow a user to send a message which masquerades as a valid message from a valid user.

Exposure period

  • Design: Mitigating technologies such as safe string libraries and container abstractions could be introduced.
  • Implementation: Many traditional techniques can be used to create a new nonce from different sources.
  • Implementation: Reusing nonces nullifies the use of nonces.

Platform

  • Languages: Any
  • Operating platforms: Any

Required resources

Any

Severity

High

Likelihood of exploit

High

Nonces, are often bundled with a key in a communication exchange to produce a new session key for each exchange.


Risk Factors

TBD

Examples

In C/C++:

#include <openssl/sha.h>
#include <stdio.h>
#include <string.h>
#include <memory.h>

int main(){
  char *paragraph = NULL;
  char *data = NULL;
  char *nonce = "bad";
  char *password = "secret";
  
  parsize=strlen(nonce)+strlen(password);
  paragraph=(char*)malloc(para_size);	
  strncpy(paragraph,nonce,strlen(nonce));
  strcpy(paragraph,password,strlen(password));
  
  data=(unsigned char*)malloc(20);
  SHA1((const unsigned char*)paragraph,parsize,(unsigned char*)data);

  free(paragraph);
  free(data);
//Do something with data//
  return 0;
}

In Java:

String command = new String("some command to execute")
MessageDigest nonce = MessageDigest.getInstance("SHA");
nonce.update(String.valueOf("bad nonce");
byte[] nonce = nonce.digest();

MessageDigest password = MessageDigest.getInstance("SHA");
password.update(nonce + "secretPassword");
byte[] digest = password.digest();
//do somethign with digest//


Related Attacks


Related Vulnerabilities

Related Controls

  • Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
  • Implementation: Refuse to reuse nonce values.
  • Implementation: Use techniques such as requiring incrementing, time based and/or challenge response to assure uniqueness of nonces.


Related Technical Impacts


References

TBD