3 ms·

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 secu

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

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