Difference between revisions of "Dictionary attack"

From TheAlmightyGuru
Jump to: navigation, search
(Step 3: Steal a Password Table)
 
(17 intermediate revisions by the same user not shown)
Line 1: Line 1:
A '''''dictionary attack''''' is form of lookup attack used to crack passwords even when the passwords have been obscured with a hash function.
+
A '''dictionary attack''' is method of cracking passwords by exploiting the fact that humans tend to use easily-remembered words and phrases for passwords resulting in the same passwords being used across multiple users. To perform a dictionary attack, a password cracker assembles a list of commonly-used passwords, like common words, names, dates, and phrases and attempts each password. Dictionary attacks are usually employed before resorting to a [[brute force attack]] because they're much faster to perform. Dictionary attacks can even be employed to determine passwords obscured with a hash function.
 +
 
 +
While there are legitimate uses for a dictionary attack, like recovering forgotten passwords or verifying that passwords are secure, dictionary attacks are usually used for nefarious purposes, so understanding the process is necessary for protecting yourself against it.
 +
 
 +
I learned about dictionary attacks in a programming class in college.
  
 
==Process==
 
==Process==
===Step 1: Obtain a Password Table===
+
This section describes the steps necessary to perform a dictionary attack.
This is the most difficult part of the attack, as system administrators don't just give away user's passwords. Obtaining a password table usually means being able to defeat a system's security or buying one from an anonymous source. Also, since it is a security flaw for even admins to know what a user's password is, the passwords in the table are almost always obfuscated through a one-way hash function. So, when you look at a password table, it may look something like this:
+
 
 +
===Step 1: Obtain a List of Commonly Used Passwords===
 +
