Take a break: Error-detecting codes in credit card numbers, ISBNs etc. (2000) | Hacker News Reader

Take a break: Error-detecting codes in credit card numbers, ISBNs etc. (2000)

plus.maths.org

85 pointssigna1119 comments

The ISBN mentioned in this article is ISBN-10, which has been replaced by ISBN-13 in 2007. ISBN-13 is a subset of EAN and use the same error detection scheme.

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

Memories. ~10 years ago I looked in to this stuff as part of adding national checksum support to an IBAN library. It was quite a mission to discover the number of systems out there, most of which were insufficiently documented or undocumented. Wound up reverse engineering quite a few of them (period braindump available[3]).

In the end I wrote a function[1] which reverses an input known to fail a checksum to determine probable transcription errors based upon a manually compiled, exhaustive list of probable mistranscriptions[2]. I was quite impressed at how fast and accurate it was.

From a systems architecture standpoint, I learned that there is really no excuse today for creating a system in which human transcription may occur without a checksum mechanism. Largely, however, QR codes and the trusted optical exchange of identifiers in physical settings has superseded this solution class (but brought its own vulnerabilities and concerns).

[1] https://github.com/globalcitizen/php-iban/blob/master/php-ib... [2] https://raw.githubusercontent.com/globalcitizen/php-iban/mas... [3] https://github.com/globalcitizen/php-iban/issues/39#issuecom...

IMEIs also have a concept of 'error' detection built in:

https://stackoverflow.com/a/25229800

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

Is the Damm algorithm strictly better than all of these?

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

A CC number also tells you the issuer, without doing a lookup.

And the issuer can usually tell you how many digits, from 13 to 16, which is an additional offline input check, besides the checksum.

In retrospect is there any point to these error detecting codes or was it just good intentions?

Anyone who enters a credit card number still knows you have to enter in… your security code.. your name on card.. your billing address (or at least the zip / postal code).

Seems to me like the ID should have just been an ID.

It provides a way to preliminarily validate the number without having to waste an API call for verification of a malformed number. If it doesn't check out, you can kick it back immediately. I don't know whether this was the intention with credit cards, as those were initially largely used offline and processed in batches, but for lots of numbers with this kind of error checking built-in, offline validation can save a small amount of effort/expense that adds up when you are dealing with a high volume of transactions.

In terms of storage and communication, there's a benefit in being able to verify some degree of data integrity as well.

So I would hazard it's totally a processing thing, not really an identity thing.

These are not authentication mechanisms, they are error detection mechanisms. This article (and these error checking algorithms) predate the time in which anyone could just throw data at a centralized API to see if you can get a 404 or 401 in response. A lot of the systems that used these numbers in the 20th century were offline and/or slow to process. e.g. the Luhn algorithm which credit cards use was invented in 1954.

Also EANs/ISBNs don't have other authentication factors available. You don't want a mis-scan for product A to accidentally charge a customer for product B. You want to detect the mistake.

It's purely for user experience not security. And it is pretty good at that.

Many of the methods to entering these numbers are very error prone:

- Laser scanners

- Cameras

- Humans

- Magnetic readers

- etc

The check digit lets the system know the error was likely misread / mistyped without needing a database or the like and also helps prevent an accidental mistyped value from also being a valid valud (The number for Book A is unlikely to be mistyped exactly to be the number for Book B because of the check digit).

It also can help to improve scanning speed to some degree since if you have two interpretations of the signal it is possible to infer which one is most likely to be correct.

> It's purely for user experience not security. And it is pretty good at that.

Indeed. One of the things I hate is that the bank account numbers in our banks does not have a check digit. There have been cases where people have transferred hundreds of thousands to wrong accounts, simply by mistyping a single digit in the account number.

If you have some important generated reference that needs to be entered manually, include some check digit/letter.

As usual EU has the better stuff, IBAN does have code checksum mechanisms! https://en.wikipedia.org/wiki/International_Bank_Account_Num...

Yes, I was looking forward to read the section on IBANs, before it never came. Then I noticed the article being from 2000. IBANs weren't in use at that time.

At least in Germany IBANs are not very popular. Compared to the national numbers usability has decreased a lot.

Previosly the was bank id in a nice 3-3-2 grouping. Because there are not so many banks the numbers were systtematically and sparsely assigned. When I was a student in Germany I had 600 100 70, I remember it decades later. Account numbers were variable length, most banks did not have very long ones.

With IBANs the bank id remained unchanged, but the grouping got very weird, so it's hard to recognize and remeber. Account number have been padded with leading zeros to achieve a fixed length IBAN. So the nice short numbers ended up with long runs of zeros, not at all user-friendly. In the old days I knew several accounts by heart. For IBANs I do not naturally remember a single one (I know how to construct the from old numbers, but it's a tedious process not happening in a couple of seconds.) Typing a German IBAN is a nightmare every time.

Do banks in the US not support IBANs? I thought they were supposed to be international/universal. I use them even for domestic (even same bank) transfers because it's just a single number I can paste/type into my online banking page.

Didn't even know they had checksums until earlier this year, when I was going to yes-and someone complaining about needing to enter them by hand from written forms and looked up if I was correct.

I think you are missing the point of the error detecting digits.

All they protect against is mistyping (or in the old days, misspeaking over a noisy telephone) the annoyingly long sequence of random digits. Actually judging that the numbers refer to a valid credit card account that the user is authorized to charge is an entirely different (and harder) problem.

The CC# is just a CC#, albeit one that contains extra digits that depend on the other digits.

> In retrospect is there any point to these error detecting codes or was it just good intentions?

They also provide a good source of problems in elementary number theory.

If you are making C2C transfer you would be pretty dismayed to find out you sent $2000 to 4929401234567009 instead of 4929401324567009.

All European banks I know require you the enter the recipient's name. So they could do a plausibility check, even with some spelling inconsistencies allowed. But banks are not in the business of offering good customer experience, they just put to their fineprint that only the number will be used. With IBANs there is only a 1% chance that the check-digits match (less if you weight common human typos), but still mistyping it and ending up with a valid number can realistically happen.

Would an error code protect against it if both accounts exist? if the account doesn't exist then the transfer wouldn't go through.

Yes it would, since adding a check digit means there are 10x as many numbers as possible accounts, and any single digit typo or transposition can't map to a valid account number with a valid check digit.

Even if a transfer doesn't go through, that transfer might be stuck pending for hours or days before being reverted, if we're talking about bank transfers.

Reply on news.ycombinator.com