On Sun, Jan 10, 2010 at 11:19:51AM +0300, Fyodor Menshikov wrote: > Package: makepasswd > Version: 1.10-4 > Severity: critical > Tags: security > Justification: root security hole > > By default makepasswd gets 32-bit random seed from /dev/urandom, initializes > Perl random numbers generator with it using srand function and then generates > password length and password chars using rand function that is not > cryptographic > secure and absolutely predictable by initial seed that is only 32 bit > strength. > > Default settings for makepasswd is password length from 8 to 10 characters > inclusive > and password consisting of characters A-Za-z0-9 (total 62) so theoreticaly it > is > possible to create 62^8+62^9+62^10 = 8.5e17 passwords in default mode. > Actually > I think that security in this case better estimated by 62^8 = 2.1e14 because > all lengths have equal probability. > > But because rand function depends completely on srand seed the amount of > possible > passwords lowered from 8.5e17 or 2.1e14 to just 2^32 = 4.2e9. So any root user > (hence "root security hole" justification) that uses password generated by > makepasswd package is vulnerable to brute force attack. 4 billions paswords > brute > force attack is quite possible. > > The best solution of the issue I've found is using --rerandom=1 command line > switch > that initializes srand with cryptographic secure /dev/urandom value before > each rand > function call.
Thanks for your report. I agree that this is a problem we need to fix. I'm not sure how calling srand every time would help at all, though. Your point is that there are only 2^32 possible seeds. If we call srand every time, then there are still only 2^32 possible seeds. In fact, calling srand every time makes it worse; at least at the moment the administrator can tell makepasswd to produce some large number of passwords and select an arbitrary (if not truly random) one from that list. Since Debian's Perl is configured to use drand48() as its implementation of rand, there are in fact considerably more than 2^32 passwords available to an administrator following this strategy. Forcing makepasswd to reset the random seed every time *worsens* the situation because now there are only 2^32 possible passwords no matter how many you tell makepasswd to generate at once, because you only ever get the first value from the PRNG sequence. How about we use libcrypt-openssl-random-perl instead? You can seed its PRNG with an arbitrary amount of data; I expect 256 bits would be quite adequate given that that's vastly more than the space of available passwords for the default lengths, and you'd have to be generating somewhat over 30-character passwords before you started reaching that kind of entropy. (Plus, urandom(4) recommends reading no more than that amount of data per invocation.) Cheers, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
