3 ms·

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 h

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
    Having a dashcam in this situation is only useful if that dashcam is physically there during the times you care about eh? Which is the physical presence part. With some applied statistics, that can be reduced (no need to sit in every parking lot 24/7 for instance), but there is definitely some sitting in parking lots involved. No, it’s that they would set tank production quotas (and budgets) based on what they expect to need to produce to crush the enemy. Modulo whatever level of effectiveness had been apparent so far. Which, for any given set of resources, would mean taking away resources from something else. Either manpower, steel, oil/gas, etc. So overproducing tanks means fewer aircraft, or less artillery, etc. Convincing the enemy you’re producing too much (or too little) of something to get them to waste their time and energy is a classic counter intelligence move. WW2 was won largely with logistics and economic might + reasonable tactics. Applying the economic might effectively was part of that.
    - akira2501 2y ago
      > Convincing the enemy you’re producing too much (or too little) of something to get them to waste their time and energy is a classic counter intelligence move. So much so that it calls into question the entire idea of clandestine wartime intelligence having any exceptional value. > WW2 was won largely with logistics and economic might + reasonable tactics. I think people who say this simply haven't counted the dead. > Applying the economic might effectively was part of that. Which had essentially no bearing on our problems with Japan.
      - 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

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
  Having a dashcam in this situation is only useful if that dashcam is physically there during the times you care about eh? Which is the physical presence part. With some applied statistics, that can be reduced (no need to sit in every parking lot 24/7 for instance), but there is definitely some sitting in parking lots involved. No, it’s that they would set tank production quotas (and budgets) based on what they expect to need to produce to crush the enemy. Modulo whatever level of effectiveness had been apparent so far. Which, for any given set of resources, would mean taking away resources from something else. Either manpower, steel, oil/gas, etc. So overproducing tanks means fewer aircraft, or less artillery, etc. Convincing the enemy you’re producing too much (or too little) of something to get them to waste their time and energy is a classic counter intelligence move. WW2 was won largely with logistics and economic might + reasonable tactics. Applying the economic might effectively was part of that.
  - akira2501 2y ago
    > Convincing the enemy you’re producing too much (or too little) of something to get them to waste their time and energy is a classic counter intelligence move. So much so that it calls into question the entire idea of clandestine wartime intelligence having any exceptional value. > WW2 was won largely with logistics and economic might + reasonable tactics. I think people who say this simply haven't counted the dead. > Applying the economic might effectively was part of that. Which had essentially no bearing on our problems with Japan.
    - 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.