How I became a password cracker

Cracking passwords is officially a "script kiddie" activity now.

The walk of shame

Remember when I said that I was no expert at this stuff? Well, I'm about to prove it.

Each of the wordlist files I had downloaded were ".bz2" files—that is, bzip2 compressed files. Now, I had recognized this, but I had not bothered to decompress the files before using them (especially in the case of Rock You; the file was quite large). This didn't appear to be a problem because the GUI version of Hashcat threw no errors when I loaded it up with these .bz2 wordlists. Everything appeared to operate normally, and I assumed that Hashcat simply contained an internal version of the open-source bzip2 decompressor and unpacked the wordlists before using them.

But the failure of my English-language wordlist in particular convinced me that something had gone wrong here, so I decompressed all the .bz2 wordlists and added them back into the program. Perhaps, I reasoned, my modest success so far as a password cracker was due only to rules or to brute force, both operating in the absence of an actual wordlist—which might explain why the early passwords I cracked followed patterns.

I re-ran a "straight" attack on my 17,000 hash file using each of my wordlists with no additional rules whatsoever.

The result: I cracked 4,976 hashes in one minute, most of them coming from the RockYou wordlist, which clearly lived up to its hype now that it was uncompressed and working. Even without rules, I had cracked far more complex passwords than before, things like "softball24" and "butterfly5."

So I added best64.rule back into the mix and let Hashcat rip. In only 16 minutes it had applied every rule to every word in every wordlist I had, smashing through 7,553 hashes. After my dumb misstep, I had finally solved the password-cracking puzzle. I stared in awe at the huge list of passwords and short amount of time need to crack them. This was getting fun.

Refining the technique

By this point I had puzzled out how Hashcat worked, so I dumped the GUI and switched back to the command-line version running on my much faster MacBook Air. My goal was to figure out how many hashes I could crack in, say, under 30 minutes, as well as which attacks were most efficient. I began again on my 17,000-hash file, this time having Hashcat remove each hash from the file once it was cracked. This way I knew exactly how many hashes each attack solved.

This set of attacks brought the number of uncracked MD5 hashes down from 17,000 to 8,790, but clearly the best "bang for the buck" came from running the RockYou list with the best64.rule iterations. In just 90 seconds, this attack would uncover 45 percent of the hashed passwords; additional attacks did little more, even those that took 16 minutes to run.

Cracking a significant number of the remaining passwords would take some much more serious effort. Applying the complex d3ad0ne.rule file to the massive RockYou dictionary, for instance, would require more than two hours of fan-spinning number-crunching. And brute force attacks using 6-character passwords only picked up a few additional results.

Why did I limit myself to six characters? In a word, time. To see just how quickly brute force attacks could spiral out of control, consider the following chart. It shows the initial time estimates Hashcat gave for running full alphanumeric + symbols attacks on my 8,790 remaining hashes as I increased the character count of the passwords.

Enlarge/ The amount of time needed to brute force passwords increases quickly when using my laptop's CPU.

Ars Technica

The lesson was clear: I could crack every last hash in the file—but I'd probably need the better part of a year to do it, assuming my machine didn't simply collapse under the strain.

But who needs to be a completist about cracking hashes? I was at least in a position now to crack thousands of passwords in mere minutes. I could get everything from common passwords (iloveyou1, iloveyou13, iloveyou19, iloveyou81) to odd passwords (hahapoop3) to long passwords (rangefinder12) to passwords incorporating mixed case characters, numbers, and symbols (Jordan2!). Had I been the one who "liberated" this particular set of hashes, I would have been well-placed to wreak havoc on thousands of accounts—more than enough for some real mischief.

Speedups and slowdowns

Enlarge/ A small selection of MD5 hashes, followed by the password that produced the hash.

Nate Anderson

While I quickly gained both a conceptual and practical grasp on password cracking, I remain firmly in the realm of the script kiddie. Cracking a set of hashes generated by a single pass through the MD5 algorithm is computationally modest, even on aging laptop CPUs. A variety of changes to either my own setup or the hashing technique could make this process faster still—or make it exponentially slower.

Faster

More powerful CPUs. My little experiment was conducted on commodity laptop hardware better suited to a writer than a number cruncher. That was by design, as I wanted to see just how feasible password cracking was without unusual amounts of power, but it's important to remember that any serious cracker will use a rig sporting more memory and a more powerful processor than the Core 2 Duo and Core i5 CPUs I used.

And there's no reason to limit oneself to the kind of hardware found in discrete computers, either. With the rise of cloud computing, an ambitious hacker could rent some potent processing power from Amazon and deploy Hashcat in numerous virtual machines, each running a different attack on the hash database being targeted.

Enter the GPU. My own experiment differed in a more dramatic way from the practices of most serious password crackers, since I relied wholly on the CPU. But the best password cracking programs today can perform calculations on a GPU as well, generally at far higher speeds than CPU-based cracking alone. (Hashcat has two variants designed solely for use on computers with an OpenCL or CUDA-compatible GPU.) Those who really want to blast through the hashes (and raise the ambient temperature of the room around them) rely on GPU-based cracking.

Better cracking techniques. My own experiment touched only on two simple attacks, "straight" wordlist attacks (sometimes using rules to generate additional words) and "brute force" attacks. But other attacks exist, including "combination" and "permutation" attacks. Attacks can even skip the processor-intensive step of generating new hashes for each item in a wordlist and simply use a massive precomputed table of hashes, often many gigabytes in size, to reduce password cracking to essentially a database lookup exercise mixed with some fancy math. (Hashcat does not support such "rainbow table" attacks; to understand more about how they work, see our primer.)

The attacks I used can also be run more efficiently. Markov chains, for instance, rely on some statistical number-crunching to determine the odds that a given character will appear after another character in a password, using probability to make brute force attacks much faster.

Slower

Better hashing algorithms. Those charged with securing passwords have many ways to fight back against this cunning onslaught, however. First up, they can use better algorithms. I chose to start with a set of unsalted MD5 hashes because the MD5 hash function was built for speed—which means that basic MD5 hashes are also easy to crack (and are generally not recommended for passwords any longer by security professionals). Plenty of other "speedy" algorithms offer better protection, including the far more secure bcrypt or scrypt. (The amount of time needed to crack hashes increases dramatically as the speed of the hashing algorithm slows.)

Hashcat will peg every processor core you give it.

Nate Anderson

More iterations. Another common way to slow down password crackers relies on running a hash through the hashing algorithms multiple times. This can slow down the cracking of even something like MD5, and it can be done as many times as desired. Running a password through SHA256, for instance, and then feeding the hashed output back through the algorithm another 500 times would certainly make wordlist and brute force attacks slower by requiring every attempted crack to follow the same time-consuming set of iterations.

Finally, more iterations alone won't stop table lookup attacks. Though the tables will take much longer to generate, once they're generated, attacks that use them will proceed at the same speed as with any other table lookup attack. Which brings us to...

Salting. Salting attempts to defeat table lookup attacks by adding several characters to the password before passing it through the hashing algorithm, and these characters don't have to remain secret.

Imagine, for instance a website that secures millions of passwords with a single iteration of SHA256. Imagine that 25 percent of them use the same weak password of "123456." Unfortunately for the hacker (and fortunately for the website and its users), each password will have to be cracked individually, even though 250,000 of them are the same. Because the website appended a unique, randomly generated "salt" such as "0hJ3l1" to each password, the resulting hash will contain a different value. In addition to preventing large numbers of passwords from being cracked all at once, salting also thwarts cracking techniques that rely on rainbow tables.

Because salt is often not hidden, but stored right with the hashed passwords, it may provide no defense against traditional wordlist attacks—which is why password security often depends on a combination of all of these techniques.

Password length. Finally, passwords can get longer. This can have a dramatic effect on password cracking times, as noted above, especially if the additional characters are random ("123" hardly counts).

