4 ms·

Do you mean enumeration, whereby an attacker starts at some ID and tries several in sequence? It has never been a problem for me and my applications. Just beca

Do you mean enumeration, whereby an attacker starts at some ID and tries several in sequence? It has never been a problem for me and my applications. Just because you know a record exists, doesn't mean you can see it. For example, if you are authorized to view https://www.example.com/records/100 https://www.example.com/records/100, and you decide to try https://www.example.com/records/101 https://www.example.com/records/101, then the code will check to see if you're authorized to see record 101. If not, then you will get Unauthorized. I suppose there are situations where it's a problem if someone finds out that record 101 even exists, but not in any of my apps.

bsder 5y ago
> I suppose there are situations where it's a problem if someone finds out that record 101 even exists, but not in any of my apps. Well, it's things like say, an invoice number. I can buy something from you. And then 7 days later I buy something else from you. If the invoice numbers are in sequence, I just gained quite a bit of information about how fast you are selling things. That's the kind of information leak that sequences can create.
- wokkel 5y ago
  Nice idea, but please check your local tax office. At least here in the Netherlands, you are required to use a monotically increasing series for invoice numbers. So I wouldn't do this if I were you.
  - silon42 5y ago
    You can't stop anyone from doing what he describes if you allow customers to see the invoice number. IMO, your sequential sequence number should be for tax audit purposes only.
    - miken123 5y ago
      That may be your opinion, but an invoice in at least the Netherlands needs an monotonically increasing number. And it needs to be on the invoice and your customer needs to be able to see it. [edit] It's even EU-wide, see article 226(2) of directive 2006/112/EC: > a sequential number, based on one or more series, which uniquely identifies the invoice;
      - d_k_f 5y ago
        Nothing stops you from using the "...or more series" part to generate numbers that are specific to the day, the hour or, if you feel like it, the minute. Today's first invoice could be 2021-07-16-001, the second one 2021-07-16-002, etc. If you really don't want people to be able to guess your invoice volume from numbers alone, there are various ways to do that while still being compliant to EU laws.
        zimpenfish 5y ago
        I think e.g. 2021-07-16-123 followed by 2021-07-17-001 wouldn't fall under "sequential number" though because, well, they're not sequential. The Italian authorities seem to see this the same way - https://vatdesk.eu/en/eu-vat-news/italy-mandatory-mentions-on-invoice/ https://vatdesk.eu/en/eu-vat-news/italy-mandatory-mentions-o... (Annoyingly the directive doesn't give a definition for "a sequential number" itself.)
        d_k_f 5y ago
        They are sequential for all intents and purposes, they are simply using two separate series within the same number – you are perfectly able to determine the order of the invoices. I do agree that (as is so often the case) the directive is not specific enough to determine whether the Italian interpretation is correct or not, though I can provide some context from the German side as provided by the ministry of finance: "Eine lückenlose Abfolge der ausgestellten Rechnungsnummern ist nicht zwingend"[1] (~ "it is not required for the invoice numbers to be gapless"), which directly contradicts the Italians as far as I understand it. [1] https://www.bundesfinanzministerium.de/Content/DE/Downloads/BMF_Schreiben/Steuerarten/Umsatzsteuer/Umsatzsteuer-Anwendungserlass/Umsatzsteuer-Anwendungserlass-aktuell-Stand-2021-06-28.pdf?__blob=publicationFile&v=47 https://www.bundesfinanzministerium.de/Content/DE/Downloads/... - p. 522, 14.5 (10) 4
- mcraiha 5y ago
  Most places do not care about this. e.g. our local Subway restaurants print purchase number of the day to every receipt that customer gets. So you can see how many sales certain Subway restaurant has done in a single day by going to that restaurant before it closes and buying something.
  - sonotathrowaway 5y ago
    If you can find a way to take a representative sample of their stores, you can front-run their quarterly earnings report and make a guaranteed profit off them.
    - joshribakoff 5y ago
      Even if you could approximate revenue, that hardly equates to profitability. Even if you could approximate profits, the market still behaves irrationally (in the short term), there are no guarantees
    - jsight 5y ago
      That is absolutely true, but an individual store is unlikely to care.
  - TheCoelacanth 5y ago
    Most places don't care about security very much in general. It is a security leak, albeit usually a minor one.
- teddyh 5y ago
  Yes; it’s often called the German tank problem: https://en.wikipedia.org/wiki/German_tank_problem https://en.wikipedia.org/wiki/German_tank_problem
  - allknowingfrog 5y ago
    Thanks for sharing this. I'm not saying this will definitely come up in my day job, but it's at least possible, and now I'll know what to call it. :)
- wayneftw 5y ago
  You asked if it was a bad idea in general. It's not. Perhaps it's a bad idea in this one specific case but not in general.
jacobsenscott 5y ago
I've certainly seen this be a problem - even if you and every future programmer who touches your code gets the authorization check right every time over the years the app is live, and over the hundreds or thousands of endpoints it exposes, plenty of apps don't get it right every time. Using random id's is a nice and low effort additional layer of security there.
- worble 5y ago
  If you're not doing your authorization properly, then no, basic ID obfuscation is not an extra layer of security. If anything, the fact that some people might gloss over the glaring security issues because "well its random ids so I never decided to check" is worse, an incremental id can at least be easily tested while developing to make sure, or a nice white hat hacker might notice and let you know.
