views:

89

answers:

6

When users create an account in my web application, I generate a GUID and use the first 8 characters as their password which is then sent via email.

Is there a security risk I am overlooking in using GUIDs as passwords? I've taken a look at the questionAre GUIDs good passwords?, but that question pertains to personal passwords not random/generated passwords. Ideally, users will login and change their password if they want to.

+4  A: 

Yes, unless you know exactly how the GUID is built. For example, some GUIDs bundle the MAC address of the host in to the GUID. If you happen to use those bits, then that compromises a large amount of the bit space for the "random" password.

Simply put, GUIDs may be unique, but they are not necessarily random.

Will Hartung
@Will they are decidedly not random
JaredPar
the MAC is normally used to build the "node" component, ie the last section of a GUID.
mlathe
@Will: first eight bytes is a timestamp: http://blogs.msdn.com/b/oldnewthing/archive/2008/06/27/8659071.aspx
Stringer Bell
@mlathe, true but finding the "node" component in this case is as simple as enlisting in the site and getting my very own password.
JaredPar
@JaredPar, my point was that the MAC is used to make the end of the GUID. So the OP wouldn't be using it since he was using the "first 8 characters"
mlathe
+6  A: 

Using GUIDs as passwords is a very bad idea. GUIDs are generated in a very predictable and well defined manner. Or in other words given enough information it would allow an attacker to predict the passwords of other users.

Predictable and well defined is the exact opposite of what you want in a password generator.

JaredPar
The spec of GUID says that the first three sections of a GUID are random numbers from a timestamp. That's probably no worse then just using random().
mlathe
@mlathe timestamp's are predictable and hence using numbers from them is never random. There is a small finite set of choices.
JaredPar
You're right... It's just a raw timestamp... Not a random number from the timestamp. I stand corrected.
mlathe
+2  A: 

"Cryptanalysis of the WinAPI GUID generator shows that, since the sequence of V4 GUIDs is pseudo-random; given full knowledge of the internal state, it is possible to predict previous and subsequent values." http://en.wikipedia.org/wiki/Globally_unique_identifier

I wouldn't use it. It's not that hard to use a random number generator, after all, which are designed to be as random as possible, rather than attempting to guarantee global uniqueness.

Kirk Woll
+1  A: 

This article says don't use it.

mlathe
+1  A: 

GUIDs come in a number of flavors; some have parts that are predictable.

On the other hand, it is very, very easy to generate random numbers.

Why use a questionable technique when a secure alternative is readily available?

erickson
Isn't it really easy, given a random number, to determine what the next 'random' number will be, assuming you've not reseeded the RNG in the meantime?
Will A
Use more strong PRNGs then.
wRAR
@Will A - It's not easy, even with a non-cryptographic RNG, but it's "computationally infeasible" with a cryptographic RNG.
erickson
If you happen to know which RNG is being used, or can make a fair guess, is it still difficult? Computationally infeasible sounds like a fair level of security to me. :)
Will A
A: 

Using part of the GUID, or even the whole thing, is a very bad idea. Even if most of it happens to be random, there's no guarantee that any particular portion will be.

I'm not sure there'd be much trouble using a hash of a GUID, or better yet a hash that combined a GUID with some other source of randomness (e.g. one might hash the time when the program starts, and then generate a passcode by returning part of a hash of the previous hash and a new GUID). If there's any randomness at all in GUID generation, the entropy of the hash should increase with each iteration. Note that the passcode should not reveal the entire hash value; some of that should be kept as secret internal state.

supercat