"Some data was illegally accessed, including a list of email addresses for global Battle.net users, outside of China. For players on North American servers (which generally includes players from North America, Latin America, Australia, New Zealand, and Southeast Asia) the answer to the personal security question, and information relating to Mobile and Dial-In Authenticators were also accessed. Based on what we currently know, this information alone is NOT enough for anyone to gain access to Battle.net accounts."
The part where it says, "answer to the personal security question" were accessed should be EXTREMELY ALARMING. This combined with an email addresses is usually enough to get your password reset on lots of sites. I believe this will reset your password on Google (assuming you're not using 2 factor).
When storing data on my server I always treat secret questions and answers the same as passwords, because that is exactly what they are. What use is a strong password if a weak secret answer can unlock the account? I salt and hash the secret answers just as I would passwords themselves.
Do these have to be human-confirmable? Wondering why they're stored in plaintext.. I've been curious about this before. Do you-folks store your challenge-question-answers in plaintext?
Possibly. I've been on phone support with companies that require me to tell them answers to my security questions. Also, automatic security question checking would require support for soft matches like capitalization or punctuation. You could simplify the data before hashing (strip special chars and convert to lower case), or store multiple hashes to each variant.
I really wish a lot more work went in to security question penetration testing. It's relatively easy for a determined attacker to come up with the correct answers to these questions (or convince a human that they know the answers). The recent iCloud breach makes me believe that in many cases the "security questions" practice is by far the weakest link in modern web authentication.
> The recent iCloud breach makes me believe that in many cases the "security questions" practice is by far the weakest link in modern web authentication.
> Do these have to be human-confirmable? Wondering why they're stored in plaintext.. I've been curious about this before. Do you-folks store your challenge-question-answers in plaintext?
I would hazard a guess that most sites store "Secret Questions/Answers" in plain text, or a two-way hash (that their support app reverses), as they are used to confirm identity along with the basics (DOB, address, email, etc).
- Mr. Berners-Lee
- Mr. Berners Lee
- Tim Berners-Lee
- Mr. Lee
Never mind if you had two different teachers who were great, and you switch them interchangeably depending on whether you're in an English mood or a Music mood
You need those answers exactly when you don't have the password, which means your 1password failed for some reason (otherwise you'd have the password from it). For me it usually happens with sites that generate their own passwords which I for some reason failed to enter into 1password some time ago (probably because I didn't use the site for a long time).
I think the bigger point is that a ton of signups use this question. Whether you say 'Mr. Smith' or 'Pecan Pie' isn't going to save you if you use it for all of them.
Actually, you often get to pick your question. If they don't hash the answer, however, you're screwed. It seems doable to me: drop on non alphanumeric (or something), split on whitespace, trim, lowercase, put back together. It beats the hell out of putting in the "right," googleable, answer. Sarah Palin can attest to that.
You could still do fuzzy matching with a one-way hash, you would just have to generate the fuzz beforehand. Create ten or twenty strings which you will also accept and hash and store them all.
I'm not a security expert, but yes. Hashing is, by definition, a one way process. If it is meant to be encrypted and decrypted it's, well, encryption...
I too use a random and unique Secret Answer each time I am prompted for one. The Rackspace people, who require the account's SQ/SA before they push you through to the real support people, think I'm weird.
That wouldn't help. For example, let's assume your question was, "Who was your favorite teacher growing up?" and your answer was "fish123jellybean456". If that answer is stored in plaintext (no encryption) in a database that's compromised, then it won't matter that it's not the "real" answer. Attackers will see it, and then use it to answer your security questions on other sites. The only way to protect against this is to ensure you use different answers on different sites.
Using a password instead of the correct answer to the question can be helpful, but in a totally different way. Specifically, it eliminates the risk that someone can guess (or research) the answer to your security questions.
For most people savy enough to use an arbitrary answer, it is because you can use a different one each time (with the very few exceptions where you may not be able, e.g. banks).
Offline portable password managers like Keepass/Password Safe/etc. are immense help for these non-bank services.
This is true. Blizzard is unbelievably strict about their account reclamation process. Several years ago I tried to access an account that had been in my ex-wife's name. When I told them that the ex-wife and I weren't in contact, they asked for a copy of the divorce decree, or separation paperwork, or whatever. Seriously.
Of course this was in the 2008 timeframe so maybe things have changed/loosened up since then.
This sort of thing kind of bothers me. Is Blizzard in the business of verifying state-issued identification? What prevents me from photoshopping my target's name on top of my own ID?
> "(Yes, I understand that there are ways to get those too)"
And at the point that someone can get a passable fake ID in your name, you have far bigger problems than their social-hacking an online service account.
This is only to remove an authenticator. I just changed my password and it didn't even send a confirmation email to confirm the change - it just changed it and sent me a notification email.
Secret questions are extreme bad security practice. They're essentially a way to trade off a large amount of user security for reduced customer support costs. It's the same as telling your users to pick a weak password (one that's very likely to be in a dictionary) and then give the attacker a hint what it is. On top of that, many providers (apparently Blizzard included) do not treat the answer to the security question as carefully as a password, e.g., they store it in plain text.
Agreed. I really dislike the "security question" feature a lot of sites force you to enter. In my opinion they make my account much less secure than it would be without this feature. There are plenty of people around who know my email address and have the means to find out my mother's maiden name, or what car I first had or whatever ridiculous information I'm forced to provide to "secure" my account.
This is ridiculous. Maybe the world is ending, because it feels like every major website/provider of some popular service is getting hacked these days. A company of Blizzard's stature and wallet size has no excuse for this kind of thing happening, no excuse at all. If you're charging people exorbitant amounts of cash to buy your games and then charging some of your customers a fee for the privilege of using your so-called "secure" servers every month then you should be providing a certain level of security in return, it's not rocket science - employ someone who knows how to secure a server.
This is certainly not limited to Blizzard, it seems like everyday there is a new story about some kind of security breach and then we're told to change our passwords and some details may have been stolen. As an owner of both Starcraft 2 and Diablo III and I am heavily disappointed especially considering how much I paid for both of those games here in Australia (bought digitally as well).
Blizzard is _literally_ under _constant_ attack and has an incredible security team in place. Obviously the only acceptable result is 100% attack deflection, but the idea that this could be or could have been anything short of an absolute top priority for the company is a ridiculous assertion that I'd expect on any other site, but not HN.
I'm a former Blizzard employee with knowledge of the situation and internal workings. EDIT: I am, of course, not remotely qualified to speak for Blizzard or the security team.
Security has nothing to do with preventing the attack, it's more so protecting the data much like a bank protects it's assets. It's pretty easy to break into a bank (they're merely glass and brick after all), but there is no way you're getting into that vault once inside and even so, if you get into the vault there are secondary security procedures in place to ensure that nothing is easily taken.
So regardless of whether or not Blizzard is under constant attack, just because someone can get in doesn't mean they should be able to take anything.. I really do hope Blizzard don't go into the banking industry because everyone will be lining up to steal what they can from the easily penetrable building and vault inside. There is no excuse.
If Blizzard is under constant attack, you'd think they'd be smarter about how data is stored and just what an attacker could see if they gained access to a database of any kind. So once again, my point was not about deflecting attacks because that's impossible, it's about making it almost impossible for the hacker to use any of the information he can access.
Just curious, are you actually a data security professional? Because while you have a very nice metaphor with the whole bank vault thing, you haven't offered any actual examples, or any specific criticisms of Blizzard's setup (not that we know what it was), or even examples of what you're talking about.
I know nothing about data security myself, but I'm not exactly learning anything about it from your posts. Sorry to be rudely blunt, but I've seen a lot of people who have no idea what Blizzard is up against, the difficulty/feasibility of protecting digital data, what Blizzard has in place, or even what Blizzard could/should have in place really criticizing Blizzard for incompetence here, and that's odd to me.
I may or may not be a data security professional, but I hardly see how that would make anything I've said more or less credible. Without knowing how Blizzard have set up their infrastructure, I can't really give any examples because each environment is different and requires different forms of security and protocols in place.
While Blizzard were apparently using SRP and while I can't say for sure I am guessing Blizzard are using the SRP authentication algorithm out-of-the-box which is bad for a number of reasons, but the main one being SRP by default is an over-glorified way of SHA1 encrypted and salting a password and by the sounds of it the hackers were able to access those salts and could theoretically brute force the passwords which by todays hardware capabilities is not very hard at all, this is LinkedIn all over again.
Take a look at the SRP design specification: http://srp.stanford.edu/design.html - if Blizzard didn't modify the algorithm, I think we've yet to see the full effects of this breach. LinkedIn learned the hard way and now one of the worlds largest multiplayer gaming companies is about to find out what a simple mistake like this can do. I hope for their sakes they customised SRP and if they didn't, I think we have the right to know.
As a Battle.net account holder, I have the right to voice my concerns about this. I paid money for the privilege of playing Blizzard's games - fortunately my Battle.net password is separate to that of any other account I have, but I feel sorry for the millions who re-use their password for their email accounts, Internet banking and other various accounts that could have all kinds of effects.
Would you mind stating what weaknesses you see in the unmodified SRP? Against a server compromise it's equivalent to salted hash storage, but it's impossible, in general, to do better without losing the ability to authenticate using the password (only).
Edit: do you mean the weakness of salted SHA-1? SRP is not defined for SHA-1 only.
I didn't say that at all. I said it's easy to break into a bank but getting into a vault in this day and age is impossible. And if you somehow by luck or knowledge get into the vault there are secondary, third, etc security procedures in place such as alarms, self-locking doors, cameras and heat/movement detectors.
A database is a vault. It's for storing things you don't want anyone to be able to access and even if a hacker can access it, they shouldn't be able to do anything with the data that they can see.
Banks get robbed all of the time, but the damage is minimal because the cash available over a counter is a write-down for a bank that keeps most of it's wealth in a vault onsite or offsite.
Bank vaults versus databases are entirely different.
A bank vault can be locked down. It's only accessible for a small set of hours per day and access is only given to a small number of people. People also don't need random access to a bank vault.
Website databases are more like cash registers. They need to be accessible 24/7 and nearly every transaction requires accessing it. Any person off the street is allowed into the store and you also have to trust the person at the register to know what they're doing. Even if you cover the case in lead, it still needs to open when a customer comes in.
It's also important to note that Blizzard did have the digital equivalent of "alarms, self-locking doors, cameras and heat/movement detectors". Many other data breaches haven't been noticed for months, if at all. Blizzard have responded in a timely manner, likely due to internal digital tripwires.
There is a far closer digital example to a bank vault and that's a Bitcoin wallet[1]. You have a hot wallet that's accessible via the server with enough money in it for most transactions and then a cold wallet that requires a person to interact with it (i.e. decrypt) for it to be of use. In the spate of Bitcoin server breaches, those implementing hot/cold wallets only lost the "cash available over [the] counter".
A major site storing authentication data should store it in a separate physical server, isolate that machine so that administrative access is not possible from the net (NO path from the net through to ssh or console server access to the auth server should be possible... that includes internet -> internal employee machine -> auth storage server). NAT and firewalls are irrelevant, because they do not protect against incoming attacks through tunnels initiated inside.
That may mean physical console only login access, if the general internal network has internet access. That's a necessary usability trade-off something as serious as an authentication database for ten million paying customers.
The authentication protocol to talk to the auth server should only allow simple (easily parsed) requests; they should be rate-limited, there should be no provision to check multiple hashes at a time, and it should be impossible to export hashes out of the auth server without administrative (console) access.
Similarly prudent precautions can be taken for backups of the auth data. The backup server encrypts the auth database, before writing it to an attached disk or whatever the scheme is. Several high-level employees then have usb keys with asymmetric keys, any of which (or any n of which) will decrypt the backups.
You can't air gap the auth server, but you can limit the attack surface so dramatically that you have a high degree of assurance that it's secure against network attacks aimed at authentication data disclosure.
Someone can own the webservers and collect passwords and one time auth tokens, and can compromise 2-factor seeds for users who are just setting up 2-factor, but that's far more limited than gaining access to hashes or seeds from auth servers.
This metaphor seems compelling, but it breaks down when you consider that in a digital break in, nothing physical must be moved. Were vault breaches like database breaches, one would merely have to look at the money to have a personal copy of it. This is a very different security scenario.
Not speaking for the security team, how likely would it be that this was an attack using reused passwords from another website?
How likely, specifically, is it that someone got into one or multiple employee accounts, found the admin console password lying around (or in an onboarding email that wasn't deleted, or in chat logs), and then accessed the internal admin site? The list of what was taken looks like it's straight from what a Support Rep would need to deal with password resets, OTPs, etc.
You are pointing your anger in the wrong direction. The reality is that security is a hard problem, much too hard for Blizzard, much too hard for RSA, much too hard for banks, and much too hard for governments.
Major companies being hacked is not a new phenomenon. What's new is them (a) detecting the hacks and (b) disclosing them. It's unfortunate but true; you should be happy that they are telling you.
You misunderstood my entire comment, but I can see why you would think I was angry. I'm disappointed, not angry. Disappointed that in this day and age, companies like Blizzard are making record profits and fall prey to attacks that are sometimes as simple as an SQL injection attack. While I am grateful they have told us about the attack, I'd much prefer the situation went like this: "We've been attacked, our database was compromised but because everything important is encrypted all they have is your email address"
Well, they're using SRP for authentication, which I didn't know about (and I don't consider myself especially illiterate when it comes to security), so it doesn't sound like they don't care about it.
Blizzard operates in a free market. Average consumers don't care that much about security until something happens, then they forget. Therefore, security isn't a priority to Blizzard. It is really as simple as that.
I was able to get an authenticator from Blizzrd years before my bank made it possible to do the same.
They care about security if only because they lose a lot of money spending time to fix up hacked accounts, and this will be even worse now they have a real-money auction house. In WoW they can just rollback items and if they duplicate some that were sold off by attackers it's no big deal. If they start duplicating real money then they need to pay out on it.
From my time reverse engineering the WoW client, I can tell you Blizzard uses SRP6 [1] for authentication. You'd have to really try hard to be storing anything other than a hash on the backend.
Down-thread [1], someone claims to have found SRP to be about 172 times slower than SHA1 on CPU due to the modular exponentiation and other overhead.
Some numbers run by zaroth (down-thread) [2] show that we could see 100k 1024-bit modular exponentiations per second on a new Intel Core i7 with the cryptography extensions. A 2011 implementation paper [3] had about
20k 1024-bit RSA decryptions per second on a GTX260 using Montgomery exponentiation, so it doesn't seem like using the GPU has that much benefit for performing modular exponentiation. I haven't had time to figure out an estimated price/attempt for SRP, so it's hard to compare to the existing SHA1 figures [4].
Still, if we take the 100k/second figure for modular exponentiation (extrapolated from the number of cycles per 1024-bit modexp on a Core i7), versus the 5B/s for SHA1 on a single GPU, being 50000 times slower than the best SHA1 speeds seems pretty good to me.
Oh wow, I wasn't aware of that. So the password (or a hash of it) never leaves the client, so an eavesdropper can never get any information? That's very interesting.
It looks like both parties end up with a session key, too, which is an added bonus.
Pretty much. The Blizzard guys know their shit. You wouldn't go wrong replicating anything they have done security wise, which is why this breach is surprising to me.
I'm concerned that this is happening so often that it is no longer raising eyebrows. It's becoming one of those "just how things work on the Internet, get used to it".
I agree. As long as the password authentication mechanism is in place, unique, random, and complex passwords are the best way to secure yourself. Unless you can memorize each of these unique passwords yourself, the next best thing is to use a secure password manager program to take care of this for you.
I follow this in practice, but I always have to wonder: what if someone gets my password database and breaks it? It would only take a keylogging trojan to get everything they needed.
I would be in for a world of hurt! Way worse than if a few of my accounts were compromised because I had used the same password. But still, the chances of being compromised are probably much smaller.
As mentioned by other people in other recent threads some good quality password safe programs work with Yubikey, so an attacker needs something you know (your password) and something you have (your Yubikey).
I'd be interested in seeing some robust analysis of password safe software. But "Password safe" and "keepass" appear to be reputable.
I'd also like a native, and trustworthy, password safe for OS X that can work with something like Yubikey.
Yubikey works just like Google Authenticator, except it is a little more convenient to type in the code. (you touch a physical button on the dongle, and it types the code for you)
It does not actually save any passwords. It would replace Google Authenticator or an RSA SecurID FOB.
Now this is convent, provided I don't have to access my password safe on a mobile device without a USB port. Does Yubikey have an app or work with Google Authenticator?
I know I can use LastPass with Google Authenticator to identify trusted devices. Still not perfect, but perfect security would be too inconvenient for anyone to use.
It depends on which service you actually use, but to my knowledge almost all of the worthy ones provide pre-generation of one-time passwords. Just get a bunch of those passwords on the paper in some proper place to fear the keyloggers no more.
Two-factor makes more sense. Relying on your database never getting hacked is nonsense. Is not a matter of are you getting hacked but when are you going to get hacked... expect getting hacked.
(disclaimer: I am the founder of Authy.com a two-factor auth API)
But secrets for the mobile authenticator are much less sensitive than passwords, which are prone to reuse. It does, however, defeat the security advantage of two-factor authentication.
(I always thought the really smart crackers would break in, modify the application code to weaken the password encryption, and then re-encrypt every password when the user logs in. Come back a few weeks later and collect a bunch of working passwords, with nobody the wiser.)
isn't it inevitable? Rogue employees, dumb mistakes, passwords will always be stolen: what's important is they're stored securely enough that when (not if) they are stolen they are worthless to the people that now hold the passwords.
With the hashes and salts stolen, please assume your password has been brute forced by the attacker (1 billion hashes per second with SHA1 is not expensive). This is LinkedIn all over again.
If Blizzard customized their SRP algorithm to use a more expensive hash than SHA1, they should come out and say it.
Otherwise, we should assume their statement that using SRP "means that each password would have to be deciphered individually" is nothing more than a salted SHA1. Combined with their reduced entropy password policy, all stored passwords are likely brute forced already.
cryptbe - I quoted the exact same text from the RFC in a post below. Sheesh...
From this it should be obvious to you that what SRP is doing is no better than SHA1 for protecting against dictionary attacks.
'g' and 'N' are well known numbers (also posted below). Username, and salt are known.
It's the perfect setup for high speed dictionary attacks. Please edit or delete your post. You can read my more lengthy post on this here: http://www.opine.me/blizzards-battle-net-hack/
I haven't studied SRP, but a quick look at it and it seems that one also needs to perform the v = g^x. While still vulnerable to brute forcing due to lack of entropy in a password, this is more expensive than bare SHA1. The opine.me post you linked elsewhere completely glosses this over.
edit: okay, just to give you some very rough numbers from 'openssl speed' on my machine. 16 byte SHA1 is about 1M/sec. Projected dsa256 (based on dsa512 and its ratio to dsa1024) signatures (most of which is an exponentiation) is about 3k/sec. It's certainly not a purpose-built tunable KDF, but it's orders of magnitude harder than SHA1.
Fixed the blog to give more credence to the ME op. Thanks for the great discussion mindslight & tedunangst.
I'm not trying to be sensationalist, but I think it's bullshit that Blizzard is saying SRP makes it "computationally very difficult and expensive" to extract the passwords from the stolen verified database.
Blizzard should come out and say, "the majority of our users' passwords have been stolen. If you have an extremely random password, you may be one of the few that were not cracked, but don't bet on it."
Just to keep the friendly banter going though, even Anandtech was getting better performance back in 2006 with his exponentiation: http://www.anandtech.com/show/2022/5
On EC2 c1.xlarge running AMI ami-ef5ff086 ($0.66 / hour):
./openssl speed rsa -multi 8
rsa 512 bits 54663.2 sign/s
rsa 1024 bits 10709.9 sign/s
./openssl speed dsa -multi 8
dsa 512 bits 56011.1 sign/s
dsa 1024 bits 20449.8 sign/s
So $100 would buy you... about 100 billion guesses?
See below, the algorithm is clearly specified in the RFC, and it's no better than plain SHA1 in terms of preventing dictionary attacks once the database is stolen.
Whatever logic you are using to prove that performing g^x is the same as computing plain sha1 would also prove that bcrypt and pbkdf2 are no better than sha1.
Finding 'x' given g, v, and N is HARD.
Calculating g^x is EASY. O(log X)
This is crypto 101 man...
This is why SRP is said to be verifier based and not password or password-equivalent based, because you cannot retrieve X from v.
But this is ALSO why the CREATOR of SRP Thomas Wu specifically states in his presentations on SRP that it does not resist dictionary attacks when the verifier database is stolen.
Right :-) Brute force is 'hard' - dictionary is not.
Calculating 'v' is a bit harder than SHA1 - there is a lot of research on performance of modular exponentiation since it is the foundation of crypto, but most of the current benchmarks are at 1024 or 2048 bit N.
Given that we have a mere 256-bit N, it looks like between 10k - 100k operations / sec is achievable with a modest budget. I should go benchmark this on Google Compute or EC2 GPU, but I need to sleep at some point.
Intel released a benchmark here: http://download.intel.com/design/intarch/PAPERS/324952.pdf claiming they can do 1024-bit ME in 2m cycles, and 512-bit ME in 250k cycles on an i7-2600. Assuming that means you can do 256-bit ME in 32k cycles, that's 100k / sec at 3.4GHz.
So an attacker takes a dictionary with 100k passwords in it (or just the top 10k, that works almost as well...) and tests them for each { username, salt, v }.
If you can do 100k tests per second, you can test 100k passwords for 100k users (10B tests total) in a little over a day. You won't successfully crack every password, but a well formed dictionary with top 100k passwords will crack a majority of them.
So don't tell me it's too slow to dictionary attack, ok?! :-)
SRP is supposed to make use of multiple types of entropy to ensure the passwords are far more complicated that salted SHA1.
While I agree it's possible that the attackers also got this information but I don't think we can jump to conclusions about the overall security of the passwords until more information is known.
(Also, computational complexity of crypto algorithms is usually specified in terms of nbits, not numeric magnitude)
(Although this argument has given me an idea for everyone that thinks using the same password on different sites is reasonable - a browser extension that runs a client-side KDF :P)
Actually, I forgot one minor thing. LinkedIn hashes were unsalted. Even assuming SRP is no better than sha1, cracking all of the battle.net passwords is going to be $number_of_users times harder than LinkedIn.
For a long time World of Warcraft accounts sold for more money on the black market than credit card numbers [1]. It was said that this was due to the fact that you could make money using those accounts (primarily through selling 'gold' or in game items) which could not get 'clawed back' by credit card companies.
So having battle.net get hit is a pretty cherry target.
That said, what is the current crack rate for SRP on a GPU for 7, 8 and 10 character passwords?
[1] This was one example but I've also seen other more credible reports on the eset blog. "WoW login I might want to check if they also have Diablo 3 on their account and vice versa. WoW accounts are already more valuable than credit card numbers on the black market, this will only increase their value." -- http://www.gosugamers.net/diablo/news/17557-it-s-the-economy...
> That said, what is the current crack rate for SRP on a GPU for 7, 8 and 10 character passwords?
That is a really good question, SRP is actually pretty serious. Based on the small amount I know about SRP, a simple rainbow table brute force attack would take a VERY VERY long time per hash; even on an extremely fast multiple gpu rig. Somebody with more specific knowledge about SRP could probably calculate an exact number.
However, since they have stolen other information (perhaps even some, like the modifier, salt or modulo data, that they have not disclosed) they could possibly create a more advanced and targeted rainbow table attack which would greatly reduce the time it would take per account.
> That said, what is the current crack rate for SRP on a GPU for 7, 8 and 10 character passwords?
If I understand the thing I just first heard about ten seconds ago, SRP is a protocol, not a hash. The passwords are hashed using some hash method, maybe SHA or bcrypt.
How is a breach like this detected and how would they determine what data was accessed? How likely is is that that other sites on the internet are breached but don't detect it? If the answer is too long and you could recommend a book or website I could read up on this topic, that would be awesome.
Breach is generally detected in one of two ways - information is sold and that leads to scrutiny when users write in, and/or you have auditing mechanisms (ip geolocation, for example) which points out behavior that does not seem to be correct.
Once you see this, you run through a full audit of all of your accesses, searching for things that don't fit a pattern. Logins of your admins — did they login at some time that they don't usually? Was there a login from a Russian/Chinese/Unusual IP? Did someone go into something they usually shouldn't? It's not an exact science, which is why it's really hard to do — you may never be sure what exactly was compromised.
Finally, how likely it is that other sites are breached: highly likely. The problem is that when you have leaked email/passwords, there's a large number of people that reuse passwords, and those people can be working at Blizzard, banks, or other companies. Unless they have proactive intrusion detection scanning in place, you don't know until after they've come in, looked at what they wanted to, and left.
Great, in Diablo 3, the only game I play, Blizzard forces you to be online at all times, even to play single player and they can't even look after your passwords.
So why am I finding out about this via HN/Kotaku? Why haven't I gotten an email from Blizzard yet? I haven't logged into my Battle.net account in the past few days, so maybe they're alerting people on login, but you know, a lot of people don't have the time to game every day, or even every week. An email alerting me to the need to change my password would be appreciated.
I know that marketing messages can take days to weeks to send out because of the incredible number of customers Blizzard has (and avoiding being flagged as spam an other considerations). It may be that an e-mail has started going out, but in the meantime the website and game launcher have been updated with messaging and Kotaku/WoW Insider/etc. is a pretty good way to get info to Blizzard's core player base.
The 16-character limit is not as bothersome to me as the fact that they go out of their way to set onpaste="false" in their HTML, making even 16-character passwords annoying because the average user has to type it all in by hand.
I will never understand the rationale for preventing me from pasting a strong password versus picking a weaker password that I have to type by hand. Currently, my workaround is to use "Inspect Element" with a Web Developer Extension and remove this rather unfortunate attribute.
I know that password manager tools like KeePass can type in the password letter-by-letter (but then, why not just allow paste?), but this automation is normally designed for login screens, not for password change forms.
Rather than doing this by hand via Firebug/Chrome Inspect Element, it might be worth looking into creating a quick Chrome Extension or Firefox Add-On (or even a userscript) to do this for you.
I understand the initial rationale behind not allowing you to paste a password:
(1) Pasting a password can allow a malicious user to find your password somewhere and paste it in (as it would take much more time to type by hand).
This doesn't make any sense - as you pointed out, there are programmatic ways to avoid actually being unable to paste. Furthermore, a malicious user going through a password list would likely be using a command line interface or script, and not bothering with a GUI anyway. I'd call this issue completely moot.
(2) You could accidentally paste it somewhere else.
This has a little more value, but it doesn't come anywhere close to being a valid reason to disallow pasting. The security benefits of using a secure password manager (like KeePass or a TrueCrypt volume with a password list) are so much greater than Blizzard (or anyone) worrying about what you're going to do with your paste buffer.
The problem with putting any limitations on passwords that a user can use is that they almost always backfire. Sure, it might have made more sense when hashing algorithms crapped out after several characters, but in today's world those hashing algorithms shouldn't be used anyway.
(3) you type your intended password wrong, copy it, paste it, and lock yourself out. The sites make you type the password twice is to make sure you did it right. People who can't be bothered to type a password twice are probably heavily intersecting with people who didn't type it right the first time.
This seems somewhat contrived, but in realm of plausible, so let's say it's in the fact the reason for doing so. If so, why do you think that the old/current password field also has paste disabled?
I think an easy solution (that perhaps I just haven't found) in KeePass is to have a feature like "Perform Auto-Type" (which does the full login and password typing sequence), but for any arbitrary field. If I could find that, then this would be a moot issue for me.
Any password length limitation (within reason, not allowing a 1MB password is reasonable) says to me "we are not using hashes". That may or may not be the actual case, but it's the only reason I can think of for limiting password length. Hashes used for passwords have fixed lengths regardless of input, so any length password will "fit" in a database column.
If you're using hashes, limiting the lengths of passwords is extra work.
I'm not talking about Battle.net specifically. I'm talking about in general. That's merely the impression that a password length limit gives to me, on any site. Can you think of any another "rational" reason for limiting password length? I see two possibilities:
1. They're not using hashes.
2. They are using hashes, but they don't understand what that actually does, and that there's no reason to have a limit on input length. The passwords might be more secure, but it calls into question the general competency of their security (do they salt? per user?).
This also applies to character restrictions (no ____ characters). I can understand requiring at least N instances of a class of characters, but the entire UTF-8 character set should be valid input. If I want an emoji password, there's no reason to disallow it. bcrypt will be happy to take those bytes.
So, here's a comparison of site purposes and security practices. This is largely unrelated, but it gives better insight as to what I was talking about, not just making a random assumption about Battle.net (which I theoretically have an account at, but I don't really care about it anymore, I don't play video games anymore).
Chase is a bank. They handle money. They allow up to 32 character passwords, with no "special" (whatever that means) characters whatsoever.
Twitter is a social networking site. I have a 50 character password of various character types, because that's how far 1Password will go.
Bank of America is also a bank. Twenty characters. Twenty. Characters. And none of those are allowed to be "special".
Facebook is user for the same purpose Twitter. I have a 50 character password there as well.
Why do I trust social sites more than my banks? Security is so messed up.
If you are to abide by CWE-521: Weak Password Requirements. Then all passwords must have a min and max password length.
There are two reasons for this. For one, hashing a large amount of data can cause significant resource consumption on behalf of the server and would be an easy target for Denial of Service. Especially if the server is using key stretching such as PBKDF2.
The other concerns is hash length-extension attacks or the prefixing attack against MD5. However If you are using a hash function that isn't broken, such as bcrypt or sha-256 and you aren't using an HMAC, then this shouldn't be a concern.
In general maybe but if you have safeguards in place such that 16 character passwords can't be bruteforced than you don't gain much by going to 256. Every hack/stolen account I've ever heard about was spoof login/keylogger/MITM, social or same p/w from another service that kept it in plaintext. I'd guess some people just got hacked because they use the most common p/w's ("12345678", etc.). 256 characters wouldn't help any of those people
So I went to update my password for my World of Warcraft account after I saw this.
And guess what I discovered, my current password is more secure than their current password policy will allow. So I filled out a support ticket with the following question (which all Blizzard account holders should ask them)
I was wondering why even after you discovered a security breach you have not updated your password policy to actually allow secure passwords. Your current password policy only allows password that will take a day or two to brute force crack. see http://xkcd.com/936/
These two rules totally nullify any security of your passwords
"Your password must be between 8–16 characters in length.
Your password may only contain alphabetic characters (A–Z), numeric characters (0–9), and punctuation."
In fact my current password is better since I apparently created it before your policy changed to not allow non alpha-numeric characters.
The only reason to have those two rules is because you are storing the password in plain text so anyone who gets access to the database can read them freely. Please update your password policy to
"Your password must be at least 20 characters long."
That is it, let me make a 400 character password if I want, let me use cyrillic, chinese, or whatever other unicode characters I want to use. If you truly care about security you will fix your broken password policy!
> "The only reason to have those two rules is because you are storing the password in plain text so anyone who gets access to the database can read them freely."
That is certainly not the only reason to have those rules; in fact, it's probably one of the least popular reasons.
It's done to keep customers creating short-ish passwords, which are likely to be more memorable, and therefore reduce the support load for password resets.
Whether this is actually effective or not is another thing entirely.
they have a "I am an idiot and forgot my password" button so people forgetting their passwords is no additional support, and if they allow longer password it actually makes them easier for people to remember and harder to crack, win win.
As far as I can tell, you can't. But Blizzard has announced that they will be putting something in place for users to do that in the next few days. Keep an eye on your B.Net email.
I'm not surprised - Blizzard don't understand the meaning of security in the first place! For instance: the passwords that a user chooses are case-insensitive. Feel free to try this one out on your battlenet account!
Here's some detailed information on what happened [1]. A press release from Mike Morhaime [2]. Also, they're currently working on allowing users update their secret question and answers [3].
> and information relating to Mobile and Dial-In Authenticators were also accessed.
I don't know a ton about 2 factor auth implementation details, but I'm assuming that if you were able to access the serial # or whatever is used to uniquely identify an authenticator, you could generate valid tokens, essentially rendering the 2 factor auth useless?
If so, and if they were also able to access information about the key fob authenticators, that could be messy. Hopefully that isn't the case.
Why is it OK to have the security answers not hashed? They are just secondary passwords, and there is absolutely no reason someone else needs to know it.
Because they need to do really fuzzy matching for call-in support, which is where the security question gets most used. Hashing makes that impossible and raises the average call length since the agent would have to type each response rather than simply compare to the answer on screen. No amount of normalization would make "The Blue Dragons" match "Dragons" or "Warwick Elementary School" match "Warwick", or whatever the answers to the questions are. Security questions aren't precise like passwords.
I still haven't received an email about this. My last email from blizzard was three months ago when I bought D3. I hope they plan on sending out something soon with a good explanation on why hackers having your ASQ is a really bad thing.
Looks like Vivendi should have moved quicker with their plans on selling Activision Blizzard. Poor guys.
I wonder how much this sad news will impact the success of the WoW: Mists of Pandaria (launch planned on 09/25).
Bring on touch screens with print scanners. I really hate login/pass. I realize in away the more secure the token the more private it can become but the screens could at least check for a pulse too. (it's late)
16 character max password with no special characters allowed.
.. Are you people high or something? This is 2012, when every major provider has been owned at least once. Not AOL circa 1995. Get with the program, Blizzard!
While that is bad, according to my napkin calculations that still gives you 82 bits of entropy for your password (if you randomly generate it, taking into account that they aren't case-sensitive {seriously}).
82 bits is actually "good enough" so, for now, not too big a deal. The bigger deal is the SHA1 + salt hash they're using to store them!
The part where it says, "answer to the personal security question" were accessed should be EXTREMELY ALARMING. This combined with an email addresses is usually enough to get your password reset on lots of sites. I believe this will reset your password on Google (assuming you're not using 2 factor).