Are you really worried that a card machine is going to leak your PIN? That doesn't seem to be a common attack vector compared to a third-party skimmer being attached or someone just mugging you and demanding your PIN under threat of physical violence.
To answer the actual question: I don't know because I left my PIN at 4 digits, despite knowing I could use more, precisely because I didn't think it would really make my life any more secure.
I'm not worried specifically about the PIN leaking.
The concern is that a 4-digit max PIN length is certainly implemented by someone who couldn't be bothered to read the spec for secure credit card transaction handling.
It's the equivalent of the "No brown M&Ms" clause or "Canary in the coal mine" test.
Nobody actually cares about the M&M color or some dumb bird.
"Must support 6-digit PINs" is not part of "the spec for secure credit card transaction handling" – which is also not a (or at least one) thing: There are dozens of card networks, and many of them have tons of regional variations.
In some markets, issuers only allow 4 digit PINs, and customers don't expect to have to press an "enter" key when they're done entering their 4 digit PIN – so the reasonable implementation is to allow only 4 digit PINs, or you'll be left with people staring at the ATM/POS terminal, waiting for something to happen.
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.
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.
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).
Ok, but that doesn't answer my question: what specific problem are you worried about that would allow someone to steal your money, that isn't incomparably unlikely compared to other methods? I'm just not aware of any problem that has happened in practice from poorly written card reader software.
To answer the actual question: I don't know because I left my PIN at 4 digits, despite knowing I could use more, precisely because I didn't think it would really make my life any more secure.