131–140 of 376 posts
Earlier quoted context omitted.
Because in SPAs if a user creates new entities it can be easier to generate the UUIDs client side. So then just a simple validation server side to ensure the data isn't malicious.
Never trust the client.
Earlier quoted context omitted.
I feel like it's well beyond the scope of UUIDs to get into "are your clocks really monotonic?". They give you 48 bits for a timestamp, what that timestamp signifies (transactional time, valid time...) and how that's generated is up to you. Out of curiosity, are you into hybrid logical clocks?
I only raise this when I see promises that IDs are ordered and can be sorted , not merely grouped by approximate time for storage locality. Yeah, though I’m more likely to go with a region ID and monotonic version number to compare-and-set and verify gapless data, where versions from different regions aren’t comparable. Actually I think earlier UUID RFCs talk about a “clock sequence” to distinguish timestamps from se…
So any thing you can link, let me know.
I am confused how this is new. UUIDv1 is time based, you just need to be careful about entropy, and in MySQL 8 you can for a longish time use it as an ordered field.
The use of a MAC address and fine grained timestamp are challenges of UUIDv1. https://blog.devgenius.io/analyzing-new-unique-identifier-fo...
Earlier quoted context omitted.
Thinking that harder-to-guess IDs will mitigate attacks is an example of security by obscurity. It's better to think of any IDs in your database as being public knowledge, because they will leak anyway. Assuming that no one can guess another ID leads to shoddy practices. I generally keep IDs sequential and build security around the basic assumption that IDs are not keys, passwords, sessions, or secrets - they're just…
Doesn't that still leak (statistical) information? It may not be technically security, but e.g. knowing your competitor just added N products to their shop, might be a security issue for the business.
This is great for internal distributed systems where having ordered keys is useful, however, it should probably be noted that these probably shouldn't be used as public identifiers (even though this will probably be the defacto standard and used publicly without thought). Having any information, specifically time information, leaking from your systems may or may not have unanticipated security or business implication…
Given that a UUID identifier fits in a single cipher block, and the whole point is that these are unique by construction (no IV needed so long as that holds true), it seems like a single round of ECB-mode AES-128 would enable quickly converting between internal/external identifiers. 128 bits -> 128 bits
Why not just hash it with pretty much any hash function?
Earlier quoted context omitted.
What benefice over uuid4 ?
There's a comparison in the README of the project: https://github.com/paralleldrive/cuid2#the-contenders Some of the arguments mentioned are explained elsewhere in the README, others are assumed. One argument standing out for me is the lack of collision-resistance for UUIDv4 which is surprising for me and I didn't spot any sources for that argument. Another argument is the entropy source where they go about that Math…
Collision of UUIDV4 (which are 122 bits of entropy) are unlikely enough that it should fit most definitions of the word "impossible".
The argument listed in this library README feels like total bullshit to me, I'd avoid using it for this reason alone.
This is great for internal distributed systems where having ordered keys is useful, however, it should probably be noted that these probably shouldn't be used as public identifiers (even though this will probably be the defacto standard and used publicly without thought). Having any information, specifically time information, leaking from your systems may or may not have unanticipated security or business implication…
Given that a UUID identifier fits in a single cipher block, and the whole point is that these are unique by construction (no IV needed so long as that holds true), it seems like a single round of ECB-mode AES-128 would enable quickly converting between internal/external identifiers. 128 bits -> 128 bits
If AES-128 is an acceptable external UUID (and likely an acceptable internal one), then you might as well just stick with a faster RNG.
Earlier quoted context omitted.
Given that a UUID identifier fits in a single cipher block, and the whole point is that these are unique by construction (no IV needed so long as that holds true), it seems like a single round of ECB-mode AES-128 would enable quickly converting between internal/external identifiers. 128 bits -> 128 bits
This seems overly complex, and you need some kind of key too. Why not just hash it with pretty much any hash function?