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.
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.
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).
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.
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).
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.
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.
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.
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.
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?
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:
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.
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.
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.
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?
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".
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)
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.
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.
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.
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.
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...
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
>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.
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.
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.
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.
> 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.
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.)
> 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.
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.
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.
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.
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.
> 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..
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.
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.
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.
