13 ms·

It is simpler but like everything else it depends on the application. For a private app you can generally get away with it. Something that's more public facing?

It is simpler but like everything else it depends on the application. For a private app you can generally get away with it. Something that's more public facing? The ID will most likely leak information. As systems mature and you introduce things like replication, having IDs that are more universal starts looking good. In general, starting off with a uuid like uuid v4 or nanoid is a good bet.

lazide 2y ago
The info leak, specifically, is [https://en.m.wikipedia.org/wiki/German_tank_problem https://en.m.wikipedia.org/wiki/German_tank_problem].
- sgarland 2y ago
  Oh no, someone might know the number of customers, or the rate of signups. Traditional businesses can figure this out by sitting in the parking lot. Why SaaS has decided it’s a huge problem is beyond me.
  - lazide 2y ago
    By sitting in every parking lot, yes. Which requires physical presence. And hedge funds do indeed do it against some targets specifically as a leg up, and pay quite a bit of money to do so, presumably because it is worth it to them. It certainly helped the Allies in the war, as previous intelligence had the rate of tank production much higher, and they were expending a lot of effort trying to exceed that previous false number. Information is power, etc. etc. As to if it's worth it for your SaaS to mitigate is up to you of course. I know I notice when things like Invoice #'s, my userID, customerID, etc. get shown, and it's a small number, or small delta. And that impacts my behavior. Does it also impact someone like a VC’s behavior? Or a competitor? Unknown. But Hell, a bunch of people right now are probably launching SaaS's with NO-OP auth flows for documents or images, or with trivial external SQL injection flaws, which is a way bigger problem. But it doesn't make the vulnerability/problem non-existent. Also feel free to use 16 bit auto incrementing primary keys for all your core tables if you want. But if we're in an engineering discussion on the topic, knowledgeable folks will bring up the issues with it, because that is what they do. Most would feel it is their duty to do it, even.
    - sgarland 2y ago
      > But if we're in an engineering discussion on the topic, knowledgeable folks will bring up the issues with it, because that is what they do. To be clear, this is not directed at you specifically, and I have no idea what your level of expertise is on anything. In general, I’ve found HN commenters level of knowledge to be fairly bimodal. They’re either regurgitating things they read on a Medium blog, or they really know their shit. Every time this topic comes up, people delightedly mention the German Tank Problem, but I have never, not once, seen anyone post an actual example of when a modern business got rekt by a competitor using knowledge gained from monotonic IDs. Re: security viz. AuthZ, my stance is the same as SQL injection – it’s such a trivially easy problem to avoid that it shouldn’t be a consideration for harming the performance of the DB. (Not that SQL injection mitigations cause performance impacts; sorry, that analogy didn’t work well)
      - melody_calling 2y ago
        > Every time this topic comes up, people delightedly mention the German Tank Problem, but I have never, not once, seen anyone post an actual example of when a modern business got rekt by a competitor using knowledge gained from monotonic IDs. At $previous_job (payments provider), the sales engineers would often spot merchants using sequential order IDs and mention it to the account managers. Rekt? I guess not, but knowing what percentage of their business we processed was extremely valuable information when it came to renegotiate the contract.
    - akira2501 2y ago
      > Which requires physical presence. It requires physical access. Presence can be achieved by placing a dash camera or window camera strategically. > and they were expending a lot of effort trying to exceed that previous false number. The idea here being that if the allies just made more tanks than the axis they would automatically win? It's a lionized story of intelligence agency cleverness built squarely on the back of insane military "strategy."
      - lazide 2y ago
  - bruce511 2y ago
    Yes, sure, it leaks some information - but to be fair printing an invoice also leaks information. For me the priority is security. If I get a link (visible or invisible) that contains a numeric ID, there's the possibility to tweak that link with another number. Ideally, the server treats that number as suspect. Every. Single . Time. In practice I only need one developer to miss the check in one place and I have a serious security issue. Like leaking my entire customer list serious. This has happened multiple times -that we know of-. Yes obscurity is not security. But sequential numbers are insecure by design, and it takes a lot of well-maintained walls to protect them. One crack leaves them very vulnerable.
    - sgarland 2y ago
      Call me naïve, but surely you can have fuzzing tests in CI? I’m also going to use this as yet another example of why getting rid of QA in favor of Ship It Now was a bad idea.
      - bruce511 2y ago
        Relying on tests to discover the tortuous path to most security exploits would not be my recommendation.
  - karmajunkie 2y ago
    i mean, you might care if the investors you’re trying to woo for that bridge round figure out your churn is a lot higher than you’re willing to admit… or worse, your traction is terrible.
    - sgarland 2y ago
      How is a monotonically incrementing integer going to reveal churn or traction? You’re not reusing IDs.
      - lazide 2y ago
        Sign up for two accounts over the space of, say, a month. See how big the delta is between the account IDs. That gives you potential traction. If you have access to revenue data (every investor is going to want this first thing), that gives you rough churn too. Do the same for creating users, if you can see user Id’s.
    - sofrimiento 2y ago
      So I should introduce complexity in my application so in the future it might help me dupe potential investors if my startup is not going well? That’s a whole new take on pre-mature optimization. I’d rather not dupe investors, and would rather not introduce unnecessary complexity, instead I’d rather focus on actually delivering value so investors actually want to invest.

lazide 2y ago

The info leak, specifically, is [https://en.m.wikipedia.org/wiki/German_tank_problem https://en.m.wikipedia.org/wiki/German_tank_problem].

sgarland 2y ago
Oh no, someone might know the number of customers, or the rate of signups. Traditional businesses can figure this out by sitting in the parking lot. Why SaaS has decided it’s a huge problem is beyond me.
- lazide 2y ago
  By sitting in every parking lot, yes. Which requires physical presence. And hedge funds do indeed do it against some targets specifically as a leg up, and pay quite a bit of money to do so, presumably because it is worth it to them. It certainly helped the Allies in the war, as previous intelligence had the rate of tank production much higher, and they were expending a lot of effort trying to exceed that previous false number. Information is power, etc. etc. As to if it's worth it for your SaaS to mitigate is up to you of course. I know I notice when things like Invoice #'s, my userID, customerID, etc. get shown, and it's a small number, or small delta. And that impacts my behavior. Does it also impact someone like a VC’s behavior? Or a competitor? Unknown. But Hell, a bunch of people right now are probably launching SaaS's with NO-OP auth flows for documents or images, or with trivial external SQL injection flaws, which is a way bigger problem. But it doesn't make the vulnerability/problem non-existent. Also feel free to use 16 bit auto incrementing primary keys for all your core tables if you want. But if we're in an engineering discussion on the topic, knowledgeable folks will bring up the issues with it, because that is what they do. Most would feel it is their duty to do it, even.
  - sgarland 2y ago
    > But if we're in an engineering discussion on the topic, knowledgeable folks will bring up the issues with it, because that is what they do. To be clear, this is not directed at you specifically, and I have no idea what your level of expertise is on anything. In general, I’ve found HN commenters level of knowledge to be fairly bimodal. They’re either regurgitating things they read on a Medium blog, or they really know their shit. Every time this topic comes up, people delightedly mention the German Tank Problem, but I have never, not once, seen anyone post an actual example of when a modern business got rekt by a competitor using knowledge gained from monotonic IDs. Re: security viz. AuthZ, my stance is the same as SQL injection – it’s such a trivially easy problem to avoid that it shouldn’t be a consideration for harming the performance of the DB. (Not that SQL injection mitigations cause performance impacts; sorry, that analogy didn’t work well)
    - melody_calling 2y ago
      > Every time this topic comes up, people delightedly mention the German Tank Problem, but I have never, not once, seen anyone post an actual example of when a modern business got rekt by a competitor using knowledge gained from monotonic IDs. At $previous_job (payments provider), the sales engineers would often spot merchants using sequential order IDs and mention it to the account managers. Rekt? I guess not, but knowing what percentage of their business we processed was extremely valuable information when it came to renegotiate the contract.
  - akira2501 2y ago
    > Which requires physical presence. It requires physical access. Presence can be achieved by placing a dash camera or window camera strategically. > and they were expending a lot of effort trying to exceed that previous false number. The idea here being that if the allies just made more tanks than the axis they would automatically win? It's a lionized story of intelligence agency cleverness built squarely on the back of insane military "strategy."
    - lazide 2y ago
- bruce511 2y ago
  Yes, sure, it leaks some information - but to be fair printing an invoice also leaks information. For me the priority is security. If I get a link (visible or invisible) that contains a numeric ID, there's the possibility to tweak that link with another number. Ideally, the server treats that number as suspect. Every. Single . Time. In practice I only need one developer to miss the check in one place and I have a serious security issue. Like leaking my entire customer list serious. This has happened multiple times -that we know of-. Yes obscurity is not security. But sequential numbers are insecure by design, and it takes a lot of well-maintained walls to protect them. One crack leaves them very vulnerable.
  - sgarland 2y ago
    Call me naïve, but surely you can have fuzzing tests in CI? I’m also going to use this as yet another example of why getting rid of QA in favor of Ship It Now was a bad idea.
    - bruce511 2y ago
      Relying on tests to discover the tortuous path to most security exploits would not be my recommendation.
- karmajunkie 2y ago
  i mean, you might care if the investors you’re trying to woo for that bridge round figure out your churn is a lot higher than you’re willing to admit… or worse, your traction is terrible.
  - sgarland 2y ago
    How is a monotonically incrementing integer going to reveal churn or traction? You’re not reusing IDs.
    - lazide 2y ago
      Sign up for two accounts over the space of, say, a month. See how big the delta is between the account IDs. That gives you potential traction. If you have access to revenue data (every investor is going to want this first thing), that gives you rough churn too. Do the same for creating users, if you can see user Id’s.
  - sofrimiento 2y ago
    So I should introduce complexity in my application so in the future it might help me dupe potential investors if my startup is not going well? That’s a whole new take on pre-mature optimization. I’d rather not dupe investors, and would rather not introduce unnecessary complexity, instead I’d rather focus on actually delivering value so investors actually want to invest.