Lets say I want to create a cookie for a user. Would simply generating a 1024 bit string by using /dev/urandom, and checking if it already exists (looping until I get a unique one) suffice?
Should I be generating the key based on something else? Is this prone to an exploit somehow?
The short answer is yes. The long answer is also yes. /dev/urandom yields data which is indistinguishable from true randomness, given existing technology. Getting "better" randomness than what /dev/urandom provides is meaningless, unless you are using one of the few "information theoretic" cryptographic algorithm, which is not your case (you would know it).
The man page for urandom is somewhat misleading, arguably downright wrong, when it suggests that /dev/urandom may "run out of entropy" and /dev/random should be preferred; the only instant where /dev/urandom might imply a security issue due to low entropy is during the first moments of a fresh, automated OS install; if the machine booted up to a point where it has begun having some network activity then it has gathered enough physical randomness to provide randomness of high enough quality for all practical usages (I am talking about Linux here; on FreeBSD, that momentary instant of slight weakness does not occur at all). On the other hand, /dev/random has a tendency of blocking at inopportune times, leading to very real and irksome usability issues. Or, to say it in less words: use /dev/urandom and be happy; use /dev/random and be sorry.
(Edit: this Web page explains the differences between /dev/random and /dev/urandom quite clearly.)
For the purpose of producing a "cookie": such a cookie should be such that no two users share the same cookie, and that it is computationally infeasible for anybody to "guess" the value of an existing cookie. A sequence of random bytes does that well, provided that it uses randomness of adequate quality (/dev/urandom is fine) and that it is long enough. As a rule of thumb, if you have less than 2n users (n = 33 if the whole Earth population could use your system), then a sequence of n+128 bits is wide enough; you do not even have to check for a collision with existing values: you will not see it in your lifetime. 161 bits fits in 21 bytes.
There are some tricks which are doable if you want shorter cookies and still wish to avoid looking up for collisions in your database. But this should hardly be necessary for a cookie (I assume a Web-based context). Also, remember to keep your cookies confidential (i.e. use HTTPS, and set the cookie "secure" and "HttpOnly" flags).
/dev/urandom, due to high use of entropy, are essentially nil. (To be precise, by "repetition" I mean an amount of repetition that is statistically significantly higher than expected by chance.) There is essentially no risk that /dev/urandom ever "runs out" within your lifetime.
Yes, it's a great way.
@Thomas's explanation nails it. And he is completely right to criticize the /dev/urandom man page. Spot on.
But skip "checking if it already exists". That check is pointless. It ain't gonna happen. (The chances of that happening are lower than the probability of being struck by lightning -- multiple times -- in the same day.)
Be aware of edge-cases if you're using Linux or NetBSD.
On Linux, you'd want make sure that enough entropy has been gained after boot to properly seed the CSPRNG, or use the getrandom() system call to read from /dev/urandom and only block in the rare event that sufficient post-boot initial seed entropy is unavailable.
In NetBSD, you'd want to read from /dev/random at least once before reading from /dev/urandom to ensure it has been seeded properly.
On FreeBSD and MacOS there is no difference between /dev/random and /dev/urandom.
The short answer is still to use /dev/urandom.
See When to use /dev/random vs /dev/urandom for further details.
From http://www.linuxfromscratch.org/hints/downloads/files/entropy.txt "Generating true entropy in a computer is fairly difficult because nothing, outside of quantum physics, is random. The Linux kernel uses keyboard, mouse, network, and disc activities, with a cryptographic algorithm (SHA1), to generate data for the /dev/random device. One of the problems with this is that the input is not constant, so the kernel entropy pool can easily become empty." "Another problem with using the keyboard, mouse, network, and disc activity is that on idle, unmanned, and disc-less systems there is very little, or no, input of this kind."
To me it looks real possible that /dev/urandom will run out because /dev/random feeds it.
/dev/urandom "running out of entropy" just isn't a problem. It continues to generate random bytes by other means, but in practice that doesn't affect predictability. I don't know enough about the issues to judge whether he's correct (though what he says agrees with things I've read elsewhere). Do you have specific evidence (or solid theory) that suggests draining the entropy pool is a real problem for /dev/urandom? Code that actually predicts the output of /dev/urandom with better results than chance would be good evidence.
Commented
Aug 15, 2013 at 20:32
/dev/urandomgives you repeats, you have a security problem that merely appending a counter won't fix. As our conversation is wandering away from the question, I suggest that we take any continuation to Information Security Chat(chat.stackexchange.com/rooms/info/151).