Re:Plan B for UUIDs: double AES-128
by chrismorgan on Friday August 05, 2022 @01:43PM
(#32359387)
> Just because I know an identifier doesn't mean I should be able to do _anything_ with it.
Depends. If it’s a sequential ID, then sure, but if it’s sufficiently random and sparse, then it can be fine to use it as authentication.
But it’s not always about authentication and security. The information leak itself is regularly a problem. See https://en.wikipedia.org/wiki/German_tank_problem for one practical example, though you normally don’t even need anything that fancy. Businesses do this where they can to analyse competitors, figure out how big they are, how they should price things, &c.
Re:Plan B for UUIDs: double AES-128
by preseinger on Friday August 05, 2022 @01:39PM
(#32359331)
At a minimum, sequential generated IDs trivially expose creation rate, which is almost always significant information.
If it was easier to have scoped id's it wouldn't be so bad. For example, instead of one OrderID for all orders in the order table, have customer specific order numbers that start at 1, and are only unique in tandem with a customer id.
It's a pain in the but to implement this though in most databases.
Re:Plan B for UUIDs: double AES-128
by GoblinSlayer on Friday August 05, 2022 @03:01PM
(#32360442)
>If there are contexts where you really can't share the ID you should salt and hash it and use that value.
That's UUIDv5.
To me this is just security though obscurity. Just because I know an identifier doesn't mean I should be able to do _anything_ with it. If there are contexts where you really can't share the ID you should salt and hash it and use that value.