Hacker News Reader

Comment by elithrar | Hacker News Reader

> Although this is a really silly bug,

Personally, I don't believe it is a bug at all. They have obviously made the decision to not enforce case in an effort to reduce customer service load/player frustration.

Yes, it reduces the time needed to brute force your password if someone got hold of their user DB. But 1) we are still talking an excessively long time (their min. password length is 8) and 2) once they have that, you may have bigger problems.

Whilst this is only anecdotal (over several years of WoW/SC2), the majority of compromised Battle.net accounts are through keyloggers/malware and phishing scams. In those cases, you can have a 40 character password with all the case sensitivity you like and it won't matter at all.

View on HN

I agree completely. It is not a bug. From my experience, technically inept users confuse upper and lower case all the time - and the result is they file an incident report because their "password stopped working". The same applies to leading or trailing spaces, they should be stripped.

We should also automatically correct the spelling of the word used as the password. /s

No. Usually, when I create a password I'm asked to verify it in the next text field. When I visit the login page and enter the exact same characters, I expect it to work. I shouldn't have to guess at my own password because some clever developer's algorithm decides that I made a mistake.

You don't need to guess it, if it's implemented the correct way, the signup and the login process will have the same rules and you won't notice.

I'm fairly certain you are both jesting.

I've implemented this very thing for the same reason--it cuts down on user errors. The real answer to password security is length, not putting odd stuff in the passwords that makes people forget them.

There's nothing you need to guess, the logic is in the password encoder and thus will apply both when you set it and when you use it.

Stripping characters reduces length, so you are making passwords less secure by your own criteria.

As for the scenario I described, I experienced it myself in a system that silently stripped spaces from any position in the verification process, storing a different password than the one I typed in, without any warning. My password wouldn't work in the login and I figured it out by examining the password verification code.

I don't understand why it's controversial to simply accept and store a user's password verbatim. Any other approach risks introducing new security issues, from reduced entropy to password clashes. Misguided policy decisions are famous for weakening encryption schemes, like that of the Enigma machine in WWII.

Indeed, case sensitivity is annoying. Better off giving the user a warning for weak passwords.

I'm even inclined to consider chars within the sets 0o and 1lL i the same, but that's even more controversial :-)

I don't think anyone's nearly as concerned about case enforcement as they are about backend storage of passwords. I can assume some (plausibly safe) ways of storing/verifying passwords that are case insensitive, but I'm not naive enough to assume they do.

From reddit:

I've reversed Battle.net protocols in full. Here's some facts:

Your plaintext password is never sent in plaintext. Old Battle.net clients (Diablo 2 and earlier) use what we call the 'old login system' (OLS), which uses Broken-SHA1 (SHA1 implemented with small bugs). Since Warcraft 3, the 'new login system' (NLS) is used, which uses SRPv6 (a standard for password exchange using public keys + RSA).

Under OLS, the Broken-SHA1 of the password is stored. Under NLS, a value called the verifier is stored, which is derived from the (actual) SHA1 of the password.

The protocols (both OLS and NLS) support case sensitivity just fine - the case insensitivity is a client-side issue. If you implement the protocol yourself, you can use a case sensitive password, but the game client won't be able to log in with it. We used to use that as a security feature in bots.

After a small number of failed logins, your IP is temporarily banned. That means that bruteforcing is nearly impossible.

Honestly, I don't understand why they have case insensitive passwords; but, at the same time, it doesn't make that much difference considering only a few password attempts are allowed before you're banned.

http://www.reddit.com/r/netsec/comments/u2168/blizzard_inten...

>After a small number of failed logins, your IP is temporarily banned. That means that bruteforcing is nearly impossible.

If someone in genuinely trying to crack passwords, I'm going to go out on a limb here and say that they know what proxy servers are and how to use them.

After a certain number of attempts even the account is locked out of being logged into for a period.

Also after being logged into from multiple IP's in a short period it will be locked.

You guys seriously act like Blizzard just fell off the turnip truck here.

Unless the list of accounts you want to crack is tiny, a brute force attack easily gets around per-account rate limiting by simply switching to a different account before tripping it and coming back to the account later.

There's only say 12-15 million active accounts. Even if you had all of them you're going to run out of attempts before you reliably brute force anything. Far more likely is Blizzard looks out for large scale distributed brute force attacks and locks users to their last handful of confirmed IPs.

That's in the realm of speculation admittedly. Look I'm largely defending Blizzard here but they aren't paragons of security. For one thing they could stop a lot of actual real world keyloggers by putting in a randomized screen pin entry. They never did that but they have been pretty aggressive on many other fronts. The fact that their passwords are case insensitive is something that might surprise many people, (and I was mildly shocked when it was pointed out to me years back because I had been dutifully capitalizing 2 characters in my p/w....) but it ends up not being of much consequence imho. Almost all hacks have been keylogger or social. There's one rumored (confirmed?) MITM attack against the authenticator. There's probably some people that used 123456 etc. but the option for a more secure password probably wasn't going to help those people, ymmv.

Once you limit it to accounts actually worth hacking which don't have an authenticator you're probably looking at more like a million accounts.

Are you saying they have a number of proxy servers comparable to the keyspace? Because I'm pretty sure there aren't that many IPs.

EDIT: I just did a few calculations, there are 40 times as many elements in a 8-character password with only lowercase letters than there are IPv4 addresses.

Why do you need to compare in a case-insensitive manner? Just lowercase the password before hashing it, and the backend doesn't even have to care.

Quite surprised at the number of people who are worried about this, it's hardly complicated..

It's almost like I acknowledged that there were ways of doing it but expressed concerns for/of doubt that it was being done in the proper fashion due to the misguidedness of it.

I'll say for a third time, as you're not the first person to reply in kind, I'm more than well aware of ways this could be done, but none of them meet the typical expectation of how passwords are hashed and I would guess/assume that someone is far more likely to be insecurely storing passwords than going out of their way to store a... reduced entropy version of users' passwords in their database.

They're using SRP, which dictates that they're storing passwords (relatively) securely on their side. You don't have to guess; this stuff has been reversed.

Storing un-hashed passwords (encrypted or otherwise)?

I'm largely unaware of crypto outside of the general "use bcrypt" webapp cases. SRP is a fairly unknown field to me.

Edit: nevermind, you more or less confirmed this question further down this thread[1], and [2]

[1] http://news.ycombinator.com/item?id=4022996

[2] http://news.ycombinator.com/item?id=4023034

> I don't think anyone's nearly as concerned about case enforcement as they are about backend storage of passwords. I can assume ways of storing/verifying passwords that are case insensitive, but I'm not naive enough to assume they do.

Whilst I would hope they use a strong encryption scheme (with a variable work factor...), most of us know that even the biggest organisations in tech can fail miserably in this area.

But, I don't believe the majority of the forum posters see things the way we do. Many of them obviously correlate "case sensitivity" with "strong password", even though that's not exactly true.

And by encryption scheme, you really mean hashing scheme. Yup, it's easy to get confused.

Convert to some canonical case on the client side before applying SRP. It's very easy.

Reply on news.ycombinator.com