Hacker News Reader

Comment by combatentropy | Hacker News Reader

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, and you decide to try 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.

View on HN

> 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.

Yes; it’s often called the German tank problem:

https://en.wikipedia.org/wiki/German_tank_problem

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. :)

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.

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.

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;

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.

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-o...

(Annoyingly the directive doesn't give a definition for "a sequential number" itself.)

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/... - p. 522, 14.5 (10) 4

> you are perfectly able to determine the order of the invoices.

But you can't determine if there are any gaps which is what the Italian ruling seemed to be concerned with (as best I could follow the Google translation which was pretty bad) and the Germans aren't bothered about.

I think if it were me, I'd ere on the side of caution and have them be sequential (ordered, gapless).

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.

Most places don't care about security very much in general. It is a security leak, albeit usually a minor one.

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.

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

That is absolutely true, but an individual store is unlikely to care.

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.

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.

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.

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.

Reply on news.ycombinator.com