Diablo 3 bug report: "Passwords not case-sensitive." | Hacker News Reader

Diablo 3 bug report: "Passwords not case-sensitive."

us.battle.net

133 pointsryanf149 comments

  Entropy of    [a-z0-9] per character : 5,1  bits
  Entropy of [A-Za-z0-9] per character : 5,95 bits
  Entropy lost by case insensitivity
                        (per character): 0,85 bits (15%)

Bottom line: add 2 characters, and your password stays strong. Still, it would cool to warn users, or at least explicitly advise them to use longer passwords.

Or if you care just use an authenticator which adds significant entropy without forcing you to remember anything.

http://us.blizzard.com/store/search.xml?q=authenticator they all have free android / iOS apps.

Not only is the entropy difference small, there is also an added benefit in less users having to reset their password. Forgetting how their password was capitalized is a big problem for people.

Letting improved user experience trump a tiny bit of extra security is a good tradeoff for Blizzard. They're not a bank.

FWIW, I think I read at one point that WoW accounts were worth more on the black market than credit card numbers. So security isn't totally unimportant.

I wonder if this (to some extent) offsets the loss of security by converting to uppercase. I know that I have reduced the complexity of passwords I forget (often by limiting them to lowercase), so I suspect other users do the same when they reset.

> They're not a bank.

Definitely not. My bank forces me to use only numbers, and only six of them. Strooonng security. The only way out of key loggers I suppose (they make me click on numbered boxes).

Facebook does sort of the same thing:

http://www.zdnet.com/blog/facebook/facebook-passwords-are-no...

Yes, it's possibly less secure. But for both Facebook and all of the Blizzard games there are other options if you are concerned.

Makes sense.

Facebook's is a little better - you can't disregard case entirely. Blizzard just cut the search space by a lot.

Then again, it would be pretty difficult to brute force a password in Battle.net, to be honest. I'm assuming they'd lock out the account after just a handful of tries.

> Then again, it would be pretty difficult to brute force a password in Battle.net, to be honest. I'm assuming they'd lock out the account after just a handful of tries.

Correct. ~5 failed attempts forces you to use your authenticator code, and if you don't have one, you need to use their reset form and a captcha.

The game clients will lock an account out after ~20 or 30 attempts and I assume the website will do the same. No one is going to brute force an account.

Yea, until someone steals their hashes.

All your hashes are belong to us

But there are plenty of password stretching algorithms like bcrypt.

A very reduced keyspace, but we all knew people's password choices are poor anyway right?

Which is easier said than done. Honestly if someone can do that, you have bigger problems to worry about.

Related, but different in an important way.

If your password is aBc, you can log in to Facebook using aBc (original), AbC (windows caps lock), and ABc (first cap) only. For a regular password, this is just slightly less secure.

Being case insensitive entirely is quite a bit less secure (abc, abC, aBc, aBC, Abc, AbC, ABc, ABC).

I wonder how they do that. If they store the password hashed, wouldn't they have to normalize it two/three different ways and store a hash for each?

Or perhaps they aren't storing it hashed ...

Facebook won't make that mistake.

Facebook are not that stupid.

No, they only need to store a single hashed password. For authentication they can just try out the other 2 transformations above and see if any of them matches what's on file.

thereis no multiple transformations, they just lcase every pwd input before hashing. the stored hash is a the hash of the lcase pwd.

They have your un-hashed password when the form is submitted, they can try all three, hash them, and compare those to the saved hash.

They would only have to store a single hash - the proper password.

