Is using a GUID security though obscurity?

Hi,

If you use a GUID as a password for a publicly facing application as a means to gain access to a service, is this security through obscurity?

I think the obvious answer is yes, but the level of security seems very high to me since the chances of guessing a GUID is very very low correct?

Update

The GUID will be stored in a device, when plugged in, will send over the GUID via SSL connection.

Maybe I could generate a GUID, then do a AES 128 bit encrption on the GUID and store that value on the device?

From stackoverflow

• I recommend against using a GUID as a password (except maybe as an initial one to be changed later). Any password that has to be written down to be remembered is inherently unsafe. It will get written down.

  Edit: "inherently" is inaccurate. see conversation in comments

  JohnFx : I think he is talking about a service password. In this case it is more rare to need to enter it frequently making it less likely to be a problem.

  James Schek : Why does this myth continue to be perpetuated? Well respected security experts have debunked this myth. http://www.schneier.com/blog/archives/2005/06/write_down_your.html

  Treb : @James Schek: Have read the blog entry. Schneier wants people to store the paper in their wallet. Most people will stick with the post-it under the keyboard or in the drawer. It is not a myth, I'm afraid.

  Dinah : If it goes on a post it note or on a notepad next to their computer (I've seen both) then it's not a myth and it is a real danger. I respect professionals and all but worship Schneier. He did not debunk this. See comment by Treb.

  James Schek : OP said: "Any password that has to be written down to be remembered is ***inherently unsafe***." Instead of teaching people "don't write it down", we should be teaching people "if you write it down, keep it somewhere safe."

  James Schek : The key phrase, "inherently unsafe", perpetuates the idea that you can never write down your password... this encourages all sorts of bad behaviors. Instaed, we should be encouraging people to SECURE physical items like written passwords--something most people CAN figure out how to do.

• If one can observe the GUID being sent (e.g. via HTTP Auth), then it's irrelevant how guessable it is.

  Some sites, like Flickr, employ an API key and a secret key. The secret key is used to create a signature via MD5 hash. The server calculates the same signature using the secret key and does auth that way. The secret never needs to go over the network.

  David Hill : No. They try to generate the same hash from the secret. If the result hash matches the sent hash, then everything is ok. You can't decrypt a 1-way hash, that's the whole point.

• GUID is to prevent accidental collisions, not intentional ones. In other words, you are unlikely to guess a GUID, but it is not necessarily hard to find out if you really want to.

• At first I was ready to give an unqualified yes, but it got me thinking about whether that meant that ALL password based authentication is security by obscurity. In the strictest sense I suppose it is, in a way.

  However, assuming you have users logging in with passwords and you aren't posting that GUID anywhere, I think the risks are outweighed by the less secure passwords the users have, or even the sysadmin password.

  If you had said the URL to an admin page that wasn't otherwise protected included a hard coded GUID, then the answer would be a definite yes.

  JohnFx : In that case I think you are good. The GUID by itself would definitely be security by obscurity and not adviseable, but obfuscating things a bit ON TOP OF a solid authentication system sounds reasonable.

• It's better than using "password" as the password, at least.

  I don't think a GUID would be considered a strong password, and there are lots of strong password generators out there that you could use just as easily as Guid.NewGuid().

  Rob Walker : A guid is a very strong password ... there are 2^128 of them, guessing a random guid is going to take you a while. But a strong password (guid or otherwise) is no good if it is written down somewhere everyone can see it (or hidden somewhere they can find it if they look hard enough).

  Treb : +1 for the password 'password' ;-)

  James Schek : US Gov't data can be classified using AES and a 128-bit binary key... a Random GUID would be a 128-bit key... sounds strong enough to me.

  MusiGenesis : @James: I just learned this the other day, but it's actually only a 124-bit key, so he's just a little too short for the Army.

  MusiGenesis : @Rob: this definitely isn't my area, but I thought a strong password needs to have upper- and lower-case letters, numbers, and funky symbols (to maximize the range of byte values). GUIDs-to-strings are usually hexadecimal (0-9 and A-F), which should make them even weaker than normal. I dunno.

  MusiGenesis : Oh, and the hyphen (sometimes). That's one funky character, at least.

  James Schek : You are confusing characters with bits. A single alpha-numeric character (a-zA-Z0-9) represents 62 possible values--i.e. about 6 bits. A hex character represents 16 possible values--i.e. 4 bits. A 21 char alpha-num password is roughly equivalent to a 32 char guid.

  MusiGenesis : @James: I'm not confusing anything with anything. When he talks about using a GUID as a password, he means the password is something like this: "5aaa7114-35b1-4ca3-b059-a868d4628378". This is, of course, just a 36-character string, but made up of only 17 different possible characters.

  James Schek : @Musi: My point is that his 36-char string is equivalent to a shorter, 21-ish char string (maybe 16 with special symbols). In most systems, that would make the password sufficently hard to brute-force that it was a "strong" password.

  James Schek : Upper/lower/symbols is just a way to make better use of your available characters. So yes, it's weaker than a full alpha-num 36 char password... but it's still as strong as your typical "strong" password with 12 random chars of uc/lc/num/sym/etc (78-bits).

  MusiGenesis : @James: I didn't realize that pure length contributed to the strength of a password (I think I was thinking of hash keys or something), although that makes obvious sense. I am dumb and I retract my answer. :)

  MusiGenesis : Except for the "using a password generator" part.

  MusiGenesis : And the "password" gag.

• Actually, using a GUID as a password is not a good idea (compared to coming up with a truly random password of equivalent length). Although it appears long, it's actually only 16 bytes which typically includes the user's MAC address, the date/time and a smallish random element. If a hacker can determine the users MAC address, it's relatively straightforward to guess possible GUID's that he would generate.

  Esteban Brenes : This will vary depending on version of UUID. Not all generators use this method. Java for one doesn't. It's also not true of the latest versions of Windows which do not include the MAC Address: http://msdn.microsoft.com/en-us/library/aa379205.aspx

  Denis Hennessy : You should separate the transport security (where you encrypt the link over which the credential is passed) from the strength of the credential. If you have 128 bits available on the device to hold a 'password', then the best password will be simply a 128 random bitstring. GUIDs are weaker than that

  Denis Hennessy : http://en.wikipedia.org/wiki/Globally_Unique_Identifier has a good description of the different algorithms used to generate GUIDs and why they're bad to use as cryptographic keys.

  sep332 : @Blankman: it's useless to encrypt something if the attacker already knows what it is. Encrypting an easily-discovered value is pretty useless.

  James Schek : @Denis: Sounds to me like that's a lesson on having a good random number generator, not evidence of the GUID's inherent unsuitability. The article only shows (I think since I only read English) the Win API generator is flaws... that said, a 128 random bitstring is still the best idea.

• It really depends on what you want to do. Using a GUID as password is not in itself security through obscurity (but beware the fact that a GUID contains many guessable bits out of the 128 total: there is a timestamp, some include the MAC address of the machine that generated it, etc.) but the real problem is how you will store and communicate that password to the server.

  If the password is stored on a server-side script that is never shown to the end user, there is not much risk. If the password is embedded in some application that the user downloads to its own machine, then you will have to obfuscate the password in the application, and there is no way to do that securely. By running a debugger, a user will always be able to access the password.

• Sure it is security by obscurity. But is this bad? Any "strong" password is security by obscurity. You count on the authentication system to be secure, but in the end if your password is easy to guess then it doesn't matter how good the authentication system is. So you make a "strong" and "obscure" password to make it hard to guess.

• In my opinion, the answer is no.

  If you set a password to be a newly created GUID, then it is a rather safe password: more than 8 charcters, contains numbers, letters ans special characters, etc.

  Of course, in a GUID the position of '{', '}' and '-' are known, as well as the fact that all letters are in uppercase. So as long as nobody knows that you use a GUID, the password is harder to crack. Once the attacker knows that he is seeking a GUID, the effort needed for a brute force attack reduces. From that point of view, it is security by obscurity.

  Still, consider this GUID: {91626979-FB5C-439A-BBA3-7715ED647504} If you assume the attacker knows the position of the special characters, his problem is reduced to finding the string 91626979FB5C439ABBA37715ED647504. Brute forcing a 32 characters password? It will only happen in your lifetime, if someone invents a working quantum computer.

  This is security by using a very, very long password, not by obscurity.

  EDIT: After reading the answer of Denis Hennessy, I have to revise answer. If the GUID really contains this info (specifically the mac address) in a decryptable form, an attacker can reduce the keyspace considerably. In that case it would definitely be security by obscurity, read: rather insecure.

  And of course MusiGenesis is right: there are lots of tools that generate (pseudo) random passwords. My recommendation is to stick with one of those.

  James Schek : GUID/UUID is not required to contain th Mac Address. This is only one of several methods to generate a GUID.

  Arafangion : The majority of those methods, however, do use known and predictable methods of calculating the values, as a way of achieving a *mathematically unique* value that is much less likely to result in a collision than a regular random string of digits would.

• It's only security through obscurity to the extent that that's what passwords are. Probably the primary problem with using a GUID as a password is that only letters and numbers are used. However, a GUID is pretty long compared to most passwords. No password is secure to an exhaustive search; that's pretty obvious. Simply because a GUID may or may not have some basis on some sort of timestamp or perhaps a MAC address is somewhat irrelevant.

  The difference in probability of guessing it and something else is pretty minimal. Some GUIDs might be "easier" (read: quicker) to break then others. Longer is better. However, more diversity in the alphabet is also better. But again, exhaustive search reveals all.

• I agree with most other people that it is better than a weak password but it would be preferable to use something stronger like a certificate exchange that is meant for this sort of authentication (if the device supports it).

  I would also ensure that you do some sort of mutual authentication (i.e. have the device verify the servers SSL certificate to ensure it is the one you expect). It would be easy enough of me to grab the device, plug it into my system, and read the GUID off of it then replay that back to the target system.

• In general, you introduce security vulnerabilities if you embed the key in your device, or if you transmit the key during authentication. It doesn't matter whether they key is a GUID or a password, as the only cryptographic difference is in their length and randomness. In either case, an attacker can either scan your product's memory or eavesdrop on the authentication process.

  You can mitigate this in several ways, each of which ultimately boils down to increasing the obscurity (or level of protection) of the key:

  • Encrypt the key before you store it. Of course, now you need to store that encryption key, but you've introduced a level of indirection.

  • Calculate the key, rather than storing it. Now an attacker must reverse-engineer your algorithm, rather than simply searching for a key.

  • Transmit a hash of the key during authentication, rather than the key itself, as others have suggested, or use challenge-response authentication. Both of these methods prevent the key from being transmitted in plaintext. SSL will also accomplish this, but then you're depending on the user to maintain a proper implementation; you've lost control over the security.

  As always, whenever you're addressing security, you need to consider various tradeoffs. What is the likelihood of an attack? What is the risk if an attack is successful? What is the cost of security in terms of development, support, and usability?

  A good solution is usually a compromise that addresses each of these factors satisfactorily. Good luck!