[HN Gopher] Take a break: Error-detecting codes in credit card n...
___________________________________________________________________
Take a break: Error-detecting codes in credit card numbers, ISBNs
etc. (2000)
Author : signa11
Score : 46 points
Date : 2024-03-06 10:25 UTC (1 days ago)
(HTM) web link (plus.maths.org)
(TXT) w3m dump (plus.maths.org)
| brvsft wrote:
| IMEIs also have a concept of 'error' detection built in:
|
| https://stackoverflow.com/a/25229800
|
| https://en.wikipedia.org/wiki/Luhn_algorithm
| shironandonon_ wrote:
| 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.
| AndrewStephens wrote:
| 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.
| jmbwell wrote:
| 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.
| kube-system wrote:
| 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.
| justsomehnguy wrote:
| If you are making C2C transfer you would be pretty dismayed to
| find out you sent $2000 to 4929401234567009 instead of
| 4929401324567009.
| throwaway2016a wrote:
| 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.
| chrisdew wrote:
| Is the Damm algorithm strictly better than all of these?
|
| https://en.wikipedia.org/wiki/Damm_algorithm
| contingencies wrote:
| 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...
| omoikane wrote:
| 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
___________________________________________________________________
(page generated 2024-03-07 23:00 UTC)