I am a CompTIA Security+ Certified technician. Holding this certification is one of my proudest professional accomplishments – it was not easy. I failed the test the first four times I took it. I spent six months studying, preparing, and practising to pass the test (not six months where I did this in addition to other things; this was the only professional activity I engaged in for the entire period). This test isn’t something you can squeeze by – the only passing grade is an A, with over 90% of answers correct (if I recall correctly, you can only give five incorrect answers on the 60 question test, total.) I am, in fact, a voice of authority on the subject of computer security.
So with that grounding, I shall now address this post from ArenaNet’s Mike O’Brien.
Many network security decisions are being made these days by those with no grounding or training in security. It is obvious to me that this is the case, because virtually all of these new security measures fail the first lesson of security. Making a system secure is easy. I can lock a server in a closet, behind two locked doors, with no network access, and no one will ever crack the system. But no one will ever use the system either. Network security is not an exercise in creating a secure system. It’s an exercise in balancing security with usability. No security works that your users actively try to circumvent. The more complicated and inconvenient your security, the more likely it is to develop holes and subsequent breaches.
90% of security breaches are user-based. There is literally nothing an IT professional can do about these breaches. Users allow their credentials to get leaked, or they ignorantly and blissfully open the door for attackers, thinking they are being helpful, clever, and/or convenient. Users will write down their passwords, store them in electronic files, or find other ways of easily reminding themselves of their credentials that can be accessed by malicious intruders. No policy, technology, or encryption can save users from themselves.
This isn’t to say there are not things companies can do to help ensure their users’ accounts are secure; however, almost all good security decisions involve internal protections, not external. These protections largely involve how credentials are stored and encrypted – and they should be encrypted. Any company that stores account information in plain text is being criminally negligent. There’s simply no excuse for such a thing (although it still happens, and is one of the major reasons many passwords have been hacked recently.)
Last month, ArsTechnica ran this article, giving a lot of insider information on how modern account hacking works. Brute force attacks are a thing of the past; the modern attack does not try every possible letter/number/symbol combination, but instead relies on patterns, existing cracked passwords, and combinations to discover passwords. XKCD’s advice, linked by O’Brien, is subject to just this sort of pattern attack, and such passwords are much less secure than the math would suggest (the math is not incorrect – the 11 bits of entropy comes from an assumption that each “common word” is drawn from a list of 2000 (actually 2048) of the most common words, thus it’s that complexity 4 times – although one can assume no repeating values, which does take a year off the time-to-crack.)
(A note on “Tr0ub4dor&3” – it’s largest weakness lays in the fact that it is an albeit uncommon dictionary word with common substitutions. Intentionally misspelling it would lead to a good trump on this, or simply throwing a random upper case in the middle of the word; “Tr0ub4Dor&3” will stymie most pattern attacks much better than “Tr0ub4dor&3”. This simple change boosts the time-to-crack the password from XKCD’s 3 days to over 1.83 billion centuries. By this pattern and the same time-to-crack standard as XKCD, it would take 7000 years to crack an 8-character alphanumeric password. A random, nonsense pattern of 8 characters is more secure than four random words.)
Now, four common words salted with random characters/symbols/numbers? That’s significantly more secure. Even just ending your password with a unique (memorable) pattern can greatly increase your password’s security. As the always-excellent Steve Gibson suggests, a good, secure password should contain all of upper case, lower case, numerals and symbols, simply to increase the search space – but that only helps after you have created a password immune to pattern attacks, such that brute force becomes the only way to guess.
One thing O’Brien mentions in his blog post is the “blacklist” of cracked passwords they have used. This prevents any Guild Wars 2 account from having a password that exists on their “known hacked” list. In abstract, this is a sound idea, albeit annoying for users. At its most basic, this idea doesn’t really endanger users – the passwords are already known to crackers, so the list does them no good. The great danger comes with the idea of extending this blacklist to all current existing passwords, cracked or not (and by ArenaNet’s own reporting, 98.5% of all user accounts are completely safe and unthreatened at the moment.)
Every existing, uncracked password added to this list will increase the knowledge base of known cracked passwords (and their hashes, assuming ArenaNet is at least responsible enough to store the password list encrypted – heaven help us if they’re storing them plaintext!) While ArenaNet is unlikely to use this list maliciously, the list will eventually be leaked out. Crackers will get their hands on this list, which, as a list without account information, will lead to ever more “known” passwords to fill the ever-expanding lists these malicious individuals use to crack accounts. Adding the 98.5% perfectly safe existing passwords to this list borders on criminal negligence.
If you are a current ArenaNet customer, you should under no circumstances change your password until they back away from this dangerous and destructive policy.
And always remember: keeping your account secure is your responsibility. Abrogating that duty and trusting the companies you deal with to shoulder the entire burden will always result in failure. The first line of defence in online security is the user, and a well-informed, savvy individual is the best weapon security professionals have against malicious attackers.
To ArenaNet, I say this: rethink your policy. Consider what danger you are posing to the 98.5% of your customers that are completely safe and secure at the moment and, if possible, delete your blacklist file, or, at worst, roll it back to nothing more than what you originally started with. Those looking to crack passwords don’t need your help, and you’re not doing anyone any good by trying to protect users who aren’t even in danger.
To anyone else running a secure server: salt. Salt. Salt. Salt your tables, and salt them now. Your information will be leaked. Protect yourselves and your users, and salt your tables. (For the lay person, what salting basically does is force attackers to crack each password individually for a user, rather than being able to run a check on every single password simultaneously.)
Krellen's Korner 
I’m confused. If we suppose that ArneaNet is storing only the salted hashes of the blacklisted passwords, what harm will a leak of that list do? I thought hashes weren’t reversible, so the hackers wouldn’t get any new passwords by getting that list.
Is hashing reversible in practice (maybe through offline brute-force)? Or is there something else I’m missing?
Because they are using this list to block ANYONE from using the passwords upon it, we know they are not stored with account information. A salt works by creating a unique hash with the user’s account and a random, non-repeating “salt” value, thus making a unique hash for that account/password pair.
The way crackers use stolen account tables is by generating hashes using the same methodology as the list, then comparing their result to the list – when they get a match, they have unlocked the password corresponding to a given hash value. Salting makes this a process that must be repeated for every individual user, as their account plus the salt will always be different. Without salt, this means that as soon as a password hash is revealed for one user, it is revealed for all users.
Because this list by design has to be divorced from user information, it cannot be easily salted – and every new password they unlock from the list would increase the knowledge base of known passwords, and the effectiveness of dictionary and hybrid patten attacks in unlocking future passwords.
Ok, thanks for clearing that up! I didn’t know that salting worked that way, now I can follow your reasoning.
If I were to implement Arena’s blacklist, I would use a long, random, individual salt for each blacklisted password, stored next to the hash. With a big enough salt and (ideally) multiple steps of hashing, that should protect against rainbow table attacks on the blacklist for quite some time (and such measures are always only meant to buy enough time so that the data is worthless when the hardware is fast enough to successfully hack it).
What I am more worried about is a potential password DoS attack – a botnet attacking ArenaNet’s login with a vast amount of bogus password which were not even leaked/hacked from anywhere, just to fill up the blacklist and reduce the remaining space for legit passwords.
It is one of those ideas that sound both good on paper and even in a sane implementation, but fail to neglect the ultimate consequences if thought to the very (usually bitter) end.
I actually had to go back and read the article closely twice before I realized just how bad this is….I mean, wow, that blacklist for existing passwords is a terrible idea. Why would anyone ever think storing everyone’s current password in an unsalted hash whether they’ve been compromised or not would be a good idea?
One thing I’ve wondered about–just how smart are dictionary attacks now? From what I’ve been reading, bots are using the already-hacked databased to blithely try user/pass pairs from already compromised accounts, but I would think using some data-mining algorithms on those millions of accounts and turning around with statistics models to attack a population of known user-names (which you can obtain in-game) would also be effective, at least enough to snag a percent of users. Is that just too involved?
To answer the question: probably not as smart as they could be, because users are, by-and-large, still not using very strong passwords. The return on investment for creating new algorithms to capitalise on newly-learned patterns isn’t great, since there still exists an extremely large portion of potential targets employing the simplest of password schemes.
Bascially, there’s still enough users using “password” as their password that it’s just not worth the time trying to crack the tougher ones.
But then…why are account names not better protected? I’m pretty sure you can see the account name for everyone that’s in your area, if not everyone on your server, while in the game.
You’d think the people who use the easily guess passwords would be eliminated Darwin-style, because it seems trivial to go through the relatively limited user base and hit everyone with a simple password dictionary, in the cases where usernames are publicly known.
Because, as I stated above, the goal isn’t SECURITY!, it’s a delicate balance between security and usability. In the games where account names are readily available (generally the “character@account” sort of games), obfuscating account names leads to another level of problems, usually in regards to intragame communication. Other games do hide account names, restricting communication to character name, but pay for that in the trade off of needing wholly unique names for every individual character (which can also be a problem, especially for really large games).
Most of the time people are protected the same way herd animals are protected – there’s so many targets, the chance of any particular individual being the one that gets hit is pretty slim, even if in any given attack there is ALWAYS a hit. They also have white hats on their side, the folks running security for the game, who implement policies and procedures to mitigate the damage of an attack – login attempt timers, for instance.
The truly outrageously stupid security decision that I’ve ran into is the 8 character maximum, only normal letters and numbers, maybe capital letters are recognised as different from small letters but that’s it. Which also means they’re likely to store the password in plain text.
Talking of character limits, it’s interesting that I’ve heard of people who consider 8 characters to be too long to remember, so they use the same one everywhere if the system forces that as the minimum.
Anyway, wouldn’t the random capital letter thing is also susceptible to patterns, as people are bound the prefer certain parts? (Not next to each other, likely a middle one.) Still better than nothing, of course.
I’m really glad you wrote this, although partly because I’ve felt frustrated every time you’ve said in the past that a 8 character password is better than a nonsense sentence. Which in turn has been because it’s the sort of claim that requires a proper explanation for me. Now I have that, so I can relax.
Well, not be quite as high strung.
Okay, so I’ll just find a new thing to feel frustrated/annoyed about and be just as irritable.
Regarding capitals:
A capital letter at the beginning of your password is a very common pattern, especially when many systems try to enforce password complexity by requiring all of the four sets (or more commonly, three of the four), and thus a capital at the beginning is of little use in stymieing pattern attacks.
But as long as it’s not at the beginning, pattern attacks become nearly impossible. While trends might appear, who knows where they’ll be placed? Some might capitalise the second letter, others the exact middle, still others the last or penultimate. Multisyllabic words offer several obvious places to capitalise, but will they capitalise the second syllable, or the third?
Every added bit on complexity to guessing at least doubles (and usually more than) the time required to crack a password. Even assuming attackers get their hands on an unsalted list, however, anything over a year is probably “good enough”. Devoting more time than that will be a losing proposition.
Still, I would recommend the random capital and an intentional misspelling. What you really want to do is force attackers to brute-force your password, because once you’ve got them doing that, you’ve pretty much won.
I’m assuming you expect the misspelling mid-word rather than at the end or front?
Or should they be as varied as possible to avoid a pattern? And is there a diminishing return point for misspelling the word?
A lack of a discernible pattern across a broad base of users is the goal. What you’re looking to do is to thwart dictionary-based attacks, while keeping a password you yourself can easily remember.
The more variance you can remember, the better, but too much variance may put you in a position of having to write down/store your password somewhere other than your head, which opens another security hole we’d like to prevent.
Given that you are, apparently, an honest-to-goodness security expert, a question:
I’m currently using a password system where I take a (fairly strong) base password and modulate it using elements of the service or website name. This produces some strong, service-independent passwords that are easy for me to reconstruct on the spot. However, my worry has always been that if someone got a hold of the plain-text version of one or two of them, the actual pattern isn’t that hard to sniff out.
Is this something I should be worried about?
Humans are very, very, very good at finding patterns (so much so that we often find them where the do not actually exist). If a human looked at it, they might be able to suss out the pattern.
I’m assuming that your “modulation” is more than just appending the service’s name to the end, though. The reason why passwords get cracked is not because humans are looking at lists and finding patterns (well, okay, it sort of is, but bear with me here), but because computers are using simple patterns programmed into them to very quickly cover as many pattern iterations as possible.
Attackers are rarely interested in one specific password – the real money is in cracking as many passwords and accounts as quickly as possible. Unless you’re someone Really Important, with access to lots of funds, no one’s going to put a lot of effort into finding out your individual password. You only need to worry if your pattern becomes commonplace enough to make it worth programming into the cracking software.
So in short, assuming your schema has a moderate level of complexity to it, you’re probably okay.
My schema has a moderate level of complexity to it, yes. Thanks.
I switched to this same “schema” method (I hope not the exact same schema!) about a year ago, but had the same concerns. Thanks for clarifying! It’s good to know that procedural methods work well for password generation, at least for the present.
Your comment about a random eight characters is actually pretty practical. I’ve found that memorizing a string of eight completely random characters (chosen from lowercase, uppercase, and numeric) isn’t as hard as it first seems, as long as you use it often. I use this method for my “work” computer password. The only danger is changing my password on Friday… and then forgetting it by the time Monday rolls around.
dudecon… that’s exactly the wrong thing to do.
The key here is “you use it often” ie in multiple places. That negates nearly all the security of making it random. If it’s cracked once, its cracked everywhere.
The danger here is if forum software gets hacked (common) and the whole list of passwords are stolen. Basically RockYou in small scale. For example if you use the same password just for all of your MMO forum accounts and just one of those forums has their passwords compromised then the _first_ place the hackers will try that password is the MMO. It doesn’t matter how random it is.
Your password is only as strong as it’s weakest link. And in this case it’s the security of the weakest place you have ever used it.
I suspect dudecon meant “used it often” in that he inputs it daily, not that he uses it multiple places.