Interesting project... just out of curiosity, could you give something resembling a couple practical examples of the risk of exposing the time portion of a v7 UUID?
Interesting project... just out of curiosity, could you give something resembling a couple practical examples of the risk of exposing the time portion of a v7 UUID?
Suppose it's something where the user may be accused of doing something nefarious if a sequence or pattern of behavior is exposed.
- "Ex-spouse: I looked you up on a dating website, and your userID indicates it was created while you were at Tom's party where you swear nothing happened."
- "You say you are in XYZ timezone, but all your imageIDs (that are unique to the image upon creation) are timestamped at what would be 3am in your timezone)"
Granted, for individual messages that are near-real-time, or for transactions that need to be timestamped anyway, it's probably fine, but for user-account-creation or "evergreen" asset-creation, it could leak the time to a sufficiently curious individual (or an organized group that is doing data-trawling and cross-correlation)
> - "You say you are in XYZ timezone, but all your imageIDs (that are unique to the image upon creation) are timestamped at what would be 3am in your timezone)"
Can you expand on this? I don't see a situation where it's actually leaking. You either have a photo with EXIF or an image post were generated when post is created and created_at usually exposed.
I've done CTFs in that past where a UUID is used to brute force an AES key. As the key was derived partially from the time source so by knowing the system time close to when the data was encrypted you could pretty easily brute force the key.
A more simple example is a URL for say a file / photo share service. You allow users to upload images, and you return them back website.com/GUID. That's it. You don't provide a way to see when that photo / file was updated, but because you use a UUIDv7 you just did.
Is this a security risk? Maybe or maybe not? But it's an unintended disclosure of information.
Let's say you've got a system that collects medical data - like "store the results of the MRI right after it happens".
For analysis reasons, you want to share this dataset (e.g. for diagnostics on the machine) but first must strip it of potentially identifying information.
The uuidv7 timestamp could be used to re-identify the data through correlation - "I know this person got an MRI on this day, there's only one record with a matching datestamp, thus I know it's their MRI."
Fair enough, thanks... I've got more experience in education/elearning, banking and elections, all of which are likely to have separate timestamp records required anyway, so this kind of scenario didn't really jump out at me.
I'm not sold on this example. If you're already preprocessing data for analysis purposes, why not just remove the ID altogether? I can't imagine a specific record ID being required for analytics
[dead]
Good example.
It's pretty simple, unless when you provide a GUID to a party you are also willing to provide the timestamp when it was created, use UUIDv4.