Hacker News Reader

Comment by lbriner | Hacker News Reader

Not necessarily. The idea here is that the id can be exposed publically because it is random. The problem it solves is someone sees a page /accountdetails?id=123 and can easily look for /accountdetails?id=124 and assume it is likely to be valid.

If you use a random id, you cannot quickly know what other ids exist which makes looking for unauthorized access to objectids much harder.

View on HN

If there needs to be an auth check for other IDs, then it shouldn't matter whether the IDs are random or not.

Depending on how highly aesthetic URLs are valued, it's not unlikely that after being in business for a while, the density of your keyspace will mean that even random IDs are found.

A better rationale for disconnecting public and private IDs is to make certain types of database migration a little bit easier. I don't think it's a huge win though, it's a chunk of work to maintain multiple IDs, do the required inderictions all the time, ensure public IDs are always sent to front end, and so on, while adding a translation layer as part of a database migration delays this kind of work until it's actually needed, if ever.

https://en.m.wikipedia.org/wiki/German_tank_problem

Preventing competitors from estimating the size of your business (or of your customer's businesses, if generating sequential IDs on their behalf) is one big reason for having unguessable public IDs.

This of course assumes that all the records backed by these IDs are not public information. In a lot of cases, this may not be true.

Unauthorized access is dealt with by implementing correct authorization procedures, not by obfuscating IDs, which valid ones can still be discovered through brute force or other means.

In your example those simple, sequential IDs should have no impact on security.

Reply on news.ycombinator.com