Can a UUID or GUID be matched back to the originating computer?

Question

A comment to this question on Reddit said

It’s almost a given that somewhere in one or more files is a UUID or GUID generated on OP’s computer. Those can, with enough effort, be matched back to the originating computer.

That seems like nonsense to me, but I am willing to be corrected.

Can it be done?

Answer 1

UUIDv1 and UUIDv2 can be matched to a computer, UUIDv4 can't. You're supposed to use UUIDv4.

See https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions

Famous story about UUIDv1: https://devblogs.microsoft.com/oldnewthing/20040211-00/?p=40663

Answer 2

To expand on the other answer: v4 UUIDs are made using a cryptographically secure [pseudo]-random number generator. Or at least, they're supposed to (there's a lot of code in the world that should use a CSPRNG and instead uses a normal fast-but-insecure PRNG). Because v4 UUIDs are thus a relatively easy way to get almost 128 bits of securely random data in hex-encoded (plus some dashes and so on) format, it's thus relatively common to use UUID generators when what you actually want is a blob of random data.

Don't do that. Please

UUIDs are not, in general, guaranteed unpredictable. That's simply not part of their design goal. They are supposed to be unique, and that's it. In fact, this goal was pretty well achieved using v1 and v2 UUIDs; the problem with them was that they leaked too much other info (MAC address and creation timestamp). Obviously leaking information can be undesirable, but sometimes you don't care, and sometimes it's even worth it for additional assurance of uniqueness.

It turns out that 122 bits of hard entropy are really enough for uniqueness, though. If you are absolutely sure that the function you're using generates and will always generate a v4 UUID - and generates it correctly - then you're probably safe to use that for session tokens or password reset tokens or so on. However, that's a rare guarantee to have. Lots of libraries that today generate v4 UUIDs make no promise about the future, for example. They probably won't go back to v1/v2, but if there's no guarantee that they'll stick to v4, then they might in future use something without v4's promise of cryptographically secure randomness.

If you're trying to use a UUID for anything at all these days, you should probably use v4. If you're trying to use a UUID for anything other than creating a fixed-length unique string that makes no other promises, you should not be using a UUID at all.