When you log in to Facebook, they hash the password you gave them and try that. If it fails, they modify the password you gave them, reversing the case on all letters (and possibly convert numbers to special characters, or vice versa - I don't know if they go that far), and hash that.

Remember that when you log in, the server is receiving your password in plain text. Facebook is just "massaging" that data a bit (possibly several times) to try to correct a user error, rather than just bailing at the first sign of trouble.

The only problem with that is that it's ripe for timing attacks. I _hope_ they always check all three passwords anyway.

Exposing the timing here can only tell you one thing: the password that you're trying works for Facebook, but the capitalization might be wrong if you're using it to get into the user's account on another site. But since there are only three variants on the password, it gives you effectively nothing. This would be insanely difficult to pull off (many, many login samples) for absolutely no payoff; they might as well save the extra hashes if it works the first time.

Hi, interested in the above comment. Can you explain how a timing attack would work here?

An interesting demo: [1] By not doing all 3 hashes, an attacker might realise that the password they sent passed, say, 2 checks, but not the third. This discloses information about the relationship between the password the attacker just tried and the correct password.

[1] http://carlos.bueno.org/2011/10/timing.html

I'm not sure how this is applicable here, if the attacker passes any of the tests then they are able to log in

Indeed, stupid logic on my part.

I see the problem in theory, but in reality, the time of a couple of hash functions compared to network latency and application server routing would be quite small. Can timing attacks actually work in such situations?

Can you do a timing attack against something as fast as a case conversion and a hash function, even if it has a work factor? Normally they're done against database requests aren't they?

"Remote Timing Attacks are Practical"

https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

I know you can do timing attacks through the network, it's not even that hard in the simple case.

That paper, like most papers on timing attacks, was done on the local network, not the internet. They're relying on absurdly precise measurements of absolutely tiny differences in timing, which would be lost in the jitter and latency of the real internet.

As I said, you can certainly do internet timing attacks where you're looking for database access, because this can take many milliseconds, which is a delay which can be detected even on a crappy internet link using a bit of light statistics.

Right; I guess my thought is that since a hash with a modest work function can also take many milliseconds, this would be meaningful. Not sure in practice, however.

You can't do a timing attack against a password hashed serverside, since you don't control the string being compared enough to make iterated byte-at-a-time changes.

Even if I'm misunderstanding, though, this particular remote timing attack is probably not practical in most programming environments; (for instance) straight C memcmp is below the measurement floor, even with signal processing.

That is a great paper; also, check out Crosby and Wallach for the modernized, math-ier take; with signal processing, the measurement limits are nanoseconds on a switched LAN (ie, if you could get a box deployed in the same hosting center as Blizzard) and tens of milliseconds over the Internet:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.65.9...

... and Nate Lawson's Black Hat talk which actually goes through the practical issues trying to set up and run these attacks against real systems:

http://www.youtube.com/watch?v=A0T8o-Aq3yY

There was a nice talk at 28c3 called "time is on my side" by Sebastian Schinzel, specifically about timing attacks over the net; it is pleasingly practical in its approach. He attacks the popular typo3 CMS.

http://www.youtube.com/watch?v=ykNt8pSQFZQ

It's very modern, as you describe, with all the fancy maths and all that.

This is really great. Thanks for sharing it.

Why not just lcase everything during initial hashing and later auth?

sha1sum(lcase($passwd). $salt);

because as nostromo said then uppercase counts for nothing. Facebook only lets you log in if you accidentally use cap-lock or accidentally capitalize the first letter(quite common on phones). If you lowercased the whole password first, you reduce the benefit of having uppercase characters at all.

Ah, I missed that, sorry.

I think the point stands for the Blizzard case - there seems to be an assumption in some corners that the password is stored plain text, but I would imagine case neutralised (so to speak) passwords are hashed.

there is no multiple transformations, they just lcase every pwd input before hashing. the stored hash is the hash of the lcase pwd.

I was referring to Facebook with my comment, not Diablo 3.

Facebook massages the data to allow you to login even if you have caps lock on, so "pASSWORD" works when your password is "Password", or if, e.g., your phone capitalizes the first character in your password, so "Password" works when your password is "password".

I don't under stand the confusion in the other replies here.

1) lowercase inputted password. 2) hash password 3) compare hash to db hash (which was from a lowercased initial password).

Because this isn't how they do it. that method is the same as the Blizzard method, and it is a lot less secure than transforming the plain text and trying the three different combinations(normal, uppercase first and capslock password)

Ah, sorry, I missed the top of this reply-thread. I was referring to the story, not Facebook. :-)

They could normalize it in the following way before storing a hash:

1. If the last letter in the string is uppercase, flip the case of the entire string.

2. Make the first character lowercase.

This would allow for abC as well (if you "capitalized" the first letter while holding down capslock).

Facebook doesn't restrict length of password, though - at least not to the same extent.

This story was on HN (albeit from a different source) a couple of weeks ago. https://news.ycombinator.com/item?id=3920918

Not a bug.

If you're worried about security as a user, d/l the free authenticator.

If you're worried about Blizzard, don't -- they're big kids. You can run your 10+ million user game platform the way you want, Blizzard will run theirs the way they want.

Just like how we shouldn't worry about big kids Sony and their 70+ million network being compromised?

Telling people not to worry about security works until they, inevitably, have their data compromised. Technically aware consumers have a responsibility to put pressure on companies to be secure with information.

Did Sony offer a free authenticator? At any rate I'm not shedding tears for Sony if that's what you're asking.

"Technically aware consumers have a responsibility to put pressure on companies to be secure with information."

No one's shown that Blizzard has been unsecure with anyone's information. I see a lot of people running around like the sky is falling when it's not.

Precisely the same way, yes. Sony's network being compromised had absolutely nothing to do with password case sensitivity, and absolutely everything to do with shoddy practices elsewhere that opened a massive hole into their database, allowing them to download millions of accounts worth of data.

Millions of accounts from a single breach somewhere. Not millions of accounts individually brute forced because their case-insensitive passwords made them trivially guessable.

We should be worried that Blizzard will get hacked like PSN was. That would be potentially catastrophic. But case sensitivity has almost no effect on password security unless your users ALL use random passwords.

So I need to buy a smartphone to enjoy basic security features.

I wouldn't call the authenticator "basic security"; it's a very high level of additional security. For a video game.

And if you don't have a smartphone (spoilers you probably do) and you wanted an authenticator you could buy the token or emulate it on the OS of your choice...

http://developer.android.com/guide/developing/tools/emulator...

or on any java device apparently:

http://arenabooster.marisil.org/bma.htm

I believe that they also now allow authentication over SMS.

Edit: it's not quite an authenticator: http://us.battle.net/support/en/article/battlenet-sms-protec...

edit: I said something stupid here. Nothing to see here, move along.

Passwords being case insensitive implies that they are storing passwords as clear text.

What? No it doesn't. They could just lower case all the password submissions and store the hashed version of that. When someone tries to log in, lower case what they enter, hash it, and compare to hash (or whatever the specifics are)

Yeah, blizzard are big kids, they would never be so astoundingly incompetent as to do something like say, trust the client to decide whether or not a character is realm. Oh wait, yeah they did that didn't they? But surely they would never be so incompetent as to trust the client to tell the server the clients co-ords right? Oh no, they did they too (and still do!). Seriously, blizzard's demonstrated repeatedly that they either do not understand security, or do not care about security. Either way, "trust them because they have lots of users" is ridiculous.

Complete security newbie here. Doesn't it make brute force attacks almost worthless when you just have a minimum time between each login request after too many attempts per IP ? So you can only try to login every 30sec after you've failed 10 times in a row? I thought brute-forcing logins were a thing of the past after people started implementing this min time between requests strategy.

The only weakness I can imagine would be a massive botnet forcing logins, but even then it would be severely limited. Am I missing something silly?

Correct, the heavy lifting for basic security is not done with a pw that has 50 bits of entropy and drives off your casual playerbase, it's done on blizzard's backend with lockouts after a few failed attempts.

>Am I missing something silly?

Yes. It's not that the bad guys try bruteforce to login multiple times and wait to be banned. They could (will/might) steal db with hashed passwords, do their decrypting at home and then login with what they got. The stronger the password (or better, ie slower to calculate hash used) the more time they need for that thus giving more time for Blizzard to realize passwords were compromised and block all accounts/force global password change. Really clever bad guys can do their homework before they have a chance to put their hands on hashed passwords by preparing hashes for say all passwords which are simple combination of words [1]. Now, once password db is compromised they just look for matching hashes and have instant access to some accounts. This is why you are told to use "strong" passwords, if they just try to "bruteforce log-in" that really wouldn't matter much.

[1] http://en.wikipedia.org/wiki/Rainbow_table

This assumes they aren't salting the hashes. But Blizzard apparently[1] uses SRP 6+ which does salt the hashes meaning if you and me have the same password we will still have unique hashes.

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

Just so you know, every variant of SRP is randomized, not just SRP6, and every variant of SRP has parameters that can to some extent be tweaked to provide variable work factors.

That's cool, I had never heard of this.

How is the salt stored to make sure attackers won't just steal your salt anyway? Wikipedia says "the salt is stored along with the output of the one-way function" [1]. Does it means the server needs to store the salt for each user so it can authenticate the password?

[1] http://en.wikipedia.org/wiki/Salt_(cryptography)

Every randomized password hash does exactly this; the randomizing nonce is tiny compared to the hash itself.

As the defender, you don't care if the salt is obtained by the attacker. The salt is not a secret. It's only use is to ensure that each password is hashed as unique, even if the users chose the same password. Basically, it is for defeating precomputed databases (rainbow tables), nothing more.

You store a salt per user. Salts protect against rainbow table attacks. The salt doesn't have to be private for it to be effective at that task.

Besides the salt point others have made, I've also read (on HN) that rainbow tables aren't much use anymore because the speed/storage equation has changed. If your hashing mechanism is dumb enough not to use salts, it is also fast enough to calculate that there's no point doing it in advance.

Although this is a really silly bug, I did already know about it (it's the same in WoW), so frankly at the moment, I'm more concerned about the Diablo 3 bug which is causing a lot of us to not be able to successfully login and play, at all.

Really not good.

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

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.

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.

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

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

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.

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.

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.

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

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.

Use a passphrase then if this bothers you?

If you want to be serious about security of your account, use one of the two factor authentication systems available that they offer.

The faster passwords stop looking like: C@tV0m!t

And start looking like: correct battery horse staple

the better for security and actually remembering the phrase rather than writing it down.

(XKCD on this: http://xkcd.com/936/)

Well, in the same forum there's also this: http://us.battle.net/d3/en/forum/topic/5149150816

    I don't understand why there is a 16 character limit on user passwords.

It's not technically a limit, as much as a truncation.

I still would be happy if they lengthened that.

I'd say it's a limit caused by truncation, but this is rather irrelevant.

One has to imagine that the actual phrase "correct battery horse staple" is a fairly poor choice of password, at this point though...

I'm using "archaic hello dog waterpool" so i'm safe.

Yes, I agree with that.

They don't (or didn't, I haven't checked in the last few months) allow special characters, either. Seriously - what? (Then again, my bank does the same thing.)

So use a long password without them: password strength is what counts, not funny rules about special characters and minimum characters.

This is not the point.

Users are put at risk because Blizzard fails to adequately impose security. Tech savvy users can just use a stronger password, but the others are put at risk by what I can only call negligence.

(based on my anecdotal evidence) Most "normal" people do not use caps letters in their passwords. If you force them to do it, they'll capitalize the first letter and that's it. Compared to this, the lower amount of password-related troubles and customer service probably results in better overall password security.

Phishing, keyloggers and various social hacks are the real problem. Blizzard has always been very active in this regard with their constant and visible reminders that "Blizzard will NEVER ask for your password", but most users disregard even that.

My fault. I didn't explain properly. I didn't mean it in the normal way- to require strict passwords. I meant in the sense that users who do add a capital in order to up their account security don't get that security added. Only users who know about this bug and go the extra mile then will benefit from the view of "So just make a better password without."

I apologize if this is worded badly. I'm not feeling up to my usual ritual of rewording my post until I'm convinced it makes perfect sense to those who don't have magical insight into my mind.

I think the point here is that if goofy capitalization is the only thing that kept your password from being trivially guessable, your password was only a little bit harder to guess. If your password isn't guessable, then it doesn't really matter if you have additional entropy, because the server smacks down brute-force attempts before they even get off the ground. In other words, it doesn't seem like capital letters make your password appreciably more secure in this context.

That's exactly the problem here. A typical user who adds capitalization to make her password more difficult to guess is basically screwed over by Blizzard who has decided that passwords don't need to be case-sensitive.

Users who opt to (I'm not talking about forcing users to use capitalization here) to use capitalization for a more secure password are unaware that their efforts are in vain.

Also, it isn't only trivially more guessable. That's nonsense. If you're using a password list and you capitalize only the first letter of every password in that list, that list is still double the size of the first list.

They also restrict it to <= 16 characters.... Yea, that's still decently secure, but there's nothing like a 50 character password that's pretty much impossible to break. I don't get why they put these restrictions on. Probably some brainless dev decided to make a SQL column 16-bytes wide.

EDIT: That doesn't even make sense, unless they're storing plain-text passwords.

If you're at the point of needing a 50 character passcode for your blizzard game maybe you should just download the free authenticator.

OK, where can I download that free authenticator for my Nokia S60?

Run java?

http://arenabooster.marisil.org/bma.htm

Nope:

    The Java-based (J2ME) versions of the Battle.net Mobile Authenticator previously
    available through this website have been discontinued.

http://eu.blizzard.com/en-gb/mobile/

Well, they do offer http://us.battle.net/support/en/article/battlenet-sms-protec... which provides an extra (but different) layer of security.

Assuming you're from one of the "supported countries", though, which aren't listed.

Find an apk and toss it on an Android emulator?

Two-factor authentication shouldn't be a replacement for a good password scheme, it should supplement it. Otherwise it's one-and-a-half factor. :)

They limit to 16 characters silently. I used a 32-character password for quite some time and wasn't aware that it was silently being truncated to 16.

There was a site I used where one password field was something like 20 chars max, the other was 50. So I could change my password but never log in with it.

That company was namecheap, if I remember rightly.

> They don't (or didn't, I haven't checked in the last few months) allow special characters, either. Seriously - what? (Then again, my bank does the same thing.)

This is not entirely correct. They do allow some types of punctuation, and have done for a very long while. I haven't tested characters like #, @, & (etc) though, but periods and the like have worked.

Fun fact: most banks don't enforce case-sensitivity for passwords either

Not true at all. My password is long and complex, complete with many different special characters.

That seemed like a pretty bad way to handle it by Blizzard, though.

I agree, the mods on that forum seem like they forgot where their last straw went.

If there is brute force protection on the login function blocking a username or IP from attempting x times in y hours AND there is a minimum of 8 characters then I can say thats strong protection on the backend. You are much more vulnerable to having your password phished rather than bruteforced.

This isn't a bug at all. I would question the assumption that case sensitivity increases the actual search space significantly, theoretically it does but in practise most users will:

- Uppercase first letter only

- All lowercase

It's a usability decision from Blizzard, not a bug.

Also, to address this comment in the thread:

> This means they probably store passwords in plain text, unsalted, etc. This is unbelievable.

It absolutely does not make that any more likely. All you have to do is normalize it to upper/lower case before hashing and you have case insensitivity.

Not sure about Diablo but one of the reasons I can think of why some web site's password is case in-sensitive (it is not uncommon) - they are checking the user password directly with MySQL, e.g.

select * from users where user = 'john' and password = 'PASSWORD'; -- the password is actually case in-sensitive if your table collation is ci (which is the default)

Of course this also implies the site is storing the password as plain text..

is that true if "password" is char or varchar as well? Or only for text fields?

For nonbinary strings (CHAR, VARCHAR, TEXT), string searches use the collation of the comparison operands

The default character set and collation are latin1 and latin1_swedish_ci, so nonbinary string comparisons are case insensitive by default.

http://dev.mysql.com/doc/refman/5.1/en/case-sensitivity.html

In that case there is a much much much bigger problem than case sensitivity.

Hint: storing passwords in plain text

That or they just do `password.lower()`

That's not what Battle.net does. They use SRP, which dictates a specific strong cryptographic storage.

This wouldn't be so bad if they didn't restrict their passwords to at most 16 characters :(.

When are we, as a society, going to solve the password problem?

Passwords are a terrible mechanism for solving security - to make them "secure" you have to enforce stringent policies creating passwords that are not memorable to many users, leading to passwords being written down. Add in the fun of needed to know far too many passwords (my daily count is at 17...).

Honestly I don't know enough about cryptography or security in general, but could an application be locked down using a public/private key (ala, SSH)? I'd love the ability to generate my own key (with my own password) and assign it to any application.

Probably when bio-based methods of authentication become cheaper and more commonplace. The problem is the passwords themselves: having to remember something arbitrary and outside the normal context of your day.

Hell, their sole purpose is to be cumbersome.

I am interested to know how are they storing case insensitive passwords if they were not plain text, they only way I could imagine is by converting them in a full lower/upper case before hashing is performed.

You answered your own question.

I'm curious, why would you doubt that your "only way" would not be what they do? It works, it's simple, it has no downsides.

Some people think that they must be storing the passwords in plain text ( http://news.ycombinator.com/item?id=4022765)

What about, battletags do not obey real id preferences in your battlnet account? As in, I was in Diablo 3 beta. I joined numerous public groups.

Apparently anyone who was in those groups can now see if I play World of Warcraft, which server I am on, and even what zone I am in.

and there is nothing I can do about it. Zero, zilch, oh except buy Diablo 3 and change my settings from there because it can access features of my account the standard account management system cannot.

Is it completely beyond the bounds of possibility that they're storing the password as originally entered (salted & hashed), but trying all combinations of upper / lower case at login-time (only after the entered password fails)? It would only be for a small subset of logins, and for the majority of passwords, a manageable number of combinations (2^num-alpha-chars-in-passwd). I believe Facebook do something similar.

I run a phone emulator and run the blizzard authenticator app on it.Works great for me and adds some security.

Doesn't that kind of defeat the purpose of two-factor authentication?

Also, most banks don't enforce case-sensitivity. I just logged in to my Chase account ignoring the case.

This has been the case since as long as I can remember. Not sure why it's an issue all of a sudden.

The following banks and financial institutions also silently discard case-sensitivity:

Citibank

Chase

Wells Fargo

E-Trade

US Bank

Fidelity Investments

SECU

HSBC

TechCU

I just tried my American Express account and you can add that to the list of financial institutions discarding case-sensitivity.

Reply on news.ycombinator.com