At work today I was having a discussion about identifying a user between two web servers that will have access to the same backend DB. I suggested using a GUID to identify the user session but a colleague said that GUIDs can be spoofed.

However a quick Google showed that version 1 GUIDs could easily be spoofed but since Windows 2000 a new version was implemented using (pseudo) random data, i.e. a version 4 GUID, as I work in a MS application environment how true is my colleagues assertion?

  • 1
    Can you explain what "spoofing a GUID" means to you? I can think of very few cases where I would use a GUID where spoofing is a meaningful attack vector, especially if I am in control of both the server assigning the GUID and the server consuming the GUID. – Cort Ammon Jul 21 '17 at 3:35
  • What I mean is generating the exact same value as a string representation. Not the first (for example) 10 characters. – Graham Harris Jul 21 '17 at 17:05
  • Generating the exact same value via. the correct means, or generating them via malicious means? – Cort Ammon Jul 21 '17 at 23:56
  • Both really. I have seen GUIDs used for primary keys in databases and for session identification or password reset links. – Graham Harris Jul 22 '17 at 9:25

You've stated you're interested in considering both collisions generated by "proper" means and attacks which involve maliciously generating GUIDs improperly. The answers to these two situations are extraordinarily different.

If all GUIDs that enter your system are generated by proper means (i.e. generated according to RFC 4122, then you can expect them all to be unique. GUIDs/UUIDs were designed from the start to provide the specific guarantee. A GUID/UUID generated anywhere will be unique from all other GUID/UUIDs without requiring any centralized authority. There are Oracle servers which generate millions of UUIDs per second in giant distributed databases without collisions. GUID/UUIDs were built for this.

If you are worried about malicious users improperly crafting GUIDs/UUIDs, you do have some concern. From this answer regarding UUIDs:

GUIDs generated by calling other people's GUID generation functions are still not suitable for use as unguessable auth tokens though, because that's not the purpose of the GUID generation function - you're merely exploiting a side effect.

That answer hit the nail on the head. GUIDs/UUIDs were never designed to be unguessable. They were designed to be unique. If the method you use to generate those GUIDs/UUIDs provides unguessability, that is a side effect of the process. You would need to investigate how your particular generator works.

As you have noticed, v1 GUIDs are particularly guessable. Their uniqueness depends entirely on a MAC address and a timestamp with 100ns increments. This is comparatively easy to spoof. If you can narrow down the time where a session was generated to, say 1/10th of a second, there's only 1,000,000 possible values. The only other protection you have is the clock-sequence field, which is not intended to be unguessable, so it is likely to remain the same between reboots of a computer.

v4, on the other hand, is almost completely defined by a 122 bit random number. These are highly unguessable, as long as you can trust the underlying random number generator. However, remember that you're reliant on a side-effect of the process here. There's no guarantees to the random number's quality because that isn't required to generate unique values -- its only required for unguessability.

As such, if you depend on the randomness of your session IDs as a security feature, you should generate them yourself, using a cryptographic generator you trust. There's nothing wrong with using the GUID format for these numbers. They'll still have more than enough entropy to deal with mere session keys. The trick is that you shouldn't trust the built in GUID generators to deliver guarantees that are not explicitly part of the purpose of GUID generation.

| improve this answer | |
  • Thanks that helps a lot in understanding GUIDs/UUIDs. Conceptually you could use a GUID as a salt to some cryptographic method to generate a hash. But as you say, with all things security related there is some form of trust in the implementation of the algorithm. – Graham Harris Jul 23 '17 at 23:12

The problem with determining the security of a v4 UUID (we know v1 UUIDs are not in any way secure) is that you have to know and understand the underlying mechanism for generating them in your specific application, since this could be different for every implementation, and could very definitely have a security impact.

The key is that you're looking not only for randomness, but also for unpredictably. We know that a version 4 UUID has 122 bits of randomness. This is very good, and if the source of the randomness is a CSPRNG, then we can be confident that yes, it is quite reasonably safe to use as a session identifier. If, however, the RNG is not a CSPRNG, there's a definite possibility that while the UUIDs have good statistical randomness properties, they may still be predictable enough for an attacker who gets his or her hands on some number of them to guess other, valid session identifiers with a non-trivial probability and only a reasonable amount of work.

So, if you know how the GUIDs are generated for your application, you can make a far better determination as to whether it's safe to use them directly to protect session data.

| improve this answer | |
  • That's intriguing. Is the attack you mentioned (grabbing some number of existing session IDs and predicting other valid ones) documented anywhere? – NH. Jan 20 '18 at 0:05

Based on the documentation for UuidCreate, this answer about the size of a Windows UUID (since Windows 2000) and this answer about UUID randomness, and lastly the RFC concerning creating a GUID from random numbers, it would appear that you are correct that modern Windows systems will generate GUIDs by default by using an AES-based random number generator, which should make spoofing them equally infeasible compared to a random identifier generated from the same CSPRNG with the same number of random bits (122 bits). As the second answer notes though, GUIDs are intended to be unique, not to defend against spoofing - that they happen to do this by their generation method is effectively a side-effect.

As a programmer, two things would concern me about using GUIDs as random session identifiers

  1. Since we can't really check the source code for the underlying functions, it's possible they have some form of guard against generating the same number twice, which may weaken them as true CSPRNGs. I also generally do not use GUIDs as random numbers on principle, because that is not their documented purpose.

  2. Using a GUID limits you to the entropy the GUID is programmed to use - 122 bits. You will need to rewrite your code in the future if you want to start using e.g. 256 bits instead, whereas using a CSPRNG now allows you to easily change the size of the number generated later.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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