3 ms·

UUIDs have always seemed to be an over-engineered solution to a minor problem. In the cases I've seen them used folks are trying to get away from auto-increment

UUIDs have always seemed to be an over-engineered solution to a minor problem. In the cases I've seen them used folks are trying to get away from auto-incremented identifying serial numbers. Ostensibly, this is because it makes guessing other IDs in the database (or whatever) fairly simple and that could be a source for leaking information. 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.

preseinger 4y ago
At a minimum, sequential generated IDs trivially expose creation rate, which is almost always significant information.
chrismorgan 4y ago
> 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 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.
GoblinSlayer 4y ago
>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.
nly 4y ago
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.

preseinger 4y ago

At a minimum, sequential generated IDs trivially expose creation rate, which is almost always significant information.

chrismorgan 4y ago

> 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 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.

GoblinSlayer 4y ago

>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.

nly 4y ago

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.