- tonyarkles 5y ago
  Depending, very much, on that balance between usability and security. For the use case in the story, I'd way rather talk about (and write down) incidents 122 through 124 with my team, rather than incidents 549697a9-dd6a-4a90-a5f4-b2ff1a1d9289, d6150929-a692-414b-ba9e-ccbcf5e48a59, and 2756998d-035f-42bc-a97d-4135529e85d9.

bsder 5y ago

> I suppose there are situations where it's a problem if someone finds out that record 101 even exists, but not in any of my apps. Well, it's things like say, an invoice number. I can buy something from you. And then 7 days later I buy something else from you. If the invoice numbers are in sequence, I just gained quite a bit of information about how fast you are selling things. That's the kind of information leak that sequences can create.

wokkel 5y ago
Nice idea, but please check your local tax office. At least here in the Netherlands, you are required to use a monotically increasing series for invoice numbers. So I wouldn't do this if I were you.
- silon42 5y ago
  You can't stop anyone from doing what he describes if you allow customers to see the invoice number. IMO, your sequential sequence number should be for tax audit purposes only.
  - miken123 5y ago
    That may be your opinion, but an invoice in at least the Netherlands needs an monotonically increasing number. And it needs to be on the invoice and your customer needs to be able to see it. [edit] It's even EU-wide, see article 226(2) of directive 2006/112/EC: > a sequential number, based on one or more series, which uniquely identifies the invoice;
    - d_k_f 5y ago
      Nothing stops you from using the "...or more series" part to generate numbers that are specific to the day, the hour or, if you feel like it, the minute. Today's first invoice could be 2021-07-16-001, the second one 2021-07-16-002, etc. If you really don't want people to be able to guess your invoice volume from numbers alone, there are various ways to do that while still being compliant to EU laws.
      - zimpenfish 5y ago
        I think e.g. 2021-07-16-123 followed by 2021-07-17-001 wouldn't fall under "sequential number" though because, well, they're not sequential. The Italian authorities seem to see this the same way - https://vatdesk.eu/en/eu-vat-news/italy-mandatory-mentions-on-invoice/ https://vatdesk.eu/en/eu-vat-news/italy-mandatory-mentions-o... (Annoyingly the directive doesn't give a definition for "a sequential number" itself.)
        d_k_f 5y ago
        They are sequential for all intents and purposes, they are simply using two separate series within the same number – you are perfectly able to determine the order of the invoices. I do agree that (as is so often the case) the directive is not specific enough to determine whether the Italian interpretation is correct or not, though I can provide some context from the German side as provided by the ministry of finance: "Eine lückenlose Abfolge der ausgestellten Rechnungsnummern ist nicht zwingend"[1] (~ "it is not required for the invoice numbers to be gapless"), which directly contradicts the Italians as far as I understand it. [1] https://www.bundesfinanzministerium.de/Content/DE/Downloads/BMF_Schreiben/Steuerarten/Umsatzsteuer/Umsatzsteuer-Anwendungserlass/Umsatzsteuer-Anwendungserlass-aktuell-Stand-2021-06-28.pdf?__blob=publicationFile&v=47 https://www.bundesfinanzministerium.de/Content/DE/Downloads/... - p. 522, 14.5 (10) 4
mcraiha 5y ago
Most places do not care about this. e.g. our local Subway restaurants print purchase number of the day to every receipt that customer gets. So you can see how many sales certain Subway restaurant has done in a single day by going to that restaurant before it closes and buying something.
- sonotathrowaway 5y ago
  If you can find a way to take a representative sample of their stores, you can front-run their quarterly earnings report and make a guaranteed profit off them.
  - joshribakoff 5y ago
    Even if you could approximate revenue, that hardly equates to profitability. Even if you could approximate profits, the market still behaves irrationally (in the short term), there are no guarantees
  - jsight 5y ago
    That is absolutely true, but an individual store is unlikely to care.
- TheCoelacanth 5y ago
  Most places don't care about security very much in general. It is a security leak, albeit usually a minor one.
teddyh 5y ago
Yes; it’s often called the German tank problem: https://en.wikipedia.org/wiki/German_tank_problem https://en.wikipedia.org/wiki/German_tank_problem
- allknowingfrog 5y ago
  Thanks for sharing this. I'm not saying this will definitely come up in my day job, but it's at least possible, and now I'll know what to call it. :)
wayneftw 5y ago
You asked if it was a bad idea in general. It's not. Perhaps it's a bad idea in this one specific case but not in general.

jacobsenscott 5y ago

I've certainly seen this be a problem - even if you and every future programmer who touches your code gets the authorization check right every time over the years the app is live, and over the hundreds or thousands of endpoints it exposes, plenty of apps don't get it right every time. Using random id's is a nice and low effort additional layer of security there.

worble 5y ago
If you're not doing your authorization properly, then no, basic ID obfuscation is not an extra layer of security. If anything, the fact that some people might gloss over the glaring security issues because "well its random ids so I never decided to check" is worse, an incremental id can at least be easily tested while developing to make sure, or a nice white hat hacker might notice and let you know.
tonyarkles 5y ago
Depending, very much, on that balance between usability and security. For the use case in the story, I'd way rather talk about (and write down) incidents 122 through 124 with my team, rather than incidents 549697a9-dd6a-4a90-a5f4-b2ff1a1d9289, d6150929-a692-414b-ba9e-ccbcf5e48a59, and 2756998d-035f-42bc-a97d-4135529e85d9.