3 ms·
One reason to not do that is because you could then figure out other users IDs by their hiring date. This ended up being a problem for me once with the auxiliar
by bongodongobob 2y ago
One reason to not do that is because you could then figure out other users IDs by their hiring date. This ended up being a problem for me once with the auxiliary systems that relied on that ID, namely when it was used in links in other applications.
- deleted 2y ago[deleted]
- tadfisher 2y agoAnother reason is sharding, in which case any non-random (to be more precise, non-uniformly distributed) bits are going to skew the partitions.
- eddd-ddde 2y agoWhy is knowing someone's ID an issue? They are meant for identification, if anything it should be a benefit that they are easily guessable.
- selcuka 2y ago> Why is knowing someone's ID an issue? It increases the attack surface as an authorization vulnerability will allow an attacker to enumerate and access all records. Yes, it is security through obscurity, but a random (e.g. UUID) scheme makes it harder.
- kubanczyk 2y ago~128 bits worth of obscurity is considered real security for the time being. Assuming a cryptographically secure PRNG. Thats like guessing a password 18 ASCII chars long.
- selcuka 2y ago> ~128 bits worth of obscurity is considered real security for the time being. Sure, what I meant was UUIDs are not supposed to be confidential information, unlike passwords. They are exposed in URLs and whatnot.
- bongodongobob 2y agoExactly, it's not that my systems use security through obscurity, it's the other ones mine ties into. This was years ago and you don't see it as much anymore, but think autogenerated links to shitty CRM, ticketing, and project management software where the link is the query aka - Blahsoftware.local/info/bunchofgarbage?=userid+garbage+view+sensitiveinfo.html type stuff.