Are GUIDs safe for one-time tokens?
I see a lot of sites use GUIDs for password resets, unsubscribe requests and other forms of unique identification.
Presumably they are appealing because they are easy to generate, unique, non-sequential and seem random.
But are they safe enough for these purposes?
It seems to me that given a GUID, predicting subsequent GUIDs may be possible since (as far as I know) they're not intended to be cryptographically secure...or are they?
- I'm not talking about sites that use a random blob of gobbledygook encoded in base64.
- I'm talking about sites like this that appear to be using a raw guid:
GUID generation is pretty much deterministic, given the operating variables, or enough prior GUIDs (actually does not require very many...)
It all depends on exactly what you mean by GUID and how it was generated. Looking at a URL it may seem that it is in UUID format, and you may guess it was generated by Microsoft's insecure GUID algorithm, and thus it would not be suitable for any use like what you propose. But it might have been generated using a good cryptographically secure pseudo-random source like /dev/random in Linux, in which case it would be just fine.
@nealmcb: sure--this isn't a direct criticism of any particular site. Instead, I'm trying to confirm my suspicion that such a practice (secure ID via guid) is probably not good. Consensus seems to be that GUIDs are predictable (though non-trivial to predict), and more secure means should be used.
@avid We agree that nothing in the RFC specifies that even type 4 "random" UUIDS are cryptographically secure. My only point was that you could use a good implementation of the RFC for security purposes. E.g. on a modern Linux box with /dev/random, the libuuid library (and uuidgen program) will by default generate very good, unpredictable UUIDs. http://www.kernel.org/doc/man-pages/online/pages/man4/random.4.html But it is surely better for security software to directly use an API that is designed specifically to provide crypto randomness, since someone may carelessly port the code.
Are they safe enough for the purposes you described? In my opinion, generally yes. Are they safe enough in applications where security is a significant concern? No. They're generated using a non-random algorithm, so they are not in any way cryptographically random or secure.
So for an unsubscribe or subscription verification function, I really don't see a security issue. To identify a user of an online banking application on the other hand, (or really probably even a password reset function of a site where identity is valuable) GUIDs are definitely inadequate.
For more information, you might want to check out section 6 (Security Considerations) of the RFC 4122 for GUIDs (or Universally Unique Identifiers).
The purpose he described is exactly a password reset function. While it is clear that you are stating that GUID is *not* acceptable for any security use, your first sentence contradicts that.
And I'd agree that it's acceptable for a password reset function on most sites. Not for banking sites, or sites where assuming another user's identity would be particularly valuable, but most sites simply don't present a valuable target for this sort of attack, or a high enough volume of password-reset requests for an attack of this nature to work in the first place.
Password reset at most organisations I have worked was definitely considered at a lower security level than authentication for transactional sites etc. Yes, it is a vector for attack, however the limitations imposed (time, knowledge of secret information etc) and the cost reductions made in simplifying password self reset (any reduction in helpdesk calls saves money) are generally considered enough of a driver.
Hmm, I guess that's true, for low-value sites GUID may be good enough. But really, as @massimo mentions in his answer, why bother? Cryptorandom numbers are not costly, neither in dev time or processing time.