On Mon, Jan 11, 2010 at 04:23:17PM +0300, Fyodor Menshikov wrote: > Colin Watson wrote: >> 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. > > No, calling srand function with 32 bit cryptographic secure random number > argument before each rand function call does _not_ make things worse and > number of available passwords is not limited by 2^32. > > With this approach first char of password depends on first 4 bytes read > from /dev/urandom. The second char depends on second 4 bytes read from > /dev/urandom. The third char depends on third 4 bytes read from > /dev/urandom. And so on.
Ah, re-randomising every character rather than every password. Right, my mistake, sorry. Still, from what I read in urandom(4), I think this would constitute urandom abuse. We don't need this much kernel randomness - a decent userspace PRNG, properly seeded, will do fine. >> 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.) > > I think that using either of libcrypt and /dev/urandom is secure and > which one to choose is just matter of taste. To my taste system internal > cryptographic PRNG (/dev/urandom) is more tested and secure than any > third party library. And it is _already_ used by makepasswd package. So > all required to do is just ignore --rerandom key and fix this parameter > value to 1. I'm comfortable with using OpenSSL here. It's already used in various critical applications. While it's true that its pseudo-random number generator has had one extremely-well-publicised serious flaw in Debian, I think sufficient eyes are on that code now that it isn't going to happen again - and in any case many more serious things were affected by that particular flaw, so anyone sensible changed their passwords following it anyway. > On the other hand makepasswd has key > --randomseed=N Use random number seed N, between 0 and 2^32 inclusive. > A zero value results in a real-random seed. > > I think that this key should be made deprecated and disallowed at all. > But if it is absolutely necessary to allow creation of predictable (but > secure!) passwords then /dev/urandom cannot help, libcrypt should be used > instead (and range of arguments to --randomseed should be extended to > 2^256). > > Or for backward compatibility it is possible to use old approach > (internal rand without reseed) if --randomseed argument is specified. > Anyway users of --randomseed were warned that there are only 2^32 cases. This latter approach is the one I ended up taking. I think it's reasonable; anyone using this option is presumably expecting that the values returned will remain constant across invocations, including across upgrades of the makepasswd package. I added a few imprecations to the effect that this option should not normally be used. I'd appreciate it if you could have a look at the code I just uploaded to unstable, and review it for correctness. You can see the diff here: http://bzr.debian.org/loggerhead/users/cjwatson/makepasswd/trunk/revision/20 Thanks for your feedback, -- 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
