From: David <ro...@us...> - 2009-11-23 23:20:42
|
Hi Noa, thanks for poking around. Jpwsafe can certainly do with more (security) reviews! For the SecureRandom init, I trusted the java doc stating "Reseeds this random object, using the eight bytes contained in the given long seed. The given seed supplements, rather than replaces, the existing seed. Thus, repeated calls are guaranteed never to reduce randomness." So it would seem to me a seed with currentTimeMillies should be ok. When having a look at the implementation of SecureRandomSpi, it could be a good idea to at least call getNextRand once before adding such not-really-random seed. But still, a quick test with code like the following didn't give me any duplicates: long current = System.currentTimeMillis(); SecureRandom rand1 = new SecureRandom(); SecureRandom rand2 = new SecureRandom(); rand1.setSeed(current); rand2.setSeed(current); for (int i = 0; i<1000; i++) { int a = rand1.nextInt(); int b = rand2.nextInt(); System.out.print(a+"-"+b+","); if (a == b) System.out.println("Equal rand nums found!"); } Removing the setSeed lines above doesn't make much difference in the output. So, what do you think? Cheers, Roxon P.S.: Your patch to build.xml is committed, though yet untested. Am Dienstag, den 17.11.2009, 11:58 +0100 schrieb Noa Resare: > Poking around a bit in PasswordSafeLib i found that the SecureRandom > instance in Util.java is seeded with System.currentTimeMillis() (lines > 29-31) > > > This is a terrible idea. The total entropy in > System.currentTimeMillis() is small as it is, and if an attacker can > make some assumptions about when it is invoked (say narrow down the > invocation to a few hours) the entropy is reduced to small fraction of > that. The result is passwords that look safe but can be guessed. > > > My suggestion would be to remove the call to setSeed() and rely on the > internal self seeding of the java environment. This will use the > settings in the global java.security propeties file, which normally > taps into the operating system entropy pool via /dev/urandom or > fallback to a pure java loop speed count method which is much much > better than relying on the system clock. > > > So, please remove lines 29-31 of org/pwsafe/lib/Util.java > > > /noa > > -- > http://noa.resare.com -- skype: noaresare > +46 730 44 03 35 -- msn/xmpp: no...@re... > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ Jpwsafe-devel mailing list Jpw...@li... https://lists.sourceforge.net/lists/listinfo/jpwsafe-devel |