NewID() - Is there a high chance of exposing the previous/next GUIDs

Question

I know GUIDs are theoritically unique with a very low chance of collision. However, if I understand properly some of that uniqueness is available because it's seeding from information on the computer used to generate it depending on the algorithm in use.

How likely is it that given a GUID a user could guess other GUIDs in the table?

As an example, if you have newsletter subscribers with a unsubscribe feature you could just have it post to example.com/subscriber/unsubscribe/{id}

With an integer identity this is obviously a bad idea. The user with ID 1000 can unsubscribe your entire database in seconds by guessing IDs.

If the ID column is a GUID initialized to a newid() how likely is it that your user could guess correct IDs if they know theirs?

Answer 1

I'd say that it's probably possible in theory, but very, very unlikely to actually happen.

I've read Eric Lippert's blog posts that SLaks linked in his comment, and some other answers on Stack Overflow:

• How to predict the next GUID from a given GUID?
• How easily can you guess a GUID that might be generated?

As far as I understand it: given a set of a few GUIDs, it might be possible to find out if they were generated on the same machine. But it's not easy to find out, and certainly not for the average user.

Now I guess that given only one GUID (the newsletter subscription ID from the example), it will be very hard to guess any other GUID.
If (and only if) it's really possible, you probably need a fast machine and in-depth knowledge about the algorithms used to create GUIDs.

Finally, you have to look at the context:
Even if it is possible to guess GUIDs (and I'm not really sure that it is - I'm sure that I couldn't do it), I can't imagine that someone will really do this in order to unsubscribe other people from your newsletter.

Answer 2

NEWID() generates a Version 4 GUID but it's implementation is guessable. GUIDs are designed to be unique, not random.

From the RFC 4122 spec:

Security Considerations

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. A predictable random number source will
exacerbate the situation.

As @martin-smith pointed out just because it is a Version 4 complaint GUID doesn't make it inherently guessable it depends on the implementation. This stackexchange post shows how to create a complaint version 4 GUID using SQL that isn't guessable:

SELECT CAST(CRYPT_GEN_RANDOM(16) AS UNIQUEIDENTIFIER)

References:

• RFC 4122
• NEWID()
• CRYPT_GEN_RANDOM()
• http://www.blackwasp.co.uk/SQLSelectRandom.aspx
• https://en.wikipedia.org/wiki/Universally_unique_identifier