5 ms·

People definitely rely on the number of bits in v4 for security. I wonder what are some use cases where you can't rely on v7 for security?

vore 3y ago
When you need to generate IDs that don't reveal when they were generated.
- vbezhenar 3y ago
  For this case just add random(0, 2^128/N) to the previous UUID. N*2 is average number of ascending UUIDs you want to maintain for database performance. If N is low enough (like 1024), database will be happy and UUIDs will be pretty random and won’t reveal much. There won’t be global ordering, but it leaks timing information in one way or another, anyway.
  - hn_throwaway_99 3y ago
    The ascending order of IDs though is a great property that is used in other contexts. I.e. for many of our workflow processes we want queries to return reverse chronological order, and "ORDER BY id DESC" is our most common sort. A v7 UUID as a primary key is still great for that, so you'd usually want to keep that property.
- JdeBP 3y ago
  Daniel J. Bernstein addressed this the 1990s: * Construct a tuple of the current TAI64NA time, the process ID, some other IDs, and a sequence number. * Encrypt this 384-bit tuple with a 1024-bit secret using SURF. * The 256-bit result is the ID. https://github.com/bruceg/ezmlm-idx/blob/master/lib/surf.3 https://github.com/bruceg/ezmlm-idx/blob/master/lib/surf.3 One could adapt this approach to UUIDs.
  - tadfisher 3y ago
    This eliminates the primary benefit of V7 UUIDs, which is that keys sort temporally, which is almost always the same as the insertion order of a database table (or most collection-like data structures(
    - JdeBP 3y ago
      But satisfies, as v7 does not satisfy, the actually stated constraint of "IDs that don't reveal when they were generated" whilst still using timestamps, no permanent IDs from hardware, and no centralized ticket-issuing mechanism for sequence numbers. There is more than one feature of v7, and the top of this sub-thread started a discussion of how one would trade them for better security.
hn_throwaway_99 3y ago
People rely on v4 UUIDs for things like session tokens, where the unguessability of the ID is ensured by the amount of randomness it has. You shouldn't use a v7 UUID here because it has considerably less entropy. However, for object retrieval (e.g. "show me my accounts with object IDs X, Y and Z"), you shouldn't be just relying on the unguessability of the ID anyway - you should be using appropriate access control permission checks (because for object IDs even if they are unguessable they are frequently not guaranteed to be private, e.g. they show up in log files, they may be in URLs that people share, etc., and they don't expire, unlike a session ID). A frequent source of severe security vulnerabilities are bugs in these access control checks, which can lead to insecure direct object reference (IDOR) vulnerabilities, where I can say "Show me account with ID X" even though I don't own or have permissions to that account. If you're using incrementing integer IDs for your object IDs here, abusing this bug is trivially easy - just walk up and down the IDs next to yours. I think it was the Parler app that had a particularly egregious case of this - they weren't doing any access control checks on posts at all. However, if your object ID is a v7 UUID, this bug becomes much more difficult to abuse, because your IDs may not be completely unguessable to a strong adversary, but you should be able to detect the failed access attempts when you see someone trying billions of access attempts and only getting not found errors (of course, you should be rate limiting these attempts in the first place).

vore 3y ago

When you need to generate IDs that don't reveal when they were generated.

vbezhenar 3y ago
For this case just add random(0, 2^128/N) to the previous UUID. N*2 is average number of ascending UUIDs you want to maintain for database performance. If N is low enough (like 1024), database will be happy and UUIDs will be pretty random and won’t reveal much. There won’t be global ordering, but it leaks timing information in one way or another, anyway.
- hn_throwaway_99 3y ago
  The ascending order of IDs though is a great property that is used in other contexts. I.e. for many of our workflow processes we want queries to return reverse chronological order, and "ORDER BY id DESC" is our most common sort. A v7 UUID as a primary key is still great for that, so you'd usually want to keep that property.
JdeBP 3y ago
Daniel J. Bernstein addressed this the 1990s: * Construct a tuple of the current TAI64NA time, the process ID, some other IDs, and a sequence number. * Encrypt this 384-bit tuple with a 1024-bit secret using SURF. * The 256-bit result is the ID. https://github.com/bruceg/ezmlm-idx/blob/master/lib/surf.3 https://github.com/bruceg/ezmlm-idx/blob/master/lib/surf.3 One could adapt this approach to UUIDs.
- tadfisher 3y ago
  This eliminates the primary benefit of V7 UUIDs, which is that keys sort temporally, which is almost always the same as the insertion order of a database table (or most collection-like data structures(
  - JdeBP 3y ago
    But satisfies, as v7 does not satisfy, the actually stated constraint of "IDs that don't reveal when they were generated" whilst still using timestamps, no permanent IDs from hardware, and no centralized ticket-issuing mechanism for sequence numbers. There is more than one feature of v7, and the top of this sub-thread started a discussion of how one would trade them for better security.

hn_throwaway_99 3y ago

People rely on v4 UUIDs for things like session tokens, where the unguessability of the ID is ensured by the amount of randomness it has. You shouldn't use a v7 UUID here because it has considerably less entropy. However, for object retrieval (e.g. "show me my accounts with object IDs X, Y and Z"), you shouldn't be just relying on the unguessability of the ID anyway - you should be using appropriate access control permission checks (because for object IDs even if they are unguessable they are frequently not guaranteed to be private, e.g. they show up in log files, they may be in URLs that people share, etc., and they don't expire, unlike a session ID). A frequent source of severe security vulnerabilities are bugs in these access control checks, which can lead to insecure direct object reference (IDOR) vulnerabilities, where I can say "Show me account with ID X" even though I don't own or have permissions to that account. If you're using incrementing integer IDs for your object IDs here, abusing this bug is trivially easy - just walk up and down the IDs next to yours. I think it was the Parler app that had a particularly egregious case of this - they weren't doing any access control checks on posts at all. However, if your object ID is a v7 UUID, this bug becomes much more difficult to abuse, because your IDs may not be completely unguessable to a strong adversary, but you should be able to detect the failed access attempts when you see someone trying billions of access attempts and only getting not found errors (of course, you should be rate limiting these attempts in the first place).