Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

It's been argued that a GUID doesn't do a good job of being a one time security token , and it makes sense because GUIDs aren't random.

In my scenario: suppose a given company is using GUIDs as a security token, and needs to see the math behind the possibility of a security breach, before they will consider it a security concern...

That being said:

What is the statistical probability of an outsider guessing a GUID?

From what I can tell, the probability increases if the attacker knows the time/date the GUID was generated; but I don't know how to calculate the degree / scope of the vulnerability.

The probability also increases if the GUID is generated on the same machine (and perhaps the attacker knows this) for GUID versions 1 though 3. I'm unsure if this also applies to GUID version 4.

share|improve this question

2 Answers 2

up vote 2 down vote accepted

A GUID is just a data format. There are many ways to generate a GUID. The difficulty of guessing a GUID depends upon how it is generated.

Personally, I would be reluctant to use a GUID as an unguessable token. It wasn't designed for that purpose, and for some methods of generating a GUID, it's going to be insecure. It's not a great idea to make your security architecture rely upon a mechanism that wasn't designed for security and is likely to be fragile.

If you need a citation for this, you could do worse than to cite the original source: the Security Considerations section of RFC 4122 (the GUID spec). It says:

Do not assume that UUIDs are hard to guess; they should not be used
as security capabilities (identifiers whose mere possession grants
access), for example.

See also Are GUIDs safe for one-time tokens?.

Instead, I recommend using a cryptographically pseudorandom generator to generate a 128-bit single-use token. This is easy to do; you just use CryptGenRandom(), /dev/urandom, java.security.SecureRandom, or the equivalent for your platform to generate the 128-bit single-use token.

share|improve this answer
    
In a pinch, I've just salt-and-hashed a GUID too. –  pdubs Dec 19 '11 at 19:26

I've seen GUID spoofers so... The concept is out there. I'm sure given time, a determined attacker would succeed in duplicating the GUID even against the new standard.

Perhaps, an alternative would to not based authentication on time, and place but, instead ensure that authentication is unique to the individual(not the machine/terminal). Secondly, that the data is completely encrypted from sender to receiver. PGP comes to mind but, once you start securing everything the network also has to be prepared to accept the added overhead.

Networks admins start complaining about right now, and then the executives see $$$ only, and decline or dilute the process so that it will get done, "slowly but, surely..."

If you are preparing to present this I would suggest you show them they'll lose more $$$ in the long run being insecure then, they will if they are secured. They love numbers no mater if its - or +. Its their language, like technical terms are ours. Research, what hackers are researching. In this instance Google will come in handy. Think like the attacker would have too for a second, and see where that takes you.

Hope it helps ;-)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.