4 ms·

I don't know. The leaking of information via time-based identifiers always strikes me as an annoying trade-off to work around an implementation detail in certai

by lucumo 3y ago

I don't know. The leaking of information via time-based identifiers always strikes me as an annoying trade-off to work around an implementation detail in certain database engines. Sometimes you have to do it, but it shouldn't be a general rule.

thomasmg 3y ago
UUIDs are globally unique (unique with such a high probability that in practise there are no collisions, if you follow the spec). But they are not cryptographically safe. So the time part is not a "leak" in this sense. If you need something cryptographically safe, then you would need to encrypt the UUID.
- lucumo 3y ago
  The time part is absolutely a disclosure of information. That can be fine, or it may not be. In the latter case that's called a leak. You need to consider that every time you decide to use a time-based identifier like UUIDv7. UUIDv4 contains no information, so you cannot accidentally leak information through them. UUIDs have nothing to do with cryptography. "Cryptographically safe" has no meaning when it comes to identifiers. Encrypting information-carrying identifiers like UUIDv7 is not a good way to hide the information, because you cannot rotate the key if/when it leaks. The moment your key leaks, all information in the identifier is public again. There's only three ways to mitigate the risk of information-carrying identifiers: * Don't have them. Use fully random identifiers instead. * Don't share them. Use a different identifier in public (including in URLs). * Carefully consider the information carried in the identifier to decide if the information can be made public.
- lazide 3y ago
  If anything returns/uses the generated UUID where it is visible to the end user - which is typical, say in a UI or API - then you can know when that thing was created. Which could be a problem info leak wise. For one similar example with sequentially generated IDs - https://www.albert.io/blog/german-tank-problem-explained-ap-statistics-review/#:~:text=In%20World%20War%20II%2C%20each,machinery%20in%20the%20German%20arsenal https://www.albert.io/blog/german-tank-problem-explained-ap-....

by lucumo 3y ago

thomasmg 3y ago

UUIDs are globally unique (unique with such a high probability that in practise there are no collisions, if you follow the spec). But they are not cryptographically safe. So the time part is not a "leak" in this sense. If you need something cryptographically safe, then you would need to encrypt the UUID.

lucumo 3y ago
The time part is absolutely a disclosure of information. That can be fine, or it may not be. In the latter case that's called a leak. You need to consider that every time you decide to use a time-based identifier like UUIDv7. UUIDv4 contains no information, so you cannot accidentally leak information through them. UUIDs have nothing to do with cryptography. "Cryptographically safe" has no meaning when it comes to identifiers. Encrypting information-carrying identifiers like UUIDv7 is not a good way to hide the information, because you cannot rotate the key if/when it leaks. The moment your key leaks, all information in the identifier is public again. There's only three ways to mitigate the risk of information-carrying identifiers: * Don't have them. Use fully random identifiers instead. * Don't share them. Use a different identifier in public (including in URLs). * Carefully consider the information carried in the identifier to decide if the information can be made public.
lazide 3y ago
If anything returns/uses the generated UUID where it is visible to the end user - which is typical, say in a UI or API - then you can know when that thing was created. Which could be a problem info leak wise. For one similar example with sequentially generated IDs - https://www.albert.io/blog/german-tank-problem-explained-ap-statistics-review/#:~:text=In%20World%20War%20II%2C%20each,machinery%20in%20the%20German%20arsenal https://www.albert.io/blog/german-tank-problem-explained-ap-....