"the hashed passwords seem to have been changed to all lowercase before storage". I have no words to describe how idiotic this is. How do people come up with this and still get paid?
This attitude ignores the fact that risk comes in multiple forms. While lowercasing the passwords increases the guess-ability of the password when attempting to log in to this site it actually reduces the value of the password in a breach of this sort, since it may not be usable verbatim on other sites even if the user typed it the same way. As this sort of breach is now quite common I think many "best practices" for password security that date back to the design of unix logins are arguably no longer best. For example if we just used CRC24 to hash passwords it would be nearly impossible to recover them from the hashes, but at a practical level would be comparably secure on the front end: it would take 1000s of guesses to find a working collision, which is easily preventable at the front gate by locking the account after a small number of bad guesses; but it would be far more secure on the backend, since any CRC24 code could derive from millions of possibilities.
Wouldn't each company salting on their front end prevent this? If you find a password synonym that works for a single company, it probably isn't the real password, so it would give you no information on a synonym for another company (unless it is the real password, in which case you can just use it directly, no need to look for another synonym).
You seem to be describing a non-standard way of salting hashes, and in the case of modifying the case, an extremely poor way of doing it. Please don't do that.
This is intended as a thought experiment, not a concrete design for how to properly store passwords. In fact CRC24 doesn't really burn as much information as I assumed, e.g. on the top 100,000 passwords it only generates about 300 collisions (so over 99% still generate unique hashes). If one was really going to go in this direction a specialized hash that is deliberately collision prone across password-like strings is probably needed.
> While lowercasing the passwords increases the guess-ability of the password when attempting to log in to this site it actually reduces the value of the password in a breach of this sort
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.
According to the article they were indeed hashes, but they were converted to lowercase _before_ hashing.
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.
I agree that password-typo tolerance may seem like a horrible idea on the surface. The "str to lower" approach is an especially aggressive way to increase usability.
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.
Case insensitivity is pretty Anglocentric. Much more interesting would be keyboard layout insensitivity. As an Israeli developer, if my password is, say, asdf, then from a usability viewpoint it would do me wonders if שדגכ would also be accepted, as I'll be writing something in Hebrew, switch to a different page, click a link that brings me to a login page where my username is saved, whoops just entered my password on the Hebrew layout by accident.
Reporting caps lock usage and not also keyboard layout usage is a pretty bad usability hole IMO.
Browser language preferences, yes. Keyboard layout, no. For one thing, layout names vary between OSes, for another, custom keyboard layouts are a thing... However, you can try and read individual keypress events and see which printable characters are generated for which key codes.
FWIW on my iphone I use the English layout (qwertyuiop) for all roman-alphabet languages I use, since spelling correction language is connected to the declared "language" (a strange yet sensible overloading).
At Facebook's scale, I'd bet someone has research and evidence of 7 digit per year reductions in support costs by making capslock (or forgotten capitalisation) problems "go away"...
The first character is often auto-capitalized in many input fields by your mobile browser.
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.
Yup. Also fun when trying to get paid from Google Play. "Please enter your name exactly like on your bank statement", then refuses since my bank statement name contains an ö...
That's a good idea but it doesn't work for other common typos: wrong case of only the first character, an extraneous character at the end of the password, etc.
Actually, I don't think there's a need to store multiple hashes.
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)
A few other cases: transcription errors (i.e., mistaking 1 for l), wrong case of the first character of the password, extraneous character at the end of a password, etc.
The paper I linked to actually does a good job motivating specific classes of typos by looking at real typos from Dropbox users.
Chase's online banking login is case insensitive (for both username and password). Frightening that a bank cares less about security than letting people in.
I don't know how things are in the states, but a lot of banks in the UK ask you to input randomly selected characters from your password rather than asking for the whole thing. This suggests they're storing the passwords in the clear. The financial times wrote an article about it recently:
They could hash all the possible triplets. This would be still ridiculously easy to crack, but it's not cleartext anymore so maybe it would pass the tick box security audit this way?
This is because a lot of banks Internet banking systems evolved from their phone banking systems. The random digits thing was so that someone couldn'the guess your code when you said it out loud over the phone.
Yes, when I wound up with Fidelity for a 401(k) I found their system was designed around being able to "enter your password on your phone" -- using the number keys, i.e. b3G -> 234. I can only hope that version is at least stored as a hash...
The worst feeling is getting halfway through keying out your password on the number keys when the Fidelity robot tells you that's not the right password. I just say operator now until they transfer me to a human.
I apparently am "good" enough to never have had that happen, though I don't call very often. That's horrific, since it implies that it is stored as plaintext, "optimistically" as "plain-number-text."
It's also horrific because you can use that to brute-force guess someone's password, because the robot will tell you when you have the wrong digit, so you can work your way through all 10 phone keys for each digit, noting each time whether the robot kicks you out, until you guess the entire thing.
To be clear, the input just times out, likely because they don't expect a long random password input. I don't think it's evidence that they can verify a substring of your password.
Agreed. Their rationale is that keyloggers can't as easily work and their chance of being hacked is lower than the odds of a user with malware keylogging :(
A common interview question for penetration testers is how you might design password storage to allow this 'feature' without having to store the plaintext password. It's possible, I guarantee it.
If you have an method for requiring n out of m key parts to use the key, it is fairly easy to see how this can be used to require n out of m characters from a password. The only problem is that just a few characters doesn't have a large enough entropy to prevent the whole thing being brute forced very quickly.
> If you have an method for requiring n out of m key parts to use the key, it is fairly easy to see how this can be used to require n out of m characters from a password.
It doesn't sound very easy to me at all. Can you explain in more detail?
I was in my bank branch recently and they printed off a statement while I was there. It was only when I got home I noticed the url was http rather than https. It was an intranet but even so.
My bank in the UK has two separate things - a password, which I have to enter in the whole, and a "memorable word" which acts as you suggest. I've not seen a bank account which solely uses a memorable word.
The last time I was made to change my Chase password, I made it maximal length at the time (32 characters). However, it turned out their login page had an off-by-one error in the login page Javascript, such that it wouldn't let you type 32 characters in the field. I worked around it via using the browser debugging tools to fix the bug, then decided on a 30-character password as an additional margin of safety. They said they'd look into it, never heard back about it.
I get the case insensitivity on the username though. You don't want grandma trying to remember if it was SweaterKnits@aol.com or sweaterKnits@aol.com as they resolve to the same thing. If not using the email, then he same thing applies, and I don't want the hassle of my tech support trying to resolve the difference over the phone.
In general Chase has a reputation for being much more careful and thoughtful about security than others (and in fact their password policy is somewhat better than some other financial institutions I've done business with). But still, I agree, that sucks.
Frightening that a bank cares less about security than letting people in.
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.
As mine is too. Just tried it and it said incorrect. Maybe it's some set of old legacy users? But that wouldn't make sense since I'm migrated in from WaMu
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.
If you're saving the hash of original PassWORD, then transforming the erronously entered pASSword to lower case will still produce a different hash from tge one you have saved. It will only work if you save a hash of lower case password.
> If you're saving the hash of original PassWORD, then transforming the erronously entered pASSword to lower case will still produce a different hash from t[h]e one you have saved.
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.
Oh, you mean only the transformation of inverting the case. But I believe that originally we were talking about any mistakes with case, not only inversion.
You can also do O(2^n) brute-force like a dumbass.
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.
In reality a lot of people don't see any difference between "Password123", "password123" or "PASSWORD123". I was once talking to a bank and had to give char n of my password and I said something like "Uppercase E" and the rep on the other end of the phone actually scoffed at me "Capitals don't make any difference in passwords" and clearly thought I was an idiot.
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.
That bank sounds to have bigger issues: perhaps obvious, it's very likely that they were storing the password as plaintext -- since they were able to ask you for a specific character and verify that your answer was correct. Scary.
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.
In my experience banks store pins in plaintext way to often.
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.
The point was more about the reaction of the rep, that it was ludicrous of me to consider passwords to be case sensitive, but yeah, not a good sign in general, though as I use a unique password for everything (1Password) I'm less concerned.
Related, the "3d secure" credit card verification system asks for individual chars of a password (at least in the UK).
It's possible that they create the character entry when you set your password and the bank/operator only has access to that particular character in plain text.
All the other comments seem to be misinterpreting this as "the passwords were changed to lowercase before hashing and storage", which is entirely different.
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.
It's a good idea. The amount of security gained by distinguishing between upper/lower case is minimal, particularly compared to the support cost. Increase the minimum password length by a character or two to compensate if you're really worried.
Saying that they don't require mixed case passwords to be chosen is not the same thing as saying they are "not case sensitive" (e.g. accepting "youare86ed" as valid for matching "YouAre86ed")
Really? I haven't seen one and I've had six figures in brokerage/checking/savings for a decade. I know someone who worked at their datacenter a while ago and, well, heh.
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.
There really is a shortage of quality developers. A bit off topic, but I believe that's why there are so many devs bemoaning the growth of the JS ecosystem...you may have to know actual Computer Science instead of just one tool.
Whatever issues people have with the js tooling ecosystem "Dammit. It requires me to have a computer science background" doesn't strike me as a common one.
I'm not sure I understood your comment. I agree there's a shortage of quality developers, but sometimes that's a result of an influx of newcomers. Maybe you can elaborate on this connection (or lack thereof) between CS and JS? I honestly couldn't tell from your comment if you were speaking in a positive or negative light.
I think an influx of newcomers might be a symptom of a shortage of quality developers rather than a cause. I suspect the cause would be more to do with an increase in demand in the job market and unfilled jobs, which encourages a lower bar when it comes to hiring.
