If they leak, it becomes trivial to find working password synonyms to stick into the other sites you say benefit from discarding information.
But why don't they use the proven common-sense strategy of not storing the passwords at all, but store the hashes instead? They can validate by converting user-input to a hash and then there is no harm even if the user auth table is stolen.
This effectively makes your password case insensitive and probably reduces the % of support tickets (some people might not just click a reset password link and will insist they were typing it right, so they will open a ticket - all because they forgot capslock). It reduces operating costs at the expense of lower security and somebody must have considered it to be worth it.
> "the hashed passwords seem to have been changed to all lowercase before storage"
However, there's recent work [0] from Cornell that explores the security-usability tradeoff when correcting password typos. It turns out that accepting specific classes of typos (e.g., caps lock on: if password is "Password" then allow "pASSWORD") can increase usability with minimal security impact.
Reporting caps lock usage and not also keyboard layout usage is a pretty bad usability hole IMO.
Facebook does this, in case you weren't aware.
If a field is properly declared to be a password field (<input type="password" name="pwd">) of course ideally this wouldn't happen (plus, the characters get masked with stars, and hopefully what you type doesn't end up in your autocorrect dictionary, etc etc) - but it's full of shitty browsers out there.
My name in Greek has a letter with a double accent. Perfectly valid of course. But many (Greek) sites will reply that this NOT a Greek letter :)
At least they do not strip special characters out of the password.
Here's one idea: Let's say the user's password is P. The user enters some password P' with a typo. The authentication check is "does H(T_k(P')) == H(P)" for some set of transformations {T_1, T_2, ..., T_n}. Each transformation T_i hypothesizes that the user made a specific mistake. (e.g., T_1 is the caps lock is on so we need to flip the case of all the characters)
The paper I linked to actually does a good job motivating specific classes of typos by looking at real typos from Dropbox users.
I seem to recall facebook allowed login for a pass "fooBar" with "FooBar" (phone input capitalize first letter) and "FOObAR" (caps lock pressed).
Still seems stupid to me, but if you care a lot more about letting people in than about their security it might make sense.
https://www.ft.com/content/33503e4a-8f95-11e6-a72e-b428cb934...
I do, and it's not fun when I get asked to type in the 12th, 13th and 15th character.
It doesn't sound very easy to me at all. Can you explain in more detail?
More probably: the branch itself has a hardware VPN, so compromising the local network is still possible.
Yay! Free bank accounts all around!
In fairness to them, they do use 2FA for anything involving moving money around.
e: There is a pretty good discussion of this here https://www.reddit.com/r/personalfinance/comments/2m81uj/tip...
It's also not unheard of for them to strip all non alphanumeric characters so P@ssw0rd2016! is normalized to pssw0rd2016
On the other hand, they are probably far more alert to detecting and stopping bruteforcing attempts.
It's a similar situation with certain 4-digit PINs for smartcards; that may seem trivial to bruteforce, but you only get 3-5 tries before the system considers you to be attacking it and permanently locks you out even if you try to enter the correct one afterwards.
Chase's online banking login is case insensitive ...
This is true, but it's not a response to your parent comment,
> You can do what Facebook does without storing the passwords as lower case. If someone tries to log in, and the password doesn't match, then just transform it that way and try again.
1. Store the hash of "PassWORD".
2. Receive erroneous "pASSword", hash it, find the hash isn't right.
3. Reverse the case of the bad input to get "PassWORD", hash that, find it matches.
At no point was it necessary to store the hash of "password".
Not sure if this is what GP meant. Maybe Facebook only accepts wrong case on the first position (simple to implement) or maybe GP just doesn't know what they do.
I am in two minds wether a service used by non technical people should allow for case insensitive passwords, it'd be interesting to see what the difference in support load, customer satisfaction and churn would be for both case sensitive and case insensitive passwords, and also enforcing minimum complexity.
Have also never heard of a bank that actually asked for a password, substring or not, at least aside from being asked for a 'Phone PIN' or similar lesser/non-critical to authentication piece of information.
The uppercase being indifferent is a first for me but I've had those people tell me that performing copy paste into the password input somehow changed the authentication procedure. He again acted as if I was a complete idiot for suggesting that that made no sense.
Related, the "3d secure" credit card verification system asks for individual chars of a password (at least in the UK).
Lowercasing after hashing increases the likelihood of a collision, but it won't necessarily have anything to do with the upper/lowercasing of the actual password.
* Must be 7-15 characters
* Must have at least one letter
* Must have at least one number
* No special characters
¯\_(ツ)_/¯
Also, do they support e-statements for savings accounts yet? I swear it is the only piece of mail I get now a days.
Overall though they are a great bank with a magic fee-less debit card and human beings who answer the phone 24/7. And they don't seem too evil, but I haven't turned over many rocks.
http://www.schwab.com/public/schwab/nn/legal_compliance/schw...
and expand the "Be strategic with login credentials and passwords" section, it says:
> Consider getting a free security token, too, which can make every login even more secure. Just call us at 800-435-4000.
I really don't like the JS ecosystem but this is totally unwarranted.