[Carpetsmoker]

I understand that /dev/urandom produces low quality streams as it will always output values, even when the entropy pool is exhausted.

On FreeBSD, /dev/random uses Yarrow (/dev/urandom is just a link to /dev/random, apparently).
/dev/random should to produce either a quality stream, or no output at all.

From random(4):

     The kern.random.sys.seeded variable indicates whether or not the random
     device is in an acceptably secure state as a result of reseeding.  If set
     to 0, the device will block (on read) until the next reseed (which can be
     from an explicit write, or as a result of entropy harvesting).  A reseed
     will set the value to 1 (non-blocking).

I don't have a Linux system, so I'll just quote wikipedia:

/dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered

[...]

A counterpart to /dev/random is /dev/urandom ("unlimited" /non-blocking random source) which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block, but the output may contain less entropy than the corresponding read from /dev/random. While it is still intended as a pseudorandom number generator suitable for most cryptographic purposes, it is not recommended for the generation of long-term cryptographic keys.

So it would seem that you're right. I had always assumed that /dev/random was an old (insecure) generator, and that /dev/urandom was a new (good) generator. I have no idea where I got this idea from. I think I got told "use /dev/urandom" once many years ago and just made assumptions from there ... :-/


Assuming that /dev/urandom isn't of spectacular low quality (which it doesn't seem to be), I don't think this has to be a problem, necessarily.
Remember, we not generating keys for use in a stream cipher 100 times/minute, where even a small problem in your PRNG would indeed be a major problem. What we're doing is occasionally generate a short password, often with large time intervals (days, weeks) in between two runs.

- An adversary needs n bits of output first to predict anything. Passwords (15 bytes in my example) generally aren't long enough to provide this output. My proposed solution even discards some output (not a security feature as such, obviously).

- You're not generating a lot of passwords, and the passwords you generate have a lot of time in between them. So if an advisory has somehow managed to get 200 of yours passwords, it's extremely unlikely anything useful can be learned about a potential 201st password.

- Even if an adversary examined all output of your PRNG, it needs to be *very* broken if you can learn enough to learn a 120 bit password to be truly useful.

- If the output wouldn't be uniform, you'd still get a fairly good pseudo-random password, unless, of course, your PRNG starts outputing 80% 0's or something ...


A system is only as strong as the weakest link, and there are quite a few weaker links I would worry about, such as:

- Passwords getting stolen (many examples of this), and re-used on other accounts. Obviously easily preventable by using an unique password for every service.

- Passwords not being stored securely, for as plaintext on the server, or as plaintext on your computer (such as your browser's cookie. Yes, people do this, often without the httponly flag set, meaning is ludicrously easy to steal it).

- (Hardware) keyloggers (I wouldn't know how to protect against this, I've seen people glue USB ports, but I don't consider that to be truly secure. You would somehow need to tamper-proof your computer's connections, your keyboard, and the cable).

- Various social engineering attacks (as described here, many other examples to be found).

- Shoulder surfing (through eyeballs, or camera's).


Open questions
- How likely is it that /dev/random is unable to generate high quality randomness, and will block?
- How low is the quality of /dev/urandom, exactly?
- What is the best cross-platform, random source? /dev/{a,u}random isn't defined by any standard. POSIX only offers random(), which isn't considered secure.