In March, readers followed along as Nate Anderson, Ars deputy editor and a self-admitted newbie to password cracking, downloaded a list of more than 16,000 cryptographically hashed passcodes. Within a few hours, he deciphered almost half of them. The moral of the story: if a reporter with zero training in the ancient art of password cracking can achieve such results, imagine what more seasoned attackers can do.

Imagine no more. We asked three cracking experts to attack the same list Anderson targeted and recount the results in all their color and technical detail Iron Chef style. The results, to say the least, were eye opening because they show how quickly even long passwords with letters, numbers, and symbols can be discovered.

The list contained 16,449 passwords converted into hashes using the MD5 cryptographic hash function. Security-conscious websites never store passwords in plaintext. Instead, they work only with these so-called one-way hashes, which are incapable of being mathematically converted back into the letters, numbers, and symbols originally chosen by the user. In the event of a security breach that exposes the password data, an attacker still must painstakingly guess the plaintext for each hash—for instance, they must guess that "5f4dcc3b5aa765d61d8327deb882cf99" and "7c6a180b36896a0a8c02787eeafb0e4c" are the MD5 hashes for "password" and "password1" respectively. (For more details on password hashing, see the earlier Ars feature "Why passwords have never been weaker—and crackers have never been stronger.")

While Anderson's 47-percent success rate is impressive, it's miniscule when compared to what real crackers can do, as Anderson himself made clear. To prove the point, we gave them the same list and watched over their shoulders as they tore it to shreds. To put it mildly, they didn't disappoint. Even the least successful cracker of our trio—who used the least amount of hardware, devoted only one hour, used a tiny word list, and conducted an interview throughout the process—was able to decipher 62 percent of the passwords. Our top cracker snagged 90 percent of them.

The Ars password team included a developer of cracking software, a security consultant, and an anonymous cracker. The most thorough of the three cracks was carried out by Jeremi Gosney, a password expert with Stricture Consulting Group. Using a commodity computer with a single AMD Radeon 7970 graphics card, it took him 20 hours to crack 14,734 of the hashes, a 90-percent success rate. Jens Steube, the lead developer behind oclHashcat-plus, achieved impressive results as well. (oclHashcat-plus is the freely available password-cracking software both Anderson and all crackers in this article used.) Steube unscrambled 13,486 hashes (82 percent) in a little more than one hour, using a slightly more powerful machine that contained two AMD Radeon 6990 graphics cards. A third cracker who goes by the moniker radix deciphered 62 percent of the hashes using a computer with a single 7970 card—also in about one hour. And he probably would have cracked more had he not been peppered with questions throughout the exercise.

The list of "plains," as many crackers refer to deciphered hashes, contains the usual list of commonly used passcodes that are found in virtually every breach involving consumer websites. "123456," "1234567," and "password" are there, as is "letmein," "Destiny21," and "pizzapizza." Passwords of this ilk are hopelessly weak. Despite the additional tweaking, "p@$$word," "123456789j," "letmein1!," and "LETMEin3" are equally awful. But sprinkled among the overused and easily cracked passcodes in the leaked list are some that many readers might assume are relatively secure. ":LOL1313le" is in there, as are "Coneyisland9/," "momof3g8kids," "1368555av," "n3xtb1gth1ng," "qeadzcwrsfxv1331," "m27bufford," "J21.redskin," "Garrett1993*," and "Oscar+emmy2."

A screenshot showing a small sampling of cracked passwords.

As big as the word lists that all three crackers in this article wielded—close to 1 billion strong in the case of Gosney and Steube—none of them contained "Coneyisland9/," "momof3g8kids," or the more than 10,000 other plains that were revealed with just a few hours of effort. So how did they do it? The short answer boils down to two variables: the website's unfortunate and irresponsible use of MD5 and the use of non-randomized passwords by the account holders.

Life in the fast lane

"These are terrible passwords," radix, who declined to give his real name, told Ars just a few minutes into run one of his hour-long cracking session. "There's probably not a complexity requirement for them. The hashing alone being MD5 tells me that they really don't care about their passwords too much, so it's probably some pre-generated site."

Like SHA1, SHA3, and most other algorithms, MD5 was designed to convert plaintext into hashes, also known as "message digests," quickly and with a minimal amount of computation. That works in the favor of crackers. Armed with a single graphics processor, they can cycle through more than eight billion password combinations each second when attacking "fast" hashes. By contrast, algorithms specifically designed to protect passwords require significantly more time and computation. For instance, the SHA512crypt function included by default in Mac OS X and most Unix-based operating systems passes text through 5,000 hashing iterations. This hurdle would limit the same one-GPU cracking system to slightly less than 2,000 guesses per second. Examples of other similarly "slow" hashing algorithms include bcrypt, scrypt, and PBKDF2.

The other variable was the account holders' decision to use memorable words. The characteristics that made "momof3g8kids" and "Oscar+emmy2" easy to remember are precisely the things that allowed them to be cracked. Their basic components—"mom," "kids," "oscar," "emmy," and numbers—are a core part of even basic password-cracking lists. The increasing power of hardware and specialized software makes it trivial for crackers to combine these ingredients in literally billions of slightly different permutations. Unless the user takes great care, passwords that are easy to remember are sitting ducks in the hands of crackers.

What's more, like the other two crackers profiled in this article, radix didn't know where the password list was taken from, eliminating one of the key techniques crackers use when deciphering leaked hashes. "If I knew the site, I would go there and find out what the requirements are," he said. The information would have allowed radix to craft custom rule sets targeted at the specific hashes he was trying to crack.

"That means we have 13,000 humans who did not choose a good password."

how is Qbesancon321 not a "good" password? It could be strengthened by using a symbol, but sooner or later, Qbe$@ncon321 won't be a good password either. (For all I know, that's already the case).

seems like not reusing the same password is more important than strength. even if I have a password that I believe to be "strong", it's still in my best interests to change my password once its hash has been released.

"That means we have 13,000 humans who did not choose a good password."

how is Qbesancon321 not a "good" password? It could be strengthened by using a symbol, but sooner or later, Qbe$@ncon321 won't be a good password either. (For all I know, that's already the case).

seems like not reusing the same password is more important than strength. even if I have a password that I believe to be "strong", it's still in my best interests to change my password once its hash has been released.

Capital at the beginning, digits at the end, all lowercase in the middle. It's a poor password because it's using a common pattern. That was the point of the article.

"That means we have 13,000 humans who did not choose a good password."

how is Qbesancon321 not a "good" password? It could be strengthened by using a symbol, but sooner or later, Qbe$@ncon321 won't be a good password either. (For all I know, that's already the case).

seems like not reusing the same password is more important than strength. even if I have a password that I believe to be "strong", it's still in my best interests to change my password once its hash has been released.

The important thing is making it actually random. Besancon is a city, so it'll fall into a dictionary list. Testing the dictionary list matched with other common things (such as adding a letter on front and a bunch of numbers on the end) isn't that hard to do. As mentioned, when you can test billions of passwords, the key thing to do is just look at what people commonly do.

The article also goes through the same symbol replacement you used there, that's not really adding much complexity to your dictionary (they'll just run through the dictionary again and replace the characters with those commonly used 'tricks', 3 for e, 5 or $ for s). What you should do is add a symbol in there randomly to get the best out of it.

I've been using 1Password (https://agilebits.com/onepassword) for quite a while. Drag the slider up to 50 chars, call it a day. The only thing you'll need to watch out for is systems that can't handle that much password, I've dealt with ones that silently truncate it down to 35, ones that accept it, but hand off mangled versions to related systems, etc. etc.

I have tried to use XKDC's password technique. Many websites wrongly demand no spaces and must include a number. Some don't allow more than 10 or 12 characters. Guess they don't want people forgetting adequately secure passwords, eh?

Yes, there is no such thing as absolute security. That's not a revelation. But very good article none the less. If you really want to improve security to almost inpenetrable levels (with today's technology) you'll have to do what has always been recommended, completely random passwords of length determine by current and foreseeable technology and increase the characters as the technology advances. All websites would have to implement hashing of equivalent randomness. That would probably cost everybody more than they were willing to pay. So you can only do what's reasonable and eventually you will get hacked. Even the Pharos were "hacked".

"That means we have 13,000 humans who did not choose a good password."

how is Qbesancon321 not a "good" password? It could be strengthened by using a symbol, but sooner or later, Qbe$@ncon321 won't be a good password either. (For all I know, that's already the case).

seems like not reusing the same password is more important than strength. even if I have a password that I believe to be "strong", it's still in my best interests to change my password once its hash has been released.

The important thing is making it actually random. Besancon is a city, so it'll fall into a dictionary list. Testing the dictionary list matched with other common things (such as adding a letter on front and a bunch of numbers on the end) isn't that hard to do. As mentioned, when you can test billions of passwords, the key thing to do is just look at what people commonly do.

The article also goes through the same symbol replacement you used there, that's not really adding much complexity to your dictionary (they'll just run through the dictionary again and replace the characters with those commonly used 'tricks', 3 for e, 5 or $ for s). What you should do is add a symbol in there randomly to get the best out of it.

Two-factor authentication is the only real answer. Even if websites use bcrypt more. Otherwise the technology will catch up with any password complexity - FPGA, GPU or whatever else.

I see that the article recommended a minimum 11 character password. Yet some of the examples of the cracked passwords on page 3 are longer (13-17 characters). Granted they are not exactly random, but still greater than 11. So is there a good safe minimum number of characters that will make me mostly secure for next few years (or a couple of years or so). Assume I'm using 1Password or KeePass, and using alphanumeric, spaces, special. Will an 18, 20, 30 suffice?

Great series of articles by the way. Just a tremendous amount of knowledge.

Anyone else expecting their IT manager to make things even worse than they are now? Many of us appreciate the importance of security, but I can't help but feel that many IT managers make things even worse.

These articles are interesting but this particular test isn't very relevant. MD5 wasn't considered a secure way to hash passwords 10 years ago, let alone now. Why wasn't this done with bcrypt and salting? That's much more realistic. Giving them a list of passwords that is encypted in a way that would be considered massively incompetent in today's IT world isn't really a useful test.

Also, I think we may all be ignoring the most important point. That being that password complexity is quickly outpacing the human ability to remember them. We're going to have to move on to something else for our computer security because the average user struggles to remember 8 digit passwords. When we implemented minimum 8 characters, with one lower, one upper and one digit requirements I got hundreds of complaint emails. Maybe my users are more ignorant and stupid than most, but I don't think so.

It doesn't have to be impressive if it works. Even sites that have moved to anything better are indirectly harmed by sites with incompetent methods because the low-hanging fruit makes it easier for future attacks to become more effective: they enhance dictionaries, reveal patterns, and generally shrink the password phase space that is safe(r) for the rest of us.

That's kind of missing the point here - if it's something a human is likely to see a pattern in, then it's the sort of thing that's likely to be checked for. As hard as it can be to remember random gibberish (*do not only use lowercase letters and/or digits*) is really the only good option here.

MD5 is really insecure BUT you don't have control over what sites use.

Therefore:

Part 2:

Use a REALLY really complex password like homecoming-foxy-bear-cake-stick for a password store like lastpass.com or 1password.com and then use those tools to auto-generate passwords. Also using lastpass enable a two-factor auth such as google authenticate or at worst the excel sheet. The point is the ONE main password you need is secure. That password is not used anywhere else period. And every site should have a unique password generated for you. And one you never have to remember, and can change on a whim.

Unfortunately that is a bit complex, but so far there are no known better solutions.

That's kind of missing the point here - if it's something a human is likely to see a pattern in, then it's the sort of thing that's likely to be checked for. As hard as it can be to remember random gibberish is really the only good option here.

Well, it is almost a paradox then. There's most be a way to remove the human factor (without being human unfriendly)

One thing that people haven't mentioned is that the hash table is the major point of failure for password security. Once you get access to it, it is only a matter of time before your password is lost. In order to get real security improvements, you have to change the architecture so there's no single point of failure for all of a single website's userbase.

- As a DEVELOPER, either don't design the need to store passwords yourself (i.e. use openid or similar) or make sure you're following recommended guidelines for storing passwords (e.g. bcrypt / scrypt / PBKDF2) and make sure you periodically check up to see if you need to migrate strategies (i.e. MD5 was once acceptable, as was SHAx) - As a USER, use a password manager (e.g. KeePass) to make sure you can easily use large, truely random passwords that are unique for every login you have.

Moving to better web security technologies as well as decent security practices will help mitigate this sort of thing. Most of the web is still using SHA-1 aren't they? TLS 1.2 standard has been out for years and has better hashes and handshaking protocols etc that don't have all these weaknesses that people continually publish about now.

Also if you aren't using unique IVs with your password hashes in your system/database design, you are just asking for trouble.

Well, it is almost a paradox then. There's most be a way to remove the human factor.

To remove the human factor, use a password manager to generate a truly random, long password.

For a password that a human can remember that is still secure, use diceware.

What about generating a text file filled random characters (hundreds of thousands ) and then just remember the row, column and length? something like 450 23 12. I wouldn't bother to copy and paste (or is copy and paste already a security flaw?

Articles like this make me seriously consider using a password manager. However, I wonder if there are any risks to using a password manager. Maybe it's just a remnant of my initial visceral reaction when Microsoft first suggested this approach ("Just let Microsoft have all of your passwords!").

My questions are:

1) Do the password manager sites ever go down? And if they do, does this mean you are locked out of every single account you're managing?

2) What if the password manger site itself is hacked? Has this ever happened? What safeguards exist if the password manager database is stolen?

I see that the article recommended a minimum 11 character password. Yet some of the examples of the cracked passwords on page 3 are longer (13-17 characters). Granted they are not exactly random, but still greater than 11. So is there a good safe minimum number of characters that will make me mostly secure for next few years (or a couple of years or so). Assume I'm using 1Password or KeePass, and using alphanumeric, spaces, special. Will an 18, 20, 30 suffice?

Great series of articles by the way. Just a tremendous amount of knowledge.

Aalphanumeric, spaces, special of 30 chars would be considered physically impossible to brute-force, so your best bet would be to randomly generate values and hope one works.

Articles like this make me seriously consider using a password manager. However, I wonder if there are any risks to using a password manager. Maybe it's just a remnant of my initial visceral reaction when Microsoft first suggested this approach ("Just let Microsoft have all of your passwords!").

My questions are:

1) Do the password manager sites ever go down? And if they do, does this mean you are locked out of every single account you're managing?

2) What if the password manger site itself is hacked? Has this ever happened? What safeguards exist if the password manager database is stolen?

I use KeePass, KeePassX and KeePassDroid on Windows, MacOSX / Linux and Android respectively. The kdb file is stored on my dropbox, and is synced between every computer I use.

The only two passwords I remember is my Dropbox password and the password of my kdb file. Which are 19 and 26 characters long respectively.

So #1 is "it's local, it never goes down" and #2 is that because it's open source and local I know that all my passwords are secured under a large and difficult to brute force password. And it also sits behind my dropbox account (which you don't necessarily need to trust) which they'd theoretically need to crack as well.

If you're worried about trusting Dropbox there are several alternatives. You can sync the file manually via USB, you can use a more security focused cloud solution such as SpiderOak or, more laboriously (but more trustworthy) Tarsnap. You could also run your own "dropbox" equivalent on you own server, there are several open source implementations in various languages.

In the meantime, readers should take pains to make sure their passwords are a minimum of 11 characters, contain upper- and lower-case letters, numbers, and letters, and aren't part of a pattern.

And yet far too many websites prevent those of us who already do use password managers from using the best possible passwords. 8-12 character limits (gotta love those sites that don't tell you the max and truncate your input silently ), no special characters, etc. Love 'em.

How does a cracker know he correctly recovered the plaintext password from the hash? Does he run it back through the hash function and see if he gets the same result? Also how does he know which hash function he's dealing with anyway if all he has is a list of hashes?

The xkcd example is poor, the states level of entropy is "ideal" not "real". If I have a 100,000 word dictionary then each word represents about 10 bits of entropy, however people do not pick random words, they pick words they know and the average person uses about 1/5th of a dictionary.

If you had a dictionary with only 20000 words in it, would all the words you chose be in the dictionary? If the answer is yes then your entropy calculation is against the smaller dictionary.