4 ms·

Nothing wrong with auto incrementing identifiers if actual security controls (authorization) are implemented for already authenticated users.

yardstick 5y ago
Sequential is still bad if you don’t want to disclose the size of your customer base or other commercially sensitive information. Also see the German Tank Problem[1]. 1. https://en.m.wikipedia.org/wiki/German_tank_problem https://en.m.wikipedia.org/wiki/German_tank_problem
- jgalt212 5y ago
  true, but if you do sequential for users and free trials, the information leakage can be close to zero. Think about if all those AOL CDs were sequentially numbered.
  - SahAssar 5y ago
    That's not zero information leakage. That's just leaking another statistic that is somewhat correlated to the one you want to hide (you're leaking the production of trial AOL CDs, and production of trial AOL CDs have some correlation to number of new users).
- jbluepolarbear 5y ago
  Don’t return indexes with user queries.
  - wongarsu 5y ago
    Usually you need some external unique identifier so you can interact with the object. Sure, that doesn't have to be the db index, but it is the convenient choice
    - azinman2 5y ago
      Except when you want to change databases, or grow beyond a single one, or shard what you have. If you do this you’re binding your future self.
- bitexploder 5y ago
  Am aware. Still don’t think it’s worth the hassle for most situations. Can leak information, but context is really important. I have rarely seen it be an issue over many years of app assessments. Just something to keep in the threat model for when it’s relevant.
  - shalmanese 5y ago
    What hassle is it? Where in your codebase do you assume sequentiality? It should be a one line change in your db configs to generate GUIDs instead of ids. You have to do it eventually anyway as sequentiality can't be assumed once you shard.
    - bitexploder 5y ago
      Depends on the needs I suppose. I don’t like starting off with GUIDs until it’s proven they are needed, because, as you say, it’s a simple change. Sharing does complicate the picture, but how many apps really need sharding.
      - sangnoir 5y ago
        > I don’t like starting off with GUIDs until it’s proven they are needed For security incidents, "when they are needed" will be too late to do anything. If it's all the same to you, I'd advise that you default to GUIDs.
  - yardstick 5y ago
    There was one wireless ISP many years ago in a city I lived in that had a signal/reception page to see your signal to their closet tower. The URL included the customer number to identify your location. I quickly discovered it had no authorisation checks. You could easily find the exact addresses of all of their customers. Inactive/old customers returned no data.
sangnoir 5y ago
If you follow the "defense in depth" paradigm, then sequential identifiers bad when the other controls are defeated. Sequential ID make it trivial to crawl the entire dataset - which could be the difference between "Information on 4 million users was stolen" and "information from 4 users was stolen"

yardstick 5y ago

Sequential is still bad if you don’t want to disclose the size of your customer base or other commercially sensitive information. Also see the German Tank Problem[1]. 1. https://en.m.wikipedia.org/wiki/German_tank_problem https://en.m.wikipedia.org/wiki/German_tank_problem

jgalt212 5y ago
true, but if you do sequential for users and free trials, the information leakage can be close to zero. Think about if all those AOL CDs were sequentially numbered.
- SahAssar 5y ago
  That's not zero information leakage. That's just leaking another statistic that is somewhat correlated to the one you want to hide (you're leaking the production of trial AOL CDs, and production of trial AOL CDs have some correlation to number of new users).
jbluepolarbear 5y ago
Don’t return indexes with user queries.
- wongarsu 5y ago
  Usually you need some external unique identifier so you can interact with the object. Sure, that doesn't have to be the db index, but it is the convenient choice
  - azinman2 5y ago
    Except when you want to change databases, or grow beyond a single one, or shard what you have. If you do this you’re binding your future self.
bitexploder 5y ago
Am aware. Still don’t think it’s worth the hassle for most situations. Can leak information, but context is really important. I have rarely seen it be an issue over many years of app assessments. Just something to keep in the threat model for when it’s relevant.
- shalmanese 5y ago
  What hassle is it? Where in your codebase do you assume sequentiality? It should be a one line change in your db configs to generate GUIDs instead of ids. You have to do it eventually anyway as sequentiality can't be assumed once you shard.
  - bitexploder 5y ago
    Depends on the needs I suppose. I don’t like starting off with GUIDs until it’s proven they are needed, because, as you say, it’s a simple change. Sharing does complicate the picture, but how many apps really need sharding.
    - sangnoir 5y ago
      > I don’t like starting off with GUIDs until it’s proven they are needed For security incidents, "when they are needed" will be too late to do anything. If it's all the same to you, I'd advise that you default to GUIDs.
- yardstick 5y ago
  There was one wireless ISP many years ago in a city I lived in that had a signal/reception page to see your signal to their closet tower. The URL included the customer number to identify your location. I quickly discovered it had no authorisation checks. You could easily find the exact addresses of all of their customers. Inactive/old customers returned no data.

sangnoir 5y ago

If you follow the "defense in depth" paradigm, then sequential identifiers bad when the other controls are defeated. Sequential ID make it trivial to crawl the entire dataset - which could be the difference between "Information on 4 million users was stolen" and "information from 4 users was stolen"