[sshykes]

Vehemently disagree. What you are proposing is everything wrong with security-by-obscurity.

In this case the security hole of /user/123 just needs to be properly locked down. That is all.

[davidw]

I mostly use integers (but see my comment elsewhere). There is most definitely a german tank problem involved in them, though:

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

For most things I do, it's not a concern, but it is something to keep in mind.

[mercer]

In which cases would this be a German tank problem for you? I can think of apps where you want investors or something, but I can't help but wonder if they'd be savvy enough to check for that.

I do know that I try to make my invoices to clients a bit more impressive, because I don't send many of them and they most definitely do notice if they get invoice #3 in May. Main problem is that in my country the rules for invoices are both murky and stringent, so I'm pretty much limited to a <year>0000<invoice no.> format.

[davidw]

Well if you have an 'order #', your competition can make an order a week and see how many other orders you've gotten in the meantime.

> in my country the rules for invoices are both murky and stringent,

I sympathize, as the rules were like that in Italy, where I lived for a long time.

[fotcorn]

You can use hashids for this problem [0] This just "encrypts" the primary key with a given salt.

[0] http://hashids.org/

[drumdance]

Yes, of course that's what needs to happen. And that's what I do when I'm the one doing the implementation.

But a junior dev just out of code school doesn't necessarily think of this. So when I ask one to build the basic scaffold and db schema I say "make sure you use UUID," then later I show them how security holes like this can manifest.

I've seen this security hole so many times in other sites that I feel like it's a good first principle to limit "guess-ability" in the schema wherever possible.

[kbenson]

Yes. Any time you let a non-associated record be displayed by a user session that is not linked to that record and should not have access to it, that's not a problem of easily guessable keys, that's a problem of not securing data by checking access rights.

[VLM]

password reset email #123 gets url /user/123

password reset email #124 gets url /user/124

password reset email #125 gets url /user/125 but that doesn't work because someone predicted it and got there before the requestor. no idea what account they'll get, but they'll get an account of some type.

This also comes up in shipping records. OK where do we go to steal an XYZ delivered today and sitting on a front porch? Well lets check

/shippinglabel/345

/shippinglabel/346

/shippinglabel/347 oh look delivered today, sitting on back porch step, and the address is right there

Another fun one is online financial documents with sequential accounts.

[sopooneo]

Shouldn't this risk be mitigated with authorization rules? Or do we assume we are delivering pages without any type of auth first?

[dennisgorelik]

You should allow to reset password to the users without authentication (and therefore without authorization).

That's the nature of password reset link.

[sopooneo]

Oh of course. Good point.