Hacker News Reader

Comment by fastball | Hacker News Reader

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.

View on HN

I couldn't agree more!

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.

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

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.

That's hyperbolic. If your table ID poses security risks like a social security number, you've designed your system horribly wrong.

It’s like one small bug that lets you move sideways to you can use a bigger and better one.

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.

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.

Reply on news.ycombinator.com