4 ms·

For good security, you don't leak internal IDs at all, sure. It is rare to find people doing that. And random primary keys (or any key really, and even more so

For good security, you don't leak internal IDs at all, sure. It is rare to find people doing that. And random primary keys (or any key really, and even more so for clustered indexes PK) really trash a db cache and locking systems.

fastball 3y ago
IDs should just be IDs. You should be able to hand out your IDs on the street corner without compromising security. If knowing IDs has a negative impact on security, you've designed your system improperly.
- rizky05 3y ago
  An ID is like social security number. When you give it away on the street corner, who knows what other people will do with it. IMHO, leaking an ID always impose a risk. It is always have negative impact if leaked, no matter how perfect your system is.
  - siva7 3y ago
    That's hyperbolic. If your table ID poses security risks like a social security number, you've designed your system horribly wrong.
    - sroussey 3y ago
      It’s like one small bug that lets you move sideways to you can use a bigger and better one.
  - ryanbrunner 3y ago
    You're almost always going to have to leak some sort of ID in an API, otherwise your API is going to be exceptionally hard to work with. You could choose to have a separate external ID, but provided that knowledge of an internal ID doesn't convey any information or additional privilege, it's not that big a deal.
  - int_19h 3y ago
    The only reason why people can do dangerous things with an SSN is because it's used for authorization - i.e. as a secret - not just as ID. That's broken by design, but there's no reason to repeat that design.
- lazy_moderator1 3y ago
  I couldn't agree more!
- sroussey 3y ago
  No. While it’s no longer on ranks on the top 10 web vulnerabilities, gaining internal insight to systems is one of first things you do when infiltrating. But people are messy and lazy. Nowadays, you ask for GDPR data and people give you CSVs with all their real table and column names. Sometimes when you are just a little inside, figuring out an id is like figuring out a password (particularly with uuid as opposed to a sequence). Real nice if it leaks easily.
  - fastball 3y ago
    Again, if knowing an ID allows someone to unfiltrate your systems, you've designed things poorly. IDs are not keys, and they should never be treated as such (looking at you, US Social Security numbers).
siva7 3y ago
> For good security, you don't leak internal IDs at all, sure. It is rare to find people doing that. We must live in a different universe. I'd wager to say that over 90% of all backends leak their primary key when speaking to the front-facing client.
- teaearlgraycold 3y ago
  99.9%
- CognitiveLens 3y ago
  I think the statement was "It is rare to find people doing good security", not "It is rare to find people leaking internal IDs"
  - emaro 3y ago
    I read it as '[…] you don't leak internal IDs at all […]. It is rare to find people doing that [i.e. not leaking internal IDs]'
  - sroussey 3y ago
    Yeah, sorry not clear. Typing on iPhone never really gets the message across as clearly as using a PC
- deleted 3y ago
  [deleted]
mort96 3y ago
> And random primary keys (or any key really, and even more so for clustered indexes PK) really trash a db cache and locking systems. That sounds like a problem which should be solved by making database engines not assume keys have some sane ordering, not by putting timestamps in UUIDs.
- jandrewrogers 3y ago
  This is mostly correct but primary keys have to co-exist with the existing data infrastructure that is unlikely to be replaced for decades. It is quite possible to do cluster-style indexing on UUIDs through disk on a single server at rates of tens of millions per second, I do it every day, just not with your typical ordered-tree architectures. Many popular database engines are not designed to make this particular scenario perform well.

fastball 3y ago

IDs should just be IDs. You should be able to hand out your IDs on the street corner without compromising security. If knowing IDs has a negative impact on security, you've designed your system improperly.

rizky05 3y ago
An ID is like social security number. When you give it away on the street corner, who knows what other people will do with it. IMHO, leaking an ID always impose a risk. It is always have negative impact if leaked, no matter how perfect your system is.
- siva7 3y ago
  That's hyperbolic. If your table ID poses security risks like a social security number, you've designed your system horribly wrong.
  - sroussey 3y ago
    It’s like one small bug that lets you move sideways to you can use a bigger and better one.
- ryanbrunner 3y ago
  You're almost always going to have to leak some sort of ID in an API, otherwise your API is going to be exceptionally hard to work with. You could choose to have a separate external ID, but provided that knowledge of an internal ID doesn't convey any information or additional privilege, it's not that big a deal.
- int_19h 3y ago
  The only reason why people can do dangerous things with an SSN is because it's used for authorization - i.e. as a secret - not just as ID. That's broken by design, but there's no reason to repeat that design.
lazy_moderator1 3y ago
I couldn't agree more!
sroussey 3y ago
No. While it’s no longer on ranks on the top 10 web vulnerabilities, gaining internal insight to systems is one of first things you do when infiltrating. But people are messy and lazy. Nowadays, you ask for GDPR data and people give you CSVs with all their real table and column names. Sometimes when you are just a little inside, figuring out an id is like figuring out a password (particularly with uuid as opposed to a sequence). Real nice if it leaks easily.
- fastball 3y ago
  Again, if knowing an ID allows someone to unfiltrate your systems, you've designed things poorly. IDs are not keys, and they should never be treated as such (looking at you, US Social Security numbers).

siva7 3y ago

> For good security, you don't leak internal IDs at all, sure. It is rare to find people doing that. We must live in a different universe. I'd wager to say that over 90% of all backends leak their primary key when speaking to the front-facing client.

teaearlgraycold 3y ago
99.9%
CognitiveLens 3y ago
I think the statement was "It is rare to find people doing good security", not "It is rare to find people leaking internal IDs"
- emaro 3y ago
  I read it as '[…] you don't leak internal IDs at all […]. It is rare to find people doing that [i.e. not leaking internal IDs]'
- sroussey 3y ago
  Yeah, sorry not clear. Typing on iPhone never really gets the message across as clearly as using a PC
deleted 3y ago
[deleted]

mort96 3y ago

> And random primary keys (or any key really, and even more so for clustered indexes PK) really trash a db cache and locking systems. That sounds like a problem which should be solved by making database engines not assume keys have some sane ordering, not by putting timestamps in UUIDs.

jandrewrogers 3y ago
This is mostly correct but primary keys have to co-exist with the existing data infrastructure that is unlikely to be replaced for decades. It is quite possible to do cluster-style indexing on UUIDs through disk on a single server at rates of tens of millions per second, I do it every day, just not with your typical ordered-tree architectures. Many popular database engines are not designed to make this particular scenario perform well.