How secure are GUIDs? Can I use it to generate passwords?


GUIDs are globally unique identifiers, and given their rather incomprehensible presentation, some people may be tempted to use them (or parts of them) as passwords. For example, one person wondered whether it was okay to use the first eight characters of a GUID as a temporary account password.

This is a really bad idea. GUIDs are designed for uniqueness, not for security.

For example, we saw that substrings of GUIDs are not unique. For example, in the classic v1 algorithm, the first part of the GUID is a timestamp. Timestamps are a great technique for helping to build uniqueness, but they are horrifically insecure because, well, duh, the current time is hardly a secret!

Using the first eight characters of a v1 GUID as a password is equivalent to using the current time as a password. And given that the current time isn't a secret, you made things an awful lot easier for the bad guys. All they need to know is what time you generated the GUID and they can get the first eight characters. Even if they don't know the exact time, if they can narrow it down to a range of a few minutes, they can brute-force the remaining options.

Even if you use one of the other GUID generation algorithms, that doesn't solve the problem, because the purpose of a GUID is to be globally unique, not to be unguessable.

Besides, the first eight characters of a GUID carry only 32 bits of entropy, because they come from a very limited alphabet: They can be a digit, or a letter from A to F. That's it.

If you want something cryptographically secure, then use a cryptographically-secure random number. Don't use something that "looks random to me." And use more entropy than 32 bits.

(Yes, this is basically a rehash of an earlier article, but I wanted to address directly the matter of using GUIDs as passwords.)

Comments (29)
  1. Kevin says:

    OTOH, a v4 GUID is *likely* to be difficult to guess *in practice*, assuming you're using something reasonable like a Mersenne Twister under the hood.  Depending on your language and library situation, that may or may not be the case.

    [The first 8 characters of a v4 GUID provide only 32 bits of entropy, which won't stop bad guys for long. -Raymond]
  2. Chris Crowther @ Work says:

    Kevin: There is no other hand.  This is a one handed argument.  Don't use GUIDs for passwords: that's not what they're for.  Use pwgen or something similar.

  3. FM says:

    Disagree with the implication of the title, as full guids make great passwords. The actual question is another rehash of "use the full guid, don't subdivide" class of mistake.

    [v1 GUIDs make terrible passwords, because once you have one password, you get the MAC of the password generator, and all that's left is to guess the time. A full v4 GUIDs is a good password, but if you are going to the effort to ensure that your generator is v4, you may as well just use your own random number generator. -Raymond]
  4. anonymouscommenter says:

    Which is why I use the whole type 4 guid not a piece of it.

  5. anonymouscommenter says:

    @Raymond: Yes, which is why I said the whole GUID is likely to be hard to guess.  It's probably not a great password (too much typing), but it could serve as an OK(ish) API key or something of that nature.

  6. anonymouscommenter says:

    I live on a street with 5-digit house numbers. My house number looks pretty arbitrary to me, so I'm thinking it will make a good password.

  7. anonymouscommenter says:

    You can get the best of both worlds by asking CryptGenRandom for 16 bytes, then treating the result as a GUID.

    (Purists will tell you that you then need to whack 6 bits to turn the result into an official v4 GUID, but this isn't required in practice.)

  8. > The first 8 characters of a v4 GUID provide only 32 bits of entropy, which won't stop bad guys for long

    Depends on what your account lockout policy is. In context, 32 bits of entropy can be great, or terrible.

  9. AndyCadley says:

    Depends on the end goal though. Around the launch of Vista a colleague was excitedly installing the RTM build on his new Dev PC, but wanted to also go off for an extended pub lunch. To avoid coming back to a half finished install he instructed the rest of us in the IT office to "answer all the questions for me and just leave me a note of the password." End result? Well we made him a password out of two GUIDs, for "security", as well as naming his machine and user account something suitably amusing….

  10. anonymouscommenter says:

    "Don't use GUIDs for passwords: that's not what they're for" and FM's comment:  Yes, I also would think that an entire v4 GUID would make a great password.

    "v1 GUIDs make terrible passwords, because once you have one password, you get the MAC of the password generator."  I presume you mean "once a bad guy has one of your passwords, he has the MAC of the password generator"?  If I use an entire v1 GUID as my password, a bad guy won't have another GUID from my computer… if he had my password, then he has my password.

    I would tend to use a password generator to generate a password.  But anything that's guaranteed to be unique SEEMS like it would make a great password.  (Not any subset of any GUID, though.)

    Interesting discussion though.  It hinges, as Raymond says, on the difference between uniqueness and hard-to-guess-ness.

    [The scenario under consideration (which I failed to communicate clearly) is that there is one machine that is responsible for generating new accounts and their temporary passwords. Therefore, once you get one temporary password, you have the MAC address of the password generator machine, and that leaves only the timestamp as a source of variability, and timestamps can be guessed. -Raymond]
  11. anonymouscommenter says:

    @DWalker

    > anything that's guaranteed to be unique SEEMS like it would make a great password.

    But really, those two properties are unrelated. Passwords don't need to be unique, and unique sequences can have terribly low entropy.

  12. Henri Hein says:

    @DWalker,

    "But anything that's guaranteed to be unique SEEMS like it would make a great password."

    I completely disagree.  For passwords, or any other token that grants access, you want distribution, not uniqueness.  To think about this more clearly, considering the 128-bit address space can be overwhelming.  Think of a 4-bit address space instead.  The principles are exactly the same, though the scale is different.

    Let us say we have a token generator that produces random 4-bit tokens, though never the same twice (at least until it runs out of possible tokens).  I want to guess your token.  Well, I already know my own token, so my guesses are already down to 15.  Maybe I can trick the generator into generating another token, or maybe I can get the token from a test-machine in the QA lab.  Once I have yours, I have one more token, and it will be easier to guess the next one.  You see how you are making my guessing task easier by introducing uniqueness.

    Anything that reduces your potential address space is a problem in security.  You want entropy and you want to make use of your whole address space, every time.

  13. T. West says:

    Given that just about every business I've ever worked for used a temporary password of "MyName99", "YYMMDD" or "CompanyName01", I'm not certain a time-stamp is distinctly worse :-).

    What I really want to know is how often weak passwords being guessed end up being the primary means of illegal access.  I have a feeling that it's a lot smaller than almost every other means of breaking in to a system, but I have no numbers to back that up.

  14. DWalker says:

    Yes, I agree that uniqueness and good-for-password-ness are not the same thing.  That's why I said SEEMS in capital letters and then I went on to say more after that.  

    @Henri Hein:  You can't disagree that it SEEMS that way, *to me*, at first glance.  :-)  It's up to me, not you, to decide what SEEMS to be true (to me).  :-)  :-)  Of course, things are not as they seem, and I recognize that!  It is an important distinction.

  15. anonymouscommenter says:

    @Henri Hein:  as I tried to say (but apparently I failed), I am explicitly assuming that a bad guy does NOT have access to the same password generator that I used.  That's why I said the bad guy doesn't necessarily know MY MAC address (especially if he has no physical access to my network).  

    Although what you say is true, you are throwing a bunch of other conditions in there, like "I already know my own token and I'm trying to guess yours".  Again, I posited that the guesser and I are using completely different password generators.  "Maybe I can trick the generator into generating another token".  If so, that's a WHOLE lot more information than an attacker would have, if I used MY computer to generate a GUID, and I used that entire GUID as a temporary password.  The attacker would not know what algorithm I used.

    I am just trying to be precise in what I said versus what you said.  The additional conditions you threw in makes it a completely different ballgame!

    And yes, still, using a GUID as a password is a bad idea.

  16. Henri Hein says:

    @DWalker,

    Fair enough, though I think it should have been equally obvious my meaning was "it does not SEEM that way to me" :)

    I'm not sure what you mean by "other conditions."  You postulated uniqueness.  Maybe you meant something different.

  17. anonymouscommenter says:

    @DWalker I'm thinking of a guid. If you can guess it, you may have all my riches. Go!

  18. anonymouscommenter says:

    Wouldn't performing a hash of the GUID make a more secure/better password than simply using the GUID?  I'm thinking SHA-2 would do the trick.

  19. cheong00 says:

    [Depends on what your account lockout policy is. In context, 32 bits of entropy can be great, or terrible.]

    I second that, considering most ATM passwords are 6-digit numeric digits only passwords and there aren't much news that the bad guys can sudenly take your money if your card is stolen.

    Whether it's good enough or not depends on the nature of how password is entered, plus the account lockout policy.

  20. anonymouscommenter says:

    Hmm, my technique has been to just do:

    loop { Guid.NewGuid(); Base64 hash it; If (base64Hash contains uppercase,lowercase,symbols,and digits) Break; }

    The base64hash ends up as 22 characters, which is good enough for me I guess(tm)

    Question: I've always wondered how the bad guys do offline attacks (where they don't attempt actual logins to check for password validity).  I mean they have an array of bytes that they stole and then they attempt to crack it to effectively get another array of bytes (that may be convertible to ASCII typically).  How do they know when to stop the crack attempts because they've nailed it?

  21. anonymouscommenter says:

    @Roger:

    If your encryption algorithm is such that

    Hunter01 always encrypts to 0x0aFEDEC65488831 and

    Hunter02 always encrypts to 0x0a7fFA5DEA43123

    If he can get a copy of the encrypted passwords, he doesn't have to try every combo.

    If the attacker knows the algorithm, he can make what's called a rainbow table of all the combos.

    If he knows your encrypted password is 0x0a7fFA5DEA43123 all he has to do is look it up in his table.

    He doesn't have to try every combination every time.

  22. anonymouscommenter says:

    Unless the attacker actually KNOWS you are using a GUID as a password, how would he know the range of characters in the password is 0-9a-f?

  23. anonymouscommenter says:

    @Henri Hein:  I meant that you were imposing other conditions (or perhaps "assumptions") that make it easier for a bad guy to guess my password-based GUID — such as you saying "trick the generator into generating another token, or maybe I can get the token from a test-machine in the QA lab".  If I generate a GUID, you (or the bad guy) won't have access to my computer.  

    And your condition "Let us say we have a token generator that produces random 4-bit tokens, though never the same twice (at least until it runs out of possible tokens).  I want to guess your token.  Well, I already know my own token."

    You were positing a token-generator, where I used that same generator, and which you also have access to. None of that was not in the original problem statement as I understood it from the original question — someone asked if THEY generated a GUID, and used it as a password, then how good is it???

    We can say these additional things that you say, but now it's a completely different problem (and an easier problem).

    The discussion is good though.

  24. anonymouscommenter says:

    @DWalker wrote "But anything that's guaranteed to be unique SEEMS like it would make a great password."

    A simple example:

    User1: Password 12345

    User2: Password 12346

    User3: Password 12347

    User4: Password ?????

    Questions:

    Is the password algorithm making UNIQUE passwords?  (yes)

    Is the password algorithm making DIFFICULT passwords? (no… anyone with multiple users on the system will see the pattern, and be able to guess subsequent passwords)

  25. anonymouscommenter says:

    I hereby motion to use IPv6 addresses instead of GUIDs for passwords.

  26. thealexdresko says:

    I hereby motion to use IPv6 addresses instead of GUIDs for passwords.

  27. Henri Hein says:

    @DWalker,

    Then I did not make myself clear.  The specifics of how the tokens are generated or discovered is not important.  Perhaps I should not have given examples.  The central point is that with unique tokens, each time an attacker sees a token, regardless of how, guessing one is easier for them.  If the attacker cannot see your tokens at all, you have a pretty closed system and the tokens are unlikely to be your point of weakness.

  28. 128=128 says:

    @alex. I wasn't going to endorse your proposition until I saw that you're *the* Alex Dresko ;)

  29. anonymouscommenter says:

    @Aaron:  Yes, I understand perfectly.  That's why I said seems.  Sorry I wasn't clear.  And yes, Henri, my point is that (in my scenario) an attacker would not see any tokens.  I have made a password from a GUID, and the attacker has NO OTHER information; it is, indeed, a closed system.  (Maybe the attacker doesn't even know that I made a password from a GUID.)

Comments are closed.

Skip to main content