This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Insecure Randomness"
Weilin Zhong (talk | contribs) |
|||
| Line 2: | Line 2: | ||
{{Template:Fortify}} | {{Template:Fortify}} | ||
| − | + | [[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]] | |
| + | |||
| + | Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' | ||
| + | |||
| + | [[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]] | ||
| + | |||
| + | [[ASDR Table of Contents]] | ||
| + | __TOC__ | ||
| − | |||
==Description== | ==Description== | ||
| + | |||
| + | Standard pseudo-random number generators cannot withstand cryptographic attacks. | ||
Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in security-sensitive context. | Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in security-sensitive context. | ||
| Line 14: | Line 22: | ||
There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and forms an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between it and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts. | There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and forms an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between it and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts. | ||
| − | ==Examples == | + | ==Risk Factors== |
| + | |||
| + | TBD | ||
| + | |||
| + | ==Examples== | ||
The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase. | The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase. | ||
| Line 28: | Line 40: | ||
This code uses the Random.nextInt() function to generate "unique" identifiers for the receipt pages it generates. Because Random.nextInt() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG. | This code uses the Random.nextInt() function to generate "unique" identifiers for the receipt pages it generates. Because Random.nextInt() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG. | ||
| − | |||
| − | ==Related Attacks== | + | ==Related [[Attacks]]== |
| + | |||
| + | * [[Attack 1]] | ||
| + | * [[Attack 2]] | ||
| + | |||
| + | |||
| + | ==Related [[Vulnerabilities]]== | ||
| + | |||
| + | * [[Vulnerability 1]] | ||
| + | * [[Vulnerabiltiy 2]] | ||
| + | |||
| + | |||
| + | ==Related [[Controls]]== | ||
| + | |||
| + | * [[Random Number Generator]] | ||
| + | * [[:Category:Cryptography]] | ||
| + | |||
| + | |||
| + | ==Related [[Technical Impacts]]== | ||
| + | |||
| + | * [[Technical Impact 1]] | ||
| + | * [[Technical Impact 2]] | ||
| + | |||
| + | |||
| + | ==References== | ||
| + | TBD | ||
| + | |||
| + | [[Category:FIXME|add links | ||
| + | |||
| + | In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki> | ||
| + | |||
| + | Availability Vulnerability | ||
| + | |||
| + | Authorization Vulnerability | ||
| + | |||
| + | Authentication Vulnerability | ||
| + | |||
| + | Concurrency Vulnerability | ||
| + | |||
| + | Configuration Vulnerability | ||
| + | |||
| + | Cryptographic Vulnerability | ||
| + | |||
| + | Encoding Vulnerability | ||
| + | |||
| + | Error Handling Vulnerability | ||
| − | + | Input Validation Vulnerability | |
| − | + | Logging and Auditing Vulnerability | |
| − | + | Session Management Vulnerability]] | |
| − | + | __NOTOC__ | |
| − | |||
| + | [[Category:OWASP ASDR Project]] | ||
[[Category:Cryptographic Vulnerability]] | [[Category:Cryptographic Vulnerability]] | ||
| − | |||
[[Category:Java]] | [[Category:Java]] | ||
| − | |||
[[Category:Code Snippet]] | [[Category:Code Snippet]] | ||
Revision as of 14:27, 26 September 2008
This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.
- This article includes content generously donated to OWASP by
Last revision (mm/dd/yy): 09/26/2008
Vulnerabilities Table of Contents
Description
Standard pseudo-random number generators cannot withstand cryptographic attacks.
Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in security-sensitive context.
Computers are deterministic machines, and as such are unable to produce true randomness. Pseudo-Random Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.
There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and forms an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between it and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts.
Risk Factors
TBD
Examples
The following code uses a statistical PRNG to create a URL for a receipt that remains active for some period of time after a purchase.
String GenerateReceiptURL(String baseUrl) {
Random ranGen = new Random();
ranGen.setSeed((new Date()).getTime());
return(baseUrl + Gen.nextInt(400000000) + ".html");
}
This code uses the Random.nextInt() function to generate "unique" identifiers for the receipt pages it generates. Because Random.nextInt() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.
Related Attacks
Related Vulnerabilities
Related Controls
Related Technical Impacts
References
TBD