As Robert David Graham puts it, "The thing that most people don't understand about passwords is that brute-force is an exponential problem. The amount of time it takes quickly grows out of all reasonableness.

"People have the misconception that massive increases in performance lead to massive differences in password cracking, but it doesn't really. Moving from my desktop processor to a GPU that's 20 times faster only slightly increases the length of password I'm able to brute-force. Even going to a 1,000 instance Amazon EC2 cluster with super-computer performance doesn't dramatically increase password lengths that I'm able to crack."

His post includes the following graph to show just how quickly additional characters can make brute-forcing impossible.

Turning the weapon on myself

The unsettling experience of cracking so many passwords so easily led me to one final question: how secure were my own key passwords? Opening Terminal in OS X, I created an MD5 hash of my computer account password, which I had not changed in many years:

echo -n "password_here" | md5

I pasted the resulting hash into a text file and ran it through Hashcat, using the RockYou dictionary and the best64.rule variations. It broke in under a second.

A quick investigation showed just how it had failed—my password was actually in the RockYou dictionary—but the news wasn't that bad. For one thing, my hash had not been leaked publicly, and retrieving it would require someone to break into my computer. Even that was more challenging than it used to be because OS X Lion, which I'm still running, moved password hashes into a protected directory only accessible to "root," but it kept the root account off by default (attempts to access the directory with "sudo" or "su" therefore fail unless root is actively switched on by the user). Beyond that, OS X hashes passwords using SHA512 and adds a salt to prevent simple table lookup attacks.

Still, "All hashes have been recovered" isn't the sort of thing one wants to see after running a password cracker on one's own password. While passwords can be made more complicated without getting longer—mixing case or adding symbols or resorting to pure randomness—adding random characters is the easiest way to protect a password. I added several more characters to my password, made sure the result wasn't in the RockYou dictionary, then ran it against the RockYou + best64.rule combo to make sure that it was safe from the most common permutations. It was.

I next checked my online banking passwords using the same system; none were easily cracked. I remain under no illusions that beating a RockYou wordlist/best64.rule attack means I am secure—but any password that protects financial information or other sensitive data should at least pass such a test.

After my day-long experiment, I remain unsettled. Password cracking is simply too easy, the tools too sophisticated, the CPUs and GPUs too powerful for me to believe that my own basic attempts at beefing up my passwords are a long-term solution. I've resisted password managers in the past over concerns about storing data in the cloud or about the hassle of syncing with other computers or about accessing passwords from a mobile device or because dropping $50 bucks never felt quite worth it—hacks only happen to other people, right?

But until other forms of authentication take root, the humble password will form a primary defense of our personal information. The time has come for me to find a better solution to generating, storing, and handling them. (Look for future features on the subject in the near future.)

Password cracking proved surprisingly addictive—it's the ultimate mathematical puzzle, a lock that can be picked with only a single precise key that you have to uncover from a pile of billions of similar keys. Finding the fastest way to sort this pile is the game, and it takes only hours to learn. But mastering it is the real challenge, and you don't need to be a dark-hearted black hat to fall for it. After all, what true puzzle lover would be content with cracking only half the hashes?

Promoted Comments

Real credit is due to Ars for raising awareness about the vulnerabilities of passwords to common crackers. More importantly, it's been done is a layman's language that's allowed me to forward it to my friends and family. Now my mom knows that the name of some obscure Greek god+123 is not a good password.

Now, if only Hotmail would allow passwords greater than 16-characters.

The best passwords are still those posited by XKCD (http://xkcd.com/936/) - four (two is next to worthless and three is not that good) random words strung together.

Actually, three or four random words with a numeral or special character inserted between each word are much better (will defeat -every- lowercase brute force attack). Even just capitalising the Nth letter of each of your words gives a dramatic improvement in security. "coRrectbaTteryhoRsestAple"

Longer is indeed always better, but the following are also good tips:* numeral or special character inserted somewhere in the middle of the password. (It's computationally easy to check prepends and postpends, but still difficult to check every possible position.)* ditto for capitalisation. The rules out there mean that "HorseStaple" is really no more secure than "horsestaple" (because it's the most likely thing someone does to a two-word passphrase, and thus only double the time to check), but "hoRsestAple" adds 5x6+2=33 permutations (if they have a rule to look for a single capitalized character in each word), which isn't great, but is still better than nothing.* Even better, replace every Nth character with something completely different. "h&rses&aple" / "hQrsesQaple" / "h5rses5aple" ... just be careful not to pick a substitution that turns a word into another word or accidentally emulates l33tsp34k.

All that aside, the MOST important thing is, if you reuse passwords, reuse them wisely.* Use unique passwords, as strong as you can stomach, for -every- account that involves access to your actual monetary resources (bank, paypal, amazon, etc)* Ditto for any email account with password reset access to the above. THIS IS IMPORTANT!* For sites where your online reputation or business would be harmed by a breakin, or where you would be seriously inconvenienced from a loss of access, use a unique password, but you don't need it to be as strong.* For generic forums and the like... try not to reuse if you can, and try to pick "good" passwords, but if the repercussions are low that it really isn't too important. These definitely lend themselves towards the "ease of use" end of the scale, as there's little for you to lose.

The best passwords are still those posited by XKCD (http://xkcd.com/936/) - four (two is next to worthless and three is not that good) random words strung together.

Dubious.

Quote:

Of course 16+ truly random characters is slightly harder to break, but it's also impossible to remember.

A 16 character truly random password is not "slightly harder to break"; it's "computationally infeasible to break, even with massive parallelism, even with a really fast hashing function, for years to come".

Your GPU may be able to do a billion hashes per second, and you may have a supercomputer with a thousand GPUs. Great. A trillion hashes per second. How much does that help you?

Not much.

There are 95 printable keyboard-friendly ASCII characters. Many systems these days will accept UTF-8, but we'll just stick with ASCII, as it's good enough. A 16 character random password taken from the 95 printable ASCII characters gives 44,012,666,865,176,569,775,543,212,890,625 combinations. That's 44 million * trillion * trillion. On average you'll only need to crack half that to crack any given password, so call it 22 million * trillion * trillion. At a trillion hashes a second, that's still going to take, on average, 22 million trillion seconds.

That's a lot of seconds. It's a hair under 700 billion years, or about 50 times the current age of the universe.

You might complain that the supercomputer is too small. But it doesn't really matter. Even with 100,000 GPUs (and that's a lot) you're looking at 7 billion years. Maybe your GPUs are better, and can do 4 billion hashes per second. Great; you're still looking at more than 1 billion years.

A billion years is a really long time.

Now let's look at your XKCD password. The idea here is that they're four common words strung together. Typical English speakers have a spoken vocabulary of 10-20,000 words, and a working knowledge of 35-50,000 words. Four words out of 35,000 gives a total of just 1,500,625,000,000,000,000 passwords. Our trillion hash per second supercomputer can crack that on average in 8.6 days, and can crack it exhaustively in 17 days. Perhaps you'll use some really obscure words (which is rather undermining the point, because you're less likely to remember really obscure words); four from 100,000 can be cracked exhaustively by our trillion hash supercomputer in 3 years. Perhaps you'll decide to span most written English, and pick four from a million words. That's stepped up the difficulty a lot--our supercomputer would now take almost 16,000 years, on average.

But it's a blink of an eye compared to the 700 billion years that it'd take for random selection of 16 ASCII printable characters to be brute forced.

After reading your article I searched for the "rock you" password list and used it against my own passwords. Some of the (computer generated "random") passwords I use were actually in the list. The only MD5 hash I was not able to crack was that of my google password. And this was running on a first generation Intel Atom processor.

I think I need to go change every password I use everywhere. I am struggling to come up with a way to generate passwords that: