3 ms·

Agreed. And the reason here for using UUIDs is not accurate. UUIDs are for having multiple systems (or components) create IDs and having a reasonable expectatio

Agreed. And the reason here for using UUIDs is not accurate. UUIDs are for having multiple systems (or components) create IDs and having a reasonable expectation for uniqueness, hence the Universal Unique part. It grinds my gears when people sneer at integers when they perform optimally or nearly optimally on the majority of use cases.

drumdance 10y ago
Integer IDs are definitely easier, but I've seen it cause so many security issues -- "hmm, I wonder what happens if I manually type in /user/239?" IME It's easier to teach junior devs not to use integers than it is to get them to think holistically about security. This relates to the "sometimes security by obscurity is okay" post from yesterday.
- sshykes 10y ago
  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 10y ago
    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 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 10y ago
      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 10y ago
        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 10y ago
      You can use hashids for this problem [0] This just "encrypts" the primary key with a given salt. [0] http://hashids.org/ http://hashids.org/
  - kbenson 10y ago
    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 10y ago
    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 10y ago
      Shouldn't this risk be mitigated with authorization rules? Or do we assume we are delivering pages without any type of auth first?
      - dennisgorelik 10y ago
        You should allow to reset password to the users without authentication (and therefore without authorization). That's the nature of password reset link.
        sopooneo 10y ago
        Oh of course. Good point.
  - drumdance 10y ago
    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.
- horshod 10y ago
  I have faced this issue in my web application. My solution is to use a UUID wherever the ID will be exposed to the user (only one place in my application) and use an integer ID everywhere else. Although this does mean 2 IDs need to be generated and stored. The other solution is to never allow access to users without a log in.
  - naasking 10y ago
    You can avoid the need for two IDs if you HMAC the URL. There's a single private key on the server used to generate and verify the MAC on subsequent requests.
- mgranda 10y ago
  Can you link to this post? This is a topic that interests me and I'm on mobile :(
  - parenthephobia 10y ago
    https://news.ycombinator.com/item?id=11854576 https://news.ycombinator.com/item?id=11854576
- vectorpush 10y ago
  > IME It's easier to teach junior devs not to use integers than it is to get them to think holistically about security. IMO, explicitly prohibiting unauthorized access to an API endpoint is a basic security tenant, not a "holistic" one. if iterating through an API's integer key sequence results in unauthorized access to data, replacing the integers with UUIDs only masks the problem and I'd say is a classic example of how relying on obscurity for security can be a pernicious mistake, especially for a novice developer.
  - drumdance 10y ago
    Yes it is a basic security tenant. But sometimes you're working with a legacy API and/or a bad auth mechanism. Not every project is greenfield or is maintained by senior devs.
- naasking 10y ago
  > Integer IDs are definitely easier, but I've seen it cause so many security issues -- "hmm, I wonder what happens if I manually type in /user/239?" You're misidentifying the actual security problem. Using URLs in this manner requires cryptographically secure random numbers, or my preferred method is to HMAC the URL to sign it's protected parameters. I actually wrote a small library for .NET called Clavis to demonstrate this idea [1]. The MAC acts as the cryptographically secure identifier needed to make the URL unguessable. [1] https://higherlogics-trac.sourcerepo.com/higherlogics_clavis/wiki https://higherlogics-trac.sourcerepo.com/higherlogics_clavis...
olavgg 10y ago
You can also use ZooKeeper to increment the id for distributed systems. If we're talking about a lot of inserts per second, you can increment by a thousand. For example system-A gets id range for 1-1000, system-B gets id range for 1001-2000 and so on.

drumdance 10y ago

Integer IDs are definitely easier, but I've seen it cause so many security issues -- "hmm, I wonder what happens if I manually type in /user/239?" IME It's easier to teach junior devs not to use integers than it is to get them to think holistically about security. This relates to the "sometimes security by obscurity is okay" post from yesterday.

sshykes 10y ago
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 10y ago
  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 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 10y ago
    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 10y ago
      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 10y ago
    You can use hashids for this problem [0] This just "encrypts" the primary key with a given salt. [0] http://hashids.org/ http://hashids.org/
- kbenson 10y ago
  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 10y ago
  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 10y ago
    Shouldn't this risk be mitigated with authorization rules? Or do we assume we are delivering pages without any type of auth first?
    - dennisgorelik 10y ago
      You should allow to reset password to the users without authentication (and therefore without authorization). That's the nature of password reset link.
      - sopooneo 10y ago
        Oh of course. Good point.
- drumdance 10y ago
  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.
horshod 10y ago
I have faced this issue in my web application. My solution is to use a UUID wherever the ID will be exposed to the user (only one place in my application) and use an integer ID everywhere else. Although this does mean 2 IDs need to be generated and stored. The other solution is to never allow access to users without a log in.
- naasking 10y ago
  You can avoid the need for two IDs if you HMAC the URL. There's a single private key on the server used to generate and verify the MAC on subsequent requests.
mgranda 10y ago
Can you link to this post? This is a topic that interests me and I'm on mobile :(
- parenthephobia 10y ago
  https://news.ycombinator.com/item?id=11854576 https://news.ycombinator.com/item?id=11854576
vectorpush 10y ago
> IME It's easier to teach junior devs not to use integers than it is to get them to think holistically about security. IMO, explicitly prohibiting unauthorized access to an API endpoint is a basic security tenant, not a "holistic" one. if iterating through an API's integer key sequence results in unauthorized access to data, replacing the integers with UUIDs only masks the problem and I'd say is a classic example of how relying on obscurity for security can be a pernicious mistake, especially for a novice developer.
- drumdance 10y ago
  Yes it is a basic security tenant. But sometimes you're working with a legacy API and/or a bad auth mechanism. Not every project is greenfield or is maintained by senior devs.
naasking 10y ago
> Integer IDs are definitely easier, but I've seen it cause so many security issues -- "hmm, I wonder what happens if I manually type in /user/239?" You're misidentifying the actual security problem. Using URLs in this manner requires cryptographically secure random numbers, or my preferred method is to HMAC the URL to sign it's protected parameters. I actually wrote a small library for .NET called Clavis to demonstrate this idea [1]. The MAC acts as the cryptographically secure identifier needed to make the URL unguessable. [1] https://higherlogics-trac.sourcerepo.com/higherlogics_clavis/wiki https://higherlogics-trac.sourcerepo.com/higherlogics_clavis...

olavgg 10y ago

You can also use ZooKeeper to increment the id for distributed systems. If we're talking about a lot of inserts per second, you can increment by a thousand. For example system-A gets id range for 1-1000, system-B gets id range for 1001-2000 and so on.