Hack and / - Password Cracking with GPUs, Part III: Tune Your Attack
You've built the hardware, installed the software and cracked some passwords. Now find out how to fine-tune your attacks.
In the first two parts of this series, I explained what hardware to get and then described how to use the hashcat software suite to perform dictionary and brute-force attacks. If you have been following along, by this point, you should have had plenty of time to build your own password-cracking hardware and experiment with oclhashcat. As I mentioned in my last column, password cracking is a pretty dense subject. In this article, I finish the series by describing how to tune and refine your attacks further so they can be more effective.
Use More GPU Cycles
The first area where you can fine-tune your attacks is to put more or less
load on your GPU. The
-n option, when passed to oclhashcat, changes how
much of your GPU will be used for an attack. The documentation says that
this value is set to 80 by default; however, on my computer, it seemed like
the default was set closer to 40. When I first ran a brute-force attack,
the output told me I was using around 70–80% of my GPU. Once I added
to my oclhashcat command, I noticed I was using between 96–98% of my GPU and
had added an extra 40,000 comparisons per second:
/path/to/mp32.bin -1 ?d?l?u ?1?1?1?1?1?1 | \ /path/to/oclHashcat-plus32.bin -m 400 -n 80 \ -o recovered_hashes phpass-hashes
Experiment with passing different values to
-n, and see whether your
comparisons per second and the percentage of GPU used increases. Be careful
though; the higher the number, the more power your GPU is going to use (and
if it's not well-cooled, the hotter it will run). Also, if you plan to use
the system for other things while you crack passwords, you may notice a
greater impact on graphics performance.
Although it may seem like increasing the
-n setting is a no-brainer, it turns
out that a higher setting really only benefits brute-force
hashcat documentation recommends you try lower
-n values when attempting
dictionary attacks. Ultimately, the key is to experiment with both high and
low values and see what gives you the best results.
In Part II of this series, I described two types of attacks: a dictionary attack and a brute-force attack. With a dictionary attack, you provide the cracking software with a dictionary full of possible passwords to try, such as all of the words in the English dictionary. A brute-force attack iterates through all possible combinations for a password of a certain length. Because a dictionary attack generally has way fewer passwords to try, it is much faster than a brute-force attack. Although a brute-force attack takes a long time, it also ultimately will find the passwords you are looking for.
It turns out you aren't limited by either a fast, possibly ineffective, attack or a highly effective, but slow, attack. With mask attacks, you can combine the speed of dictionary attacks with some of the thoroughness of a brute-force attack. Mask attacks work by making some educated guesses about the characters that might be used in a password. With a mask attack, you perform a brute-force attack only with a far smaller list of combinations to try all based on a pattern.
Mask attacks make more sense once you see an example. Let's say that you are attempting to crack a password, and you know the password policy requires the user to select at least one uppercase letter and at least one number. As I mentioned in my previous article, you can calculate how many combinations are in a particular type of password by taking the number of characters in the character set, figuring out how long the password is going to be, then raising the first number to the power of the second. So, for instance, if you wanted to do a thorough brute-force attack against the above password policy, you would have 62 characters in your character set (A–Za–z0–9) and with an eight-character password, the number of combinations would be: 628 = 218 trillion combinations.
At 350,000 comparisons per second on my password-cracking hardware, it would take me approximately 7,200 days, or 19 years, to complete the attack.
The fact of the matter is, when you tell most users to create an eight-character password that has at least one uppercase character and at least one number, most users aren't going to generate a truly random password. Instead, they likely will make the first letter uppercase and then use lowercase characters until they get to the end of the password, where they either will add a single number to the end of the password or they will put a four-digit year at the end—usually the year they were born, the year they graduated high school or the current year. A mask attack against the same password policy would build a brute-force pattern where you would just try an uppercase letter as the first character, lowercase for the next three, then either lowercase or numbers for the final four characters. In that case, the number of combinations would be: (26) * (263) * (364) = ~ 767 billion combinations.
On my hardware, that would take a bit more than 600 hours, or 25 days. Although that's a long time to crack a password, it's still a lot better than 19 years and likely will be effective against a large number of weaker passwords.
To describe this pattern, I use the same custom pattern language with maskprocessor that I used in the previous column for regular brute-force attacks, only in this case, I combine a custom pattern that includes all lowercase characters and numbers with a regular set of character patterns. The final maskprocessor command would look like:
/path/to/mp32.bin -1 ?d?l ?u?l?l?l?1?1?1?1
As you can see, I defined a special mask of
(0–9a–z) and assigned it
to 1, then I created a password pattern where the first character was
(A–Z), the next three were
?l (a–z), and
the final four were
The complete command to attempt this mask attack against my phpass hashes
with my new custom GPU tuning would be:
/path/to/mp32.bin -1 ?d?l ?u?l?l?l?1?1?1?1 | \ /path/to/oclHashcat-plus32.bin -m 400 -n 80 \ -o recovered_hashes phpass-hashes
The final way to improve your attacks further is by applying rules to your dictionary attacks. A rule allows you to perform some sort of transformation against all the words in your dictionary. You might, for instance, not only try all your dictionary words, but also create a rule that adds a single digit to the end of the dictionary word. That will catch even more weak passwords and only increases the number of overall combinations by ten times.
Here's an even better example of how rules can help crack more tricky
passwords. With the new requirement that users must have numbers in their
password, a lot of users have resorted to "leet speak". For instance,
instead of using "password" they might use
"p455w0rd". The fact of the
matter is, they still are using a dictionary word—they are just applying a
basic transformation to it where a becomes 4, s becomes 5, o becomes 0, e
becomes 3 and so on. When you want to crack such a password, all you have
to do is add the
-r option to hashcat and point it to a file that contains
the rule you want to apply. Hashcat uses a custom language to define rules,
but it's not too tricky to figure out, and the installation directory for
oclhashcat has a rules directory that contains a number of rule files you
can use as a reference. It even already includes a rule for leet speak, so
if you wanted to perform a dictionary attack that took leet speak into
account, it would look something like this if you ran it from within the
/path/to/oclHashcat-plus32.bin -m 400 \ -r ./rules/leetspeak.rule \ -o recovered_hashes example400.hash example.dict
For more information about rules, check out the documentation on the Hashcat Wiki at http://hashcat.net/wiki/rule_based_attack.
You now should have everything you need to refine your (completely legitimate and white hat) password-cracking attacks. On the Hashcat Wiki, you will find even more examples of types of attacks and examples you can use to improve your odds of cracking a password hash.
Main Hashcat Site: http://hashcat.net
Hashcat Wiki: http://hashcat.net/wiki
Hashcat Rules Documentation: http://hashcat.net/wiki/rule_based_attack
Password photo via Shutterstock.com
Kyle Rankin is a systems architect; and the author of DevOps Troubleshooting, The Official Ubuntu Server Book, Knoppix Hacks, Knoppix Pocket Reference, Linux Multimedia Hacks, and Ubuntu Hacks.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- RSS Feeds
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
2 hours 56 min ago
- Reply to comment | Linux Journal
3 hours 28 min ago
- All the articles you talked
5 hours 52 min ago
- All the articles you talked
5 hours 55 min ago
- All the articles you talked
5 hours 56 min ago
10 hours 21 min ago
- Keeping track of IP address
12 hours 12 min ago
- Roll your own dynamic dns
17 hours 26 min ago
- Please correct the URL for Salt Stack's web site
20 hours 37 min ago
- Android is Linux -- why no better inter-operation
22 hours 52 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?