A year or so ago this was also the case with Facebook [0]. I believe it's a simple compromise between user experience and security. You can probably eliminate a large portion of user frustration this way. Before you instinctively respond with something like "but security should be the NUMBER ONE priority," realize that you're always making a compromise between user experience and security, and in fact, the two aren't even orthogonal. You could require users to purchase and use biometric scanners to authenticate, but that would likely be very frustrating. Or, you could require users to use a 50 character password with tons of entropy, but that would probably just lead to users leaving, or (perhaps worse) writing their password on a note stuck to their monitor.

[0] http://www.zdnet.com/blog/facebook/facebook-passwords-are-no... —Actually, Facebook wasn't completely case insensitive. It only accepts the chosen password and a version with every character's case inverted.

They gave a pretty good reason for that, case inversion occurs naturally if you have capslock on.

It doesn't make the password any less secure. (It's actually only one other password.)

They also allow you to change the first letter to caps, which accounts for phones that capitalise the first letter of every sentence you type.

> It doesn't make the password any less secure. (It's actually only one other password.)

It does make your password less secure, it's just that Facebook judged it an acceptable compromise between user experience and security.

Try making your passwords longer instead of making them harder to enter.

That is to say "usingthisasapassword" is ~4 million times better than using "p4ssWOrd!".

Actually, I don't see that as a big deal. Maybe it could be tweaked to have only the first one sensitive or try the all-caps/no-caps. But still, it's all in the length of the password. I prefer to have that rather than someone forcing me to use a 6-8 characters password with at least one cap, one special or any of this bullshit.

You are correct, this is less than a big deal. In fact it's pretty irrelevant.

Third parties hacking battle.net accounts aren't doing so through brute force, they are doing it through phishing and viruses with keyloggers.

This is kind of important. I will reserve "big deal" for other infractions, but it's far from harmless. It's important to protect your users passwords regardless of whether phishing them directly is the more popular attack. If you don't know why, just ask Sony and Valve.

I would be very interested, however, to know what this implies about the way they store their passwords. If, on submission, they normalise the case it and then hash it (and then for all checks, normalise the supplied pw)... then, it's still not really acceptable, but at least the password I've given them is encrypted.

Why isn't that technique (normalizing then hashing) acceptable? There is always a compromise between user experience and security. Why allow three character passwords, or passwords of "password", but not case insensitive passwords?

Pedant alert! Hashing is not encryption.

Hashing is one way, and encryption is two way -- correct?

edit: Might as well look it up. The user "bestsss" at Stack overflow confirms this is the case.

http://stackoverflow.com/questions/4948322/fundamental-diffe...

Pedant alert, hashing is still a form of encryption. Take a look at what crypt(3) used to do ;)

Why isn't it acceptable to normalise the password and then hash it, compared to just hashing it?

Because the search space for brute-forcing a password is massively reduced :). Suddenly, instead of having 62 possibilities per password character (assuming alphanumeric + no specials), there's only 36. Whereas a password like "PassWord123" might have gotten past a wordlist (well, that's unlikely, but...), "password123" certainly wouldn't.

Thanks!

I find it funny how eager the community manager is to admit the flaw.