American Express passwords are not case sensitive.
It is possible that they UPPER(...) the password before hashing it and then compare against that when you log in. This explanation would only be a little dumb because it reduces the domain of the password space. It also strains credulity.
It's because the old mainframes they used to use only accepted uppercase passwords. A lot of of financial applications were uppercase only. I know this because my dad would often message me in all caps and then say, "sorry I was working in FinAppX and had caps lock on".
When the banks first moved to going online, they were just building thin interfaces on top of their mainframes. Hence things like password being letters and numbers only and max 8 characters. Some banks made this explicit, some just did upper() and truncate(8).
And at this point some have converted to modern technology but their tech debt lives on.
Lol it's been that way for at least 20 years. Same with chase (well at least the bank one half of it).
It seems remarkably stupid, but it's way cheaper for them to refund any losses and/or pay for lifetime credit monitoring than it is to deal with customer service calls from people getting locked out because they can't figure out how to deal with uppercase and lowercase letters.
It's funny that my small-ish credit union is not only more technologically advanced, but also way more ethical (looking at you, Wells Fargo) and convenient, and has top notch customer service. Seriously, I've never interacted with more pleasant customer service reps than my CU.
Why are people giving their money to big banks again? Is it just advertising pressure?
Well, 25 years ago, when I opened at $BigBank the CU I use now didn't exist, and $BigBank offered services and availability that CU didn't (in 1995). Then, for the very long time I tied so many things to that account at $BigBank that it took almost three years for me to migrate all the accounts, business and personal and loans, etc to the new CU.
I get that Amex would do this. It seems to be their attitude. They seem absolutely bent on eating the cost of fraud to make life easier for their customer.
For the other banks, the motivation is harder to understand.
Same motivation. Call center costs related to account recovery are astronomical when you have tens of millions of customers. The authentication systems at large banks are generally a bit more 'observational' than just watching what password is sent (not always of course) so you can still mitigate many threats while still allowing for reduced login friction.
Just checked to re-confirm: Wells Fargo passwords are case insensitive as well. This doesn't confirm that they store passwords in plaintext, as you said they may just convert to uppercase before hashing, but it is bad practice either way.
There is a lot more possible entropy if QwErTy and QWERTY are distinct. However, there seems to be issues in the entire financial sector with inability to upgrade certain systems due to massive amounts of legacy code. That being said, my local credit union's system distinguishes case for passwords; and they were unable to give a family member their password (they had to issue a reset) which at least leads me to believe they are hashing passwords instead of storing in plaintext.
My gut reaction to your story would be to assume that your local credit union is doing a better job than the big banks, not that there's a good explanation for the big banks.
Credit unions frequently also offer better mortgage APRs, better savings APYs, better customer service, lower (or no) ATM fees, etc.
My local credit union (one of the largest 25 NCUA insured in the U.S.) until about 5 years ago used your debit pin as the only password for online login and didn't allow changing the password or adding a second factor.
They also disallow certain common punctuation, which is indicative of either storing in cleartext, a really dumb hash function, the inability to sanitize inputs, or someone who has no idea setting password policy. All of which are bad.
BNP's password interface is insane. Instead of having normal password options, they limit it to 0-9 and then implement some hideous and overcomplicated front-end that randomizes the positions of each number on a virtual keypad and you click to enter your password.
Sucks for users but means you can't use key loggers or click loggers to get users' pins. From a security perspective it's actually pretty good. Even if they offered more complex passwords most people would choose a simple one anyway. This likely reduces fraud for the most vulnerable. It obviously sucks for people who know how to protect their devices.
I've got an account number, which is only used by the bank (though it appears on all bank statements). For some operations (adding a beneficiary for bank transfer, for example), there's a double factor, either on my phone or by postal mail and then there's at least a 24h delay: they must know their security is bad, so the bank limits the damage that can be done, you can't just get hacked and all your account emptied in a hour.
And to change your phone number, you've to use a on-use password, sent by postal mail to your address.
Elsewhere in this thread, a commenter (actually multiple) mentions that many French banks use 6-digit pins for authentication.[0] Another mentions that in Spain, some telcos do the same thing.[1]
Blizzard battle.net used to do that, and probably still does: transform to lower or upper case (then hash because I'm giving them the benefit of the doubt), instead of dealing with customer support at a large scale of people messing up capitalisation of their passwords.
There's a middle ground where part of the bank wants to do things right, and the other half wants customers happy now.
As a pure hypothetical situation, if the old system was terrible and, say, stored things in plaintext and did case-insensitive password lookups, then the new system needs to emulate that if they don't want to piss off existing customers by making their old password suddenly not work. The security side is going say "just have customers make new passwords", the business side will say "we won't budge, this has to be seamless", and the developers will settle with the crappy middleground of uppercasing everything before hashing to emulate the old system. Maybe they even maintain naive hope of improving the system down the road and convincing the next set of execs that its ok to revoke everyones password to allow them to better the system.
Found that out when I typed in a (example) 25 character password, but at some point the field was truncated down and I somehow figured out that if I backspace IIRC 4 characters away, my saved password worked.
This chain of logic does not follow. It is possible that your bank is properly salt+hashing your password - the truncation may have been on the back end before, and is now exposed to you because the field is shorter.
Maybe - but why not indicate clear password length requirements on the password entry screen and/or have the PWE text input HTML form only accept password characters up to that max length?
Additionally, silent trucation and 'maybe we do salt and hash after all' makes no sense IMO. That's not to say that I disagree that this is a possibility, only that the whole point of a hash is that it converts something of arbitrary length to a single length.
Therefore, truncating data that gets inputted into the hash would be computationally wasteful for no benefit, because the hash function will always result in a single length.
This is a feature, not a bug. Facebook accepts the inverse casing of your password as valid in case you accidentally have caps lock on while typing it.
American Express passwords are not case sensitive.
It is possible that they UPPER(...) the password before hashing it and then compare against that when you log in. This explanation would only be a little dumb because it reduces the domain of the password space. It also strains credulity.