How to predict the next GUID from a given GUID?
Asked Answered
T

5

5

I have sent 10000 mails to our customers and each mail had a link of the format

http://example.com/LogIn?key={guid}

Unfortunately the guid I sent were random guids (test data generated by Guid.NewGuid()) so the customers have all received invalid links...

Based on the 404s i receive from the webserver I have a few guids that I sent out. I have read that the guid generator in windows is weak so you can predict the next guid from one you already have. Does anyone know how? If i could do that I could make the guids I sent out valid so the links would work again.

Topography answered 3/5, 2009 at 12:1 Comment(5)
Why not check the sent mails and parse the GUIDs sent from there? Do you have some mail server archives? Or you could just enable any GUID of that form. It's not like there is a swarm of bad guys waiting to take advantage of your offer that know the details of the link sent out AND that you don't have the GUIDs (until your post on S.O that is).Meant
Is there no way to get a copy of what you sent, and process that? If you have your own mail server, it might have kept a copy.Yaya
See: #643945Quirt
unfortunately the mails have not been recorded. each guid is associated with a set of data that only that specific customer can see and edit. it is a password.Topography
I think it would be better to simply redo the process, and send out emails with working links, along with an apology to your customers.Rhizome
N
8

The way Windows has generated GUIDs has changed several times, and lots of seemingly reliable advice on the internet is completely wrong (maybe just out of date, maybe always completely wrong).

The last time I looked into this (a few years ago, probably XP SP2), I stepped right down into the OS code to see what was actually happening, and it was generating a random number with the secure random number generator.

I doubt you'll have much luck predicting one GUID from another if you generated them in the default way.

Neophyte answered 3/5, 2009 at 14:6 Comment(4)
Have you got any sources for this? That is, why should I take your word for it because this post is "on the internet" too. Can you definitely confirm that .NET 4.5 and MS SQL server use this OS function?Konstantin
@Konstantin Well, it tells you how I came to my conclusion, which was to step into Windows with a debugger - there's nothing stopping you doing this. The source for .NET is available too (or trivially decompilable anyway), so you can check that out as well. My point is mainly that most 'definitely confirmed' statements about this need a precise qualification as to exactly what versions of what they apply to.Neophyte
I've asked this as a new question which I'd like to invite you to answer if you're interested in posting a canonical answer on the subject? No problem if not. Thanks.Konstantin
Windows 2000 and later uses a cryptorandom algorithm for v4 guids. (Source: msdn.microsoft.com/en-us/library/…) That being said you should never use a guid for crypto, Just use RNGCryptoServiceProvider (.NET) or similar directly which is what it was intended for. Even if you understand that .NET GUIDs use a CSPRNG, other guid algorithms don't, by using a GUID you are signalling they are safe everywhere and they are most definitely not.Allegra
T
3

First of all you need to know if they are RFC4122-compliant, and you need to get the version.

If it's UUIDv1, you can predict them

An UUIDv1 is made of :

  • A timestamp (100-ns intervals since the gregorian calendar epoch)
  • A version (1) nibble
  • Two (or three, lol) bits for the RFC4122 compliance (this causes a nibble to be in [89ab])
  • A clock id (random bits)
  • A node id (constant 6 bytes mask)

You just have to iterate over the possible timestamps. Beware, there are a lot of 100-ns intervals out there!

Some software are generating UUIDv1 (Grafana dashboards IDs, Airbnb listings, etc.) but some software are relying on random UUIDs, UUIDv4.

If it's UUIDv4, you might steal the PRNG context

As demonstrated a while ago by Nikolay «denish» Denishchenko (Kaspersky), given a debugging access to the process generating UUIDs, one can steal the current RC4 contexts and reproduce elsewhere up to 500000 UUIDs. This has been demonstrated (hi, Will Dean) on Microsoft Windows XP which used a funny 8*RC4 mechanism and only seeded with actual entropy every 500000 UUIDs.

On Windows 10 (it's not exactly the Windows version but rather the .NET framework or the rpcrt4.dll version), it's not RC4 anymore but an AES, presumably used in CTR mode. There is presumably the same entropy reuse.

For more information, check the work I did there https://uuid.pirate-server.com/blog/

Towardly answered 3/12, 2018 at 4:47 Comment(0)
S
1

There are several different types of guids. Type 1 uses a host ID - usually a mac address - a sequence number, and the current date and time. Type 4 is entirely random. If it's a type 1 UUID, you can probably figure out a fairly restricted set of likely UUIDs, but even so, you're not going to be able to generate a single sequence of UUIDs, so you won't be able to pin down a specific UUID to a specific user.

Stilbite answered 3/5, 2009 at 13:59 Comment(1)
Type 4 is random, but there's nothing in the spec to say this randomness is cryptographically secure - this is down to implementation.Konstantin
F
0

Predicting the next GUID would be unreliable even if you could do it, but more than likely is completely impossible with the resources at your disposal.

Your best bet here is to simply add a manual redirect from any non-matching GUID to a generic page that either explains what went wrong or just programmatically figures out where they should have ended up and sends them there.

Fredrickafredrickson answered 6/5, 2009 at 18:17 Comment(0)
D
-1

Part of a GUID is the current date/time. If you happen to receive two of them sequentially, then you can tell how fast they are being created and therefore predict the sequence with strong confidence.

Disarmament answered 3/5, 2009 at 12:31 Comment(1)
only if they are type 1 GUIDs.Fissiparous

© 2022 - 2024 — McMap. All rights reserved.