Hacker News Reader

Comment by coldcode | Hacker News Reader

"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?

View on HN

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.

by that token I'd imagine ALLCAPSing would overlap many fewer passwords that have been reused for other sites.

If you know the password in allcaps, then you know it in lowercase, so why would that matter?

Assuming other sites DON'T do this it helps the security of other sites. But it hurts the security of your site.

Overall, yeah, it's not a good thing to do!

Wouldn't the leakage be catastrophically worse if storing CRC24 became commonplace?

If they leak, it becomes trivial to find working password synonyms to stick into the other sites you say benefit from discarding information.

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.

Not changing the salting. Changing the hashing algorithm.

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.

Read that again, slower.

> "the hashed passwords seem to have been changed to all lowercase before storage"

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.

[0] https://www.cs.cornell.edu/~rahul/projects/pwtypos.html

The problem is that it requires you to store multiple hashes while case normalization doesn't.

At least they do not strip special characters out of the password.

No, you can just store the original hash and try two times when matching.

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)

That caps lock case is a good one, but I don't really see other realistic instances where you wouldn't just say "username or password is incorrect".

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.

Or you could just show a message if the caps lock is on.

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.

How do you detect if caps lock is on with JavaScript in the browser?

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.

I've been out of the web game for a while - does the browser report what your keyboard layout is?

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).

>if password is "Password" then allow "pASSWORD"

Facebook does this, in case you weren't aware.

eugh. really? If true, I'd imagine they do it to appease mobile users.

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"...

Why would you imagine that? In my experience, it's much harder to turn on caps lock by accident on mobile.

More like if your password has a caps in it and you forget it on mobile.

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.

GP was specifically referring to caps lock inverse, not initial character capitalization (which I agree is more likely to be the problem).

autocapitalize="none" on input elements works since iOS 5, and seems to work on modern Android based on a quick google search.

I thought case insensitivity was only for the first character?

They do try changing the capitalization of only the first character, but also invert the capitalization of all the characters in the supplied password. http://www.zdnet.com/article/facebook-passwords-are-not-case...

Too bad that web sites are very English centric. They ask for upper case, I enter Ö, they don't recognize it as upper case.

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 ö...

Time to dredge up this one: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...

That's nothing!

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 :)

I guess this was done to allow inputting a slightly wrong password?

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.

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 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.

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:

https://www.ft.com/content/33503e4a-8f95-11e6-a72e-b428cb934...

I'm sure that is also preventing lots of people from using randomly generated passwords.

I do, and it's not fun when I get asked to type in the 12th, 13th and 15th character.

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 :(

Probably true for the most part, given the nature of the user base. On the other hand, Tesco Bank got owned this week.

Card-readers and other two-factor authentication is a better defence against keyloggers.

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?

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.

So if someone breaks into one branch, they break into every branch?

Yay! Free bank accounts all around!

It's possible the machine has some kind of VPN connection and this encryption is indeed end-to-end, just at another layer.

More probably: the branch itself has a hardware VPN, so compromising the local network is still possible.

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.

Santander uses selected digits of PIN and selected characters of password, with a numeric user ID.

In fairness to them, they do use 2FA for anything involving moving money around.

Ouch, yeah, Santander. Worst bank in the UK. Everyone I know who uses them has had some really terrible experiences.

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.

That sounds interesting. Can you explain how to do it?

https://en.wikipedia.org/wiki/Secret_sharing

SSS doesn't look like it pertains to this discussion at all. How do you use this to store single digits securely?

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?

How? I would be very interested in a solution for that, past the obvious and insecure "hash each character separately".

I don't think that's correct, the password field is case sensitive for me.

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

My bank used to do this as well.

  Chase's online banking login is case insensitive ...

So is the case with Citi.

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.

e: There is a pretty good discussion of this here https://www.reddit.com/r/personalfinance/comments/2m81uj/tip...

This is common with banks due to legacy systems that don't have case sensitivity.

It's also not unheard of for them to strip all non alphanumeric characters so P@ssw0rd2016! is normalized to pssw0rd2016

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.

Finding off-by-one errors in production code is a hobby of mine, but it's also pretty horrifying how often they're security-relevant.

You're lucky they didn't send a SWAT team to your door for "hacking."

This is not true (at least for passwords on Android).

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.

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.

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.

> 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.

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".

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.

Why wouldn't they transform it before registration and login ? That way they don't have to check multiple passwords. I guess I'm missing smtg.

Battle.net does the same: https://www.reddit.com/r/wow/comments/3hbqcl/psa_battlenet_p...

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.

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.

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.

If your bank is compromised to the point that your password - plaintext or otherwise - has been discovered, can things get much worse?

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).

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.

TDAmeritrade passwords aren't case sensitive. It's only money I guess.

Password rules...

* Must be 7-15 characters

* Must have at least one letter

* Must have at least one number

* No special characters

¯\_(ツ)_/¯

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")

If they don't require uppercase characters in the password, it is not so idiotic... specially if they have rules that make up for it.

Charles Schwab surprisingly does this, too.

They were really bad at one point, and only used the first 8 chars. Might be more now iirc

To their credit, they do offer sending you a free security token.

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.

Yep, if you go here:

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.

Chase bank does this.

I don't think they're recruiting top talent...

Maybe they don't look out for talent on HN unlike Pornhub [0] :)

[0] https://news.ycombinator.com/item?id=12846537

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.

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.

Never miss a moment for a random Js snipe

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.

Eh, the JS ecosystem's growth certainly isn't something I'd categorize as "scientific."

How do you jump from a small available pool of quality developers to JS problems?!

I really don't like the JS ecosystem but this is totally unwarranted.

Reply on news.ycombinator.com