Take the 2-minute tour ×

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:
share|improve this question
That depends if you can create/predict what's gonna be the next GUID in use. –  Marcin Nov 30 '10 at 15:59
GUID generation is pretty much deterministic, given the operating variables, or enough prior GUIDs (actually does not require very many...) –  AviD Nov 30 '10 at 16:45
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 Nov 30 '10 at 20:59
@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. –  Michael Haren Nov 30 '10 at 21:35
@nealmcb, it isnt just MS' implementation, its the standard for GUIDs. –  AviD Dec 1 '10 at 21:08
show 1 more comment

5 Answers

up vote 10 down vote accepted

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).

share|improve this answer
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. –  AviD Nov 30 '10 at 16:38
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. –  Xander Nov 30 '10 at 16:49
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. –  Rory Alsop Nov 30 '10 at 18:26
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. –  AviD Nov 30 '10 at 19:56
Point taken. I'd agree that even if they're suitable for the purpose at hand, they're still not the best option from a security perspective. –  Xander Nov 30 '10 at 21:45
add comment

The UUID specification details several "versions" which are methods for generating the UUID. Most are aimed at ensuring uniqueness (that's the main point of UUID) by using, e.g., the current date. This is efficient but means that while the generated UUID are unique, they are also predictable, which makes them inadequate for some security usages.

The "version 4" UUID generation method (in section 4.4), however, is supposed to use a cryptographically strong random number generator. 6 of the 128 bits are fixed to a conventional value (to indicate that this is a version 4 UUID, namely), so this leaves 122 bits from the RNG.

If the underlying RNG is secure (e.g. /dev/urandom on a Linux/MacOS/*BSD system, or CryptGenRandom() on Windows) then given many generated UUID, an attacker is not supposed to be able to predict the next one with success probability higher than 2-122, which is adequately small for most purposes, including launch codes for nuclear missiles.

122 random bits ensure uniqueness with high probability. If you generate many version 4 UUID and accumulate them, you may expect to encounter your first collision after about 261 UUID -- that's about 2 billions of billions; simply storing that number of UUID would use more than 30 millions of terabytes. If you consider "only" 1012 such UUID (one thousand of billions, storable over 16 terabytes), then risks of having two identical UUID among these are about 9.4*10-14, i.e. about 700 thousands times less probable than winning millions of dollars at the lottery.

Therefore, UUID are appropriate for security purposes if (and only if) they are "version 4" UUID generated with a secure RNG.

share|improve this answer
add comment

No they are not secure. Your vulnerability & risk depends on how the GUID is generated. If you're on a Windows 2000 or newer box, then you're likely using version 4 of the GUID


These Guid's aren't cryptographically secure, but they do work as an identifier.

I think this GUID string should be encrypted before being sent to the client (via email, or however you decide). If you're encrypting using .NET take a look at this code to encrypt a string:


Here is another tip for dealing with encryption in a webfarm: there are several ways to encypt a string, and using DPAPI-based encryption won't work for a web farm, as the keys are different between machines. Use the machine key, or some other shared secret.

share|improve this answer
Why complicate things by encrypting a not-so-random number? Better and simpler to just generate a truly unpredictable random number. That is easy with /dev/random or /dev/urandom on Linux. We just need a simple specific recipe here for other platforms. –  nealmcb Jan 30 '11 at 16:27
add comment

If you're using a common development language creating a one shot generator of unique random numbers using a proper crypto function is not so difficult (we're talking about 10 lines of code that are available as samples in the most common languages simply using Google) and so using a simple new guid it's basically laziness from developer point of view.

In the scenario described they are "secure enough", if the Guid passed in the forgot password function has some basic features:

1) It's really a one shot value that has no relationship with the user id, so, once the password has been reset, cannot be used anymore

2) It has a defined window of time for its validity (you can reset password in the next 30 minutes or something like that)

If using the same Guid you can reset the password more than once or guess the guid and reset password of users that did not ask for a password reset or, like Avid describe in the comment, try to get access to reset password using some kind of replay attach then it's the application design that's faulty and using or not using a Guid is not the real problem.

So if you're not dealing with very sensitive information then maybe a guid could work, but why do not make things in a proper way the first time and use a proper crypto api to generate a secure random string?

Regards Massimo

share|improve this answer
I agree with the first part of your answer generating crypto-random numbers is extremely easy (and should take substantially less than 10 LoC...). However, in the scenario described they are not secure enough, since there is no guarantee that the password is reset immediately: There is usually a non-trivial window of validity. –  AviD Nov 30 '10 at 16:40
For example, consider the following: often this scheme is used to send a link to the user's preregistered email, which will allow direct access to reset the user's password. As an attacker, I would generate enough of these links/GUIDs till I could semi-reliably calculate the next batch, then ask to send the link to my victim (essentially having the user ask for a password reset). Then I would not care about access to the user's email, since I could just guess the GUID/link. –  AviD Nov 30 '10 at 16:44
AviD - definitely! GUID's must by dynamic/single use if there is any risk of a replay attack. –  Rory Alsop Nov 30 '10 at 19:31
@Rory, I was talking about the inherent guessability of GUIDs (given enough prior data), not replay attacks... –  AviD Nov 30 '10 at 19:55
add comment

Fake "GUID"s, which are not generated by any GUID generation algorithm, but which instead are simply 128 bits (16 bytes) generated by a cryptographically secure PRNG, and which are merely represented using conventional GUID hex-with-hyphens encoding, are mostly safe for one-time tokens.

You do run into the birthday problem, however, since the existence of a collision is around 2^-64 for 128-bit tokens.

Better to use 256-bit or 512-bit tokens, where the existence of a collision is around 2^-128 or 2^-256.

share|improve this answer
This is simply not true, at least not in general. If you are building on @Thomas's answer, then it starts to look more plausible but is still less accurate than his. –  Michael Haren Oct 7 '11 at 17:38
It should be clearer now. –  yfeldblum Oct 7 '11 at 17:50
add comment

Your Answer