This is particularly easy since many crackers have already done the hard work and compiled [https://en.wikipedia.org/wiki/List_of_the_most_common_passwords lists of commonly used passwords]. Here is an example list:
  
 
{| class="wikitable" |
 
{| class="wikitable" |
! User !! Password
+
! Common Password
 
|-
 
|-
| smithr || <tt>5EBE2294ECD0E0F08EAB7690D2A6EE69</tt>
+
| 12345678
 
|-
 
|-
| jonesd || <tt>0CC175B9C0F1B6A831C399E269772661</tt>
+
| admin
 
|-
 
|-
| doej || <tt>92EB5FFEE6AE2FEC3AD71C777531578F</tt>
+
| god
 
|-
 
|-
| johnsonk || <tt>25D55AD283AA400AF464C76D713C07AD</tt>
+
| password
 
|-
 
|-
| williamsd || <tt>21232F297A57A5A743894A0E4A801FC3</tt>
+
| secret
 
|}
 
|}
  
In this case, the passwords have been run through an MD5 hash function which cannot be reversed. When a user logs in, the computer will first apply the hash to the password they typed in, and compare it with the one on file to ensure a match. This way, the plaintext password is only even known by the user. So then, how can a password cracker ever determine a user's password? This is where the dictionary attack comes into play.
+
===Step 2: Try Each Password===
 +
A basic computer program is created to attempt every password in the dictionary on the specified user account. Since most log-in gateways protect against multiple incorrect password attempts, a password cracker will usually have to steal a user table with the passwords.
  
===Step 2: Obtain a List of Commonly Used Password===
+
===Step 3: Steal a Password Table===
This is particularly easy since many crackers have already done the hard work and compiled [https://en.wikipedia.org/wiki/List_of_the_most_common_passwords lists of commonly used passwords]. Here is an example list:
+
This is the most difficult part of the attack, as system administrators don't just give away user's passwords. Obtaining a password table means being able to defeat a system's security or buying a password table from someone who already has. Since it is a security flaw for even admins to know a user's password, the passwords in the table are almost always obfuscated through a one-way hash function. So, when you look at a password table, it may look something like this:
  
 
{| class="wikitable" |
 
{| class="wikitable" |
! Common Password
+
! User !! Password
 
|-
 
|-
| 12345678
+
| smithr || <tt>5EBE2294ECD0E0F08EAB7690D2A6EE69</tt>
 
|-
 
|-
| admin
+
| jonesd || <tt>0CC175B9C0F1B6A831C399E269772661</tt>
 
|-
 
|-
| god
+
| doej || <tt>92EB5FFEE6AE2FEC3AD71C777531578F</tt>
 
|-
 
|-
| password
+
| johnsonk || <tt>25D55AD283AA400AF464C76D713C07AD</tt>
 
|-
 
|-
| secret
+
| williamsd || <tt>21232F297A57A5A743894A0E4A801FC3</tt>
 
|}
 
|}
  
===Step 3: Run the Same Hash On the List of Common Passwords===
+
In this example, the passwords have been run through an MD5 hash function which cannot be reversed. When a user logs in, the computer will first apply the same hash to the password they typed in, and compare it with the one on-file to ensure a match. This way, the plaintext password is only ever known by the user. So then, how can a password cracker ever determine a user's password without a [[brute force attack]]? This is where the dictionary attack comes into play.
 +
 
 +
===Step 4: Run the Same Hash On the Dictionary Passwords===
 
Hash functions used to obfuscate passwords cannot be reversed, but they can be repeated. To do this, a cracker must know the exact same hash function used to obfuscate the passwords in the stolen password table. This isn't too difficult, since only a few are commonly used. From here, the cracker runs all the commonly used passwords through the same hash function and gets a list of the hashes for each of the passwords.
 
Hash functions used to obfuscate passwords cannot be reversed, but they can be repeated. To do this, a cracker must know the exact same hash function used to obfuscate the passwords in the stolen password table. This isn't too difficult, since only a few are commonly used. From here, the cracker runs all the commonly used passwords through the same hash function and gets a list of the hashes for each of the passwords.
  
Line 57: Line 66:
 
I should point out that the MD5 hash function is not a cryptographically secure hash function and should never be used to store passwords. I'm just using it for this example.
 
I should point out that the MD5 hash function is not a cryptographically secure hash function and should never be used to store passwords. I'm just using it for this example.
  
===Step 4: Compare Against the Password Table===
+
===Step 5: Compare Against the Password Table===
 
Once the dictionary of hashes has been generated, the cracker need simply look for matches in the hashes between the stolen password table and their dictionary. A match indicates that the user chose the password in the table.
 
Once the dictionary of hashes has been generated, the cracker need simply look for matches in the hashes between the stolen password table and their dictionary. A match indicates that the user chose the password in the table.
  
Line 79: Line 88:
  
 
==Defenses==
 
==Defenses==
 +
This section details the ways to protect yourself from a dictionary attack.
 +
 +
===Eliminate Access===
 +
It should go without saying that a system administrator should eliminate access to the password table for all but the most trusted personnel. As a user, you should also be wary of supplying passwords to any system where administrators don't vigilantly protect the password table. This is also a general rule for all information, no matter what level of encryption is used, never allow people to have access to it. You never know if it will fall into the hands of a clever person.
 +
 +
===Use Unique Passwords===
 +
Only use unique passwords that won't show up in the cracker's dictionary. If you're not sure if your password is unique, open a browser (in secret mode) and do a Google search of your password in quotes. If there are any results, you should probably choose a more complicated password. Also, adding a number to the end of a common word will not make it safe, even if there isn't a Google hit. Multiple dictionaries can be created with permutations of existing passwords. For example, a cracker could make a copy of their dictionary and append the number 1 to the end of each password and run a dictionary attack on that as well and it wouldn't add much time to the process. Best practice is a number or symbol in the middle of a word that is unrelated to the word. For example, "passw0rd" where the letter o is a zero could be easily guessed, but it is unlikely a cracker would guess "pas6sword" where the number has nothing to do with the word.
 +
 +
===Use Uncommon Characters===
 +
Older systems rarely allow for this, but modern systems do. When you create a password, include a character that is not found on your keyboard. You can do this when typing in your password by holding down the ALT key on your keyboard then typing the character's number on your keypad (the numbers on the side of your keyboard, not the top), then release the ALT key. For example, ALT+175 gives you this character, "»". Few password dictionaries are going to include even a single password with that character in it, so your password will be safe from a dictionary attack.
 +
 
===Salt===
 
===Salt===
In order to combat dictionary attacks, most modern password tables first apply a salt to passwords before sending them through a hash function. A salt is a modification to a password so that it will yield a completely different hash. For example, the password below have been salted by adding a question mark to the beginning of them before being hashed, which gives an MD5 hash that is totally different from the hash without the question mark.
+
In order to combat dictionary attacks, most modern password tables first apply a salt to passwords before sending them through a hash function. A salt is a modification to a password so that it will yield a completely different hash from what is expected. For example, the passwords below have been salted by adding a question mark to the beginning of them before being hashed, which yields a completely different MD5 hash.
  
 
{| class="wikitable" |
 
{| class="wikitable" |
! Common Password !! MD5 Hash !! Salted Hash
+
! Common Password !! MD5 Hash !! Salted Password !! Salted Hash
 
|-
 
|-
| 12345678 || <tt>25D55AD283AA400AF464C76D713C07AD</tt> || <tt>9F7128DB15B794862C8E96A819379D94</tt>
+
| 12345678 || <tt>25D55AD283AA400AF464C76D713C07AD</tt> || ?12345678 || <tt>9F7128DB15B794862C8E96A819379D94</tt>
 
|-
 
|-
| admin || <tt>21232F297A57A5A743894A0E4A801FC3</tt> || <tt>C0D28ABB7D0C94329B81AA112518ADA0</tt>
+
| admin || <tt>21232F297A57A5A743894A0E4A801FC3</tt> || ?admin || <tt>C0D28ABB7D0C94329B81AA112518ADA0</tt>
 
|-
 
|-
| god || <tt>A4757D7419FF3B48E92E90596F0E7548</tt> || <tt>27DE47E3C4C4205ED02216C2A51AF071</tt>
+
| god || <tt>A4757D7419FF3B48E92E90596F0E7548</tt> || ?god || <tt>27DE47E3C4C4205ED02216C2A51AF071</tt>
 
|-
 
|-
| password || <tt>5F4DCC3B5AA765D61D8327DEB882CF99</tt> || <tt>1007980A168F839AA8C4689C7FBDDB0E</tt>
+
| password || <tt>5F4DCC3B5AA765D61D8327DEB882CF99</tt> || ?password || <tt>1007980A168F839AA8C4689C7FBDDB0E</tt>
 
|-
 
|-
| secret || <tt>5EBE2294ECD0E0F08EAB7690D2A6EE69</tt> || <tt>D3A4FE3D71CD8546AA9BEC89F0D686DF</tt>
+
| secret || <tt>5EBE2294ECD0E0F08EAB7690D2A6EE69</tt> || ?secret || <tt>D3A4FE3D71CD8546AA9BEC89F0D686DF</tt>
 
|}
 
|}
  
 
When using a salt, the program that handles user passwords must not only apply the salt when storing the password into the password table, but it must also apply the salt to the password each time a user logs in to make sure it will match the hash in the password table.
 
When using a salt, the program that handles user passwords must not only apply the salt when storing the password into the password table, but it must also apply the salt to the password each time a user logs in to make sure it will match the hash in the password table.
  
A salted password table adds a layer of security because, in order for a dictionary attack to work, the dictionary of hashes must be generated with the passwords and the salt. So, if the cracker doesn't know the salt, all of the password will fail to find a match. However, if a cracker defeated a system's security well enough to make a copy of the password table, they probably also made a copy of the program that adds the salt. So, a salt will not stop a cracker, because they will be able to determine how the salt was added and apply it to their password dictionary, but it will slow them down.
+
A salted password table adds a layer of security because, in order for a dictionary attack to work, the dictionary of hashes must be re-generated with the passwords ''and'' the salt. So, if the cracker doesn't know the salt, all of the passwords will fail to match the hash. Naturally, the particular salt being used should never be disclosed, but, if a cracker defeated a system's security well enough to make a copy of the password table, they probably also made a copy of the program that adds the salt and can determine it from that.
 +
 
 +
Even if the cracker doesn't know the salt, by using a [[brute force attack]] on a salted password hash, a cracker can usually determine what the salt is based on the results. For example, if the cracker brute forced two of the passwords from the table and found that they both began with a question mark, they could probably guess that the question mark is the salt. Because of this, a salt as basic as adding some text to the beginning or end of a password is discouraged and something more complex, like performing a logical XOR on every character, is preferred. Regardless, a salt will not stop a cracker, but it might slow them down long enough for the administrator to take counter-measures; like forcing everyone to change their password.
  
 
==Links==
 
==Links==

Latest revision as of 16:19, 11 October 2018

A dictionary attack is method of cracking passwords by exploiting the fact that humans tend to use easily-remembered words and phrases for passwords resulting in the same passwords being used across multiple users. To perform a dictionary attack, a password cracker assembles a list of commonly-used passwords, like common words, names, dates, and phrases and attempts each password. Dictionary attacks are usually employed before resorting to a brute force attack because they're much faster to perform. Dictionary attacks can even be employed to determine passwords obscured with a hash function.

While there are legitimate uses for a dictionary attack, like recovering forgotten passwords or verifying that passwords are secure, dictionary attacks are usually used for nefarious purposes, so understanding the process is necessary for protecting yourself against it.

I learned about dictionary attacks in a programming class in college.

Process

This section describes the steps necessary to perform a dictionary attack.

Step 1: Obtain a List of Commonly Used Passwords

This is particularly easy since many crackers have already done the hard work and compiled lists of commonly used passwords. Here is an example list:

Common Password
12345678
admin
god
password
secret

Step 2: Try Each Password

A basic computer program is created to attempt every password in the dictionary on the specified user account. Since most log-in gateways protect against multiple incorrect password attempts, a password cracker will usually have to steal a user table with the passwords.

Step 3: Steal a Password Table

This is the most difficult part of the attack, as system administrators don't just give away user's passwords. Obtaining a password table means being able to defeat a system's security or buying a password table from someone who already has. Since it is a security flaw for even admins to know a user's password, the passwords in the table are almost always obfuscated through a one-way hash function. So, when you look at a password table, it may look something like this:

User Password
smithr 5EBE2294ECD0E0F08EAB7690D2A6EE69
jonesd 0CC175B9C0F1B6A831C399E269772661
doej 92EB5FFEE6AE2FEC3AD71C777531578F
johnsonk 25D55AD283AA400AF464C76D713C07AD
williamsd 21232F297A57A5A743894A0E4A801FC3

In this example, the passwords have been run through an MD5 hash function which cannot be reversed. When a user logs in, the computer will first apply the same hash to the password they typed in, and compare it with the one on-file to ensure a match. This way, the plaintext password is only ever known by the user. So then, how can a password cracker ever determine a user's password without a brute force attack? This is where the dictionary attack comes into play.

Step 4: Run the Same Hash On the Dictionary Passwords

Hash functions used to obfuscate passwords cannot be reversed, but they can be repeated. To do this, a cracker must know the exact same hash function used to obfuscate the passwords in the stolen password table. This isn't too difficult, since only a few are commonly used. From here, the cracker runs all the commonly used passwords through the same hash function and gets a list of the hashes for each of the passwords.

Common Password MD5 Hash
12345678 25D55AD283AA400AF464C76D713C07AD
admin 21232F297A57A5A743894A0E4A801FC3
god A4757D7419FF3B48E92E90596F0E7548
password 5F4DCC3B5AA765D61D8327DEB882CF99
secret 5EBE2294ECD0E0F08EAB7690D2A6EE69

I should point out that the MD5 hash function is not a cryptographically secure hash function and should never be used to store passwords. I'm just using it for this example.

Step 5: Compare Against the Password Table

Once the dictionary of hashes has been generated, the cracker need simply look for matches in the hashes between the stolen password table and their dictionary. A match indicates that the user chose the password in the table.

User Password Match From Dictionary
smithr 5EBE2294ECD0E0F08EAB7690D2A6EE69 secret
jonesd 0CC175B9C0F1B6A831C399E269772661 -no match-
doej 92EB5FFEE6AE2FEC3AD71C777531578F -no match-
johnsonk 25D55AD283AA400AF464C76D713C07AD 12345678
williamsd 21232F297A57A5A743894A0E4A801FC3 admin

This method will identify every password in the stolen password table that matches one in the dictionary of commonly used passwords, which, in common practice, is often over half.

Since computers are very fast at generating hash functions and comparing values between two tables, a dictionary attack with millions of commonly used passwords can be carried out against a table of millions of user passwords in a matter of minutes.

Defenses

This section details the ways to protect yourself from a dictionary attack.

Eliminate Access

It should go without saying that a system administrator should eliminate access to the password table for all but the most trusted personnel. As a user, you should also be wary of supplying passwords to any system where administrators don't vigilantly protect the password table. This is also a general rule for all information, no matter what level of encryption is used, never allow people to have access to it. You never know if it will fall into the hands of a clever person.

Use Unique Passwords

Only use unique passwords that won't show up in the cracker's dictionary. If you're not sure if your password is unique, open a browser (in secret mode) and do a Google search of your password in quotes. If there are any results, you should probably choose a more complicated password. Also, adding a number to the end of a common word will not make it safe, even if there isn't a Google hit. Multiple dictionaries can be created with permutations of existing passwords. For example, a cracker could make a copy of their dictionary and append the number 1 to the end of each password and run a dictionary attack on that as well and it wouldn't add much time to the process. Best practice is a number or symbol in the middle of a word that is unrelated to the word. For example, "passw0rd" where the letter o is a zero could be easily guessed, but it is unlikely a cracker would guess "pas6sword" where the number has nothing to do with the word.

Use Uncommon Characters

Older systems rarely allow for this, but modern systems do. When you create a password, include a character that is not found on your keyboard. You can do this when typing in your password by holding down the ALT key on your keyboard then typing the character's number on your keypad (the numbers on the side of your keyboard, not the top), then release the ALT key. For example, ALT+175 gives you this character, "»". Few password dictionaries are going to include even a single password with that character in it, so your password will be safe from a dictionary attack.

Salt

In order to combat dictionary attacks, most modern password tables first apply a salt to passwords before sending them through a hash function. A salt is a modification to a password so that it will yield a completely different hash from what is expected. For example, the passwords below have been salted by adding a question mark to the beginning of them before being hashed, which yields a completely different MD5 hash.

Common Password MD5 Hash Salted Password Salted Hash
12345678 25D55AD283AA400AF464C76D713C07AD  ?12345678 9F7128DB15B794862C8E96A819379D94
admin 21232F297A57A5A743894A0E4A801FC3  ?admin C0D28ABB7D0C94329B81AA112518ADA0
god A4757D7419FF3B48E92E90596F0E7548  ?god 27DE47E3C4C4205ED02216C2A51AF071
password 5F4DCC3B5AA765D61D8327DEB882CF99  ?password 1007980A168F839AA8C4689C7FBDDB0E
secret 5EBE2294ECD0E0F08EAB7690D2A6EE69  ?secret D3A4FE3D71CD8546AA9BEC89F0D686DF

When using a salt, the program that handles user passwords must not only apply the salt when storing the password into the password table, but it must also apply the salt to the password each time a user logs in to make sure it will match the hash in the password table.

A salted password table adds a layer of security because, in order for a dictionary attack to work, the dictionary of hashes must be re-generated with the passwords and the salt. So, if the cracker doesn't know the salt, all of the passwords will fail to match the hash. Naturally, the particular salt being used should never be disclosed, but, if a cracker defeated a system's security well enough to make a copy of the password table, they probably also made a copy of the program that adds the salt and can determine it from that.

Even if the cracker doesn't know the salt, by using a brute force attack on a salted password hash, a cracker can usually determine what the salt is based on the results. For example, if the cracker brute forced two of the passwords from the table and found that they both began with a question mark, they could probably guess that the question mark is the salt. Because of this, a salt as basic as adding some text to the beginning or end of a password is discouraged and something more complex, like performing a logical XOR on every character, is preferred. Regardless, a salt will not stop a cracker, but it might slow them down long enough for the administrator to take counter-measures; like forcing everyone to change their password.

Links