Jan P. Monsch wrote:
> Hi
>
> In my review practice I often have to look at Java
source code which is used
> to generate passwords, authentication tokens or session
ids. Ever so often
> this code uses the Java API class java.util.Random to
generate random
> numbers. It is well-established in security industry
that this particular
> random generator is not secure. Since I did not know
what the reason is for
> this perception I started to have a closer look.
>
> During the review of the Java API source code I
discovered two
> vulnerabilities which cause the internal state of
java.util.Random to be
> partially exposed or easy guessable. Following paper
"Ruining Security with
> java.util.Random" demonstrates two techniques how
security mechanisms based
> on java.util.Random can be attacked and under certain
conditions can be
> broken within seconds:
> http://www.iplosion.com/papers/ruini
ng_security_with_java.util.random_v1.0.p
> df
>
>
FYI: I discussed a particular case of reconstructing the
internal PRNG
state from output observation (the Apache JServ session ID
weakness -
which is based on the Java Random) in my "Cookie
Poisoning" paper of
2002 (http://www.cgisecurity.com/lib/CookiePoisoningByline.pdf
, see the
appendix for details).
Regards,
-Amit
------------------------------------------------------------
-------------
Sponsored by: Watchfire
Today's hackers exploit web applications to expose,
embarrass and even
steal. Firewalls and SSL may be commonplace but recent
studies indicate 3
out of 4 websites remain vulnerable to attack. Watchfire's
"Addressing
Challenges in Application Security" whitepaper,
explains what to do and
provides a guideline to improving your own application
security.
Download this whitepaper today!
https://www.watchfire.com/securearea/whi
tepapers.aspx?id=701500000008YTU
------------------------------------------------------------
--------------
|