[ACCEPTED]-Is using a GUID security though obscurity?-security-by-obscurity

In my opinion, the answer is no.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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