Comment by jiggawatts
1 year ago
4 is the minimum number of digits required, but there are over a dozen different PIN block standards, and most allow between 4..9 and 4..16 digits: https://www.eftlab.com/knowledge-base/complete-list-of-pin-b...
Making an ATM that can accept cards from multiple issuers (which is the norm these days) and allowing only 4 digits is the same category of error as requiring that the first character of someone's last name start with a capital letter, or to block symbol characters in names.
I agree: An annoying/avoidable implementation shortcoming, but arguably relatively orthogonal to security.
> there are over a dozen different PIN block standards
You almost certainly don't need to support all of these inside the PIN pad or even ATM/POS. If necessary, translation can happen in other parts of the system.
> or to block symbol characters in names.
People tend to very very quickly their mind on that one once they get a few right-to-left control characters that flip over the text layout of the entire program.
"We'll just not do business with anyone named O'Neill, that's just a made-up name designed to trick the database with SQL injection."
Also: https://www.ancestry.com.au/name-origin?surname=null
Are you arguing to just allow any byte in names (which are ultimately user-defined input data), including 0x00, Unicode byte order markers etc., in a thread about a perceived correlation between developers' lack of i18n awareness and security bugs no less?
The reality is that there is often a tradeoff between keeping your test and edge cases simple via constraining allowable inputs and internationalization.
So I think you've got it exactly the wrong way around: These limitations might have happened precisely because somebody wanted to do the right thing from a safety/security perspective by doing overly strict input validation, at the expense of internationalization/compatibility.
Not saying that that's a good tradeoff in every case, but I really don't think you can draw any conclusions about a system's security by looking at whether it arbitrarily disallows some inputs (or if anything, maybe the opposite).