Insecure Randomness - Revision history

Imifos at 14:34, 2 February 2016

2016-02-02T14:34:30Z

Imifos at 13:03, 1 December 2015

2015-12-01T13:03:34Z

Wichers at 15:44, 20 December 2013

2013-12-20T15:44:29Z

Augustd: /* Examples */

2012-02-09T22:42:19Z

‎Examples

KirstenS at 01:25, 21 February 2009

2009-02-21T01:25:10Z

KirstenS at 02:32, 18 February 2009

2009-02-18T02:32:45Z

KirstenS at 14:37, 2 November 2008

2008-11-02T14:37:06Z

KirstenS at 14:27, 26 September 2008

2008-09-26T14:27:43Z

Weilin Zhong at 16:45, 19 July 2006

2006-07-19T16:45:53Z

Weilin Zhong at 14:50, 19 July 2006

2006-07-19T14:50:16Z

@@ Line 1: / Line 1: @@
 {{Template:Vulnerability}}
-Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 [[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
@@ Line 43: / Line 43: @@
 [[Category:OWASP ASDR Project]]
 [[Category:Cryptographic Vulnerability]]
-[[Category:OWASP Java Project]]
+[[Category:Java]]
 [[Category:Code Snippet]]
 [[Category:Vulnerability]]

@@ Line 43: / Line 43: @@
 [[Category:OWASP ASDR Project]]
 [[Category:Cryptographic Vulnerability]]
-[[Category:Java]]
+[[Category:OWASP Java Project]]
 [[Category:Code Snippet]]
 [[Category:Vulnerability]]

@@ Line 1: / Line 1: @@
 {{Template:Vulnerability}}
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
@@ Line 15: / Line 14: @@
 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==
@@ Line 42: / Line 37: @@
+	}
 </pre>
 __NOTOC__

@@ Line 22: / Line 22: @@
 ==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 (DO NOT DO THIS).
 <pre>
@@ Line 34: / Line 34: @@
 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]]==

@@ Line 1: / Line 1: @@
 {{Template:Vulnerability}}
 {{Template:Fortify}}
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
+[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 ==Description==

@@ Line 2: / Line 2: @@
 {{Template:Fortify}}
-==Abstract==
+[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 ==Description==
 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.
-==Examples ==
+==Risk Factors==
 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.
-==Related Attacks==
+==Related [[Attacks]]==
-==Related Vulnerabilities==
+Input Validation Vulnerability
-==Related Countermeasures==
+Logging and Auditing Vulnerability
-[[Random Number Generator]]
+Session Management Vulnerability]]
-[[:Category:Cryptography]]
+__NOTOC__
 [[Category:Cryptographic Vulnerability]]
 [[Category:Java]]
 [[Category:Code Snippet]]

← Older revision		Revision as of 16:45, 19 July 2006
Line 1:		Line 1:
		+	{{Template:Vulnerability}}
	{{Template:Fortify}}		{{Template:Fortify}}
−	~~{{Template:Vulnerability}}~~

	==Abstract==		==Abstract==

← Older revision		Revision as of 14:50, 19 July 2006
Line 1:		Line 1:
	{{Template:Fortify}}		{{Template:Fortify}}
−
	{{Template:Vulnerability}}		{{Template:Vulnerability}}