Cryptography

Published on May 30th, 2016 📆 | 2038 Views ⚑

0

The LinkedIn Hack: Understanding Why It Was So Easy to Crack the Passwords

https://www.ispeech.org/text.to.speech
LinkedIn was breached in 2012 with a reported 6.5 million user accounts compromised. LinkedIn sent a request to known hacked users advising them to change their passwords. However, on May 16, 2016, 117 million LinkedIn accounts--reportedly from the 2012 hack--were found to be up for sale on a hacker site. LinkedIn stated that after the initial 2012 breach, they added enhanced protection, most likely adding the “salt” functionality to their passwords. However, if you have not changed your password since 2012, you do not have the added protection of a salted password hash. You may be asking yourself--what on earth are hashing and salting and how does this all work?

When creating a site that collects and stores user accounts, it is critical to ensure that passwords are properly protected. Because there are so many ways to crack passwords, including guessing (typically by using social media to figure out birthdays, pets’ names, favorite sports teams, etc.), dictionary attacks, and the use of rainbow tables (which we’ll go into later), it is more vital than ever to employ unique salted password hashing, which is in compliance with current cybersecurity industry standards.

First, let’s understand how this all works. When a user first creates an account, they enter a password in plain text, such as “1234”. The password “1234” is then hashed and stored in the system. Hashing is a mathematical algorithm that takes a plain text password and turns it into a set of letters and numbers. There are several methods of hashing.  One method is called Secure Hash Algorithm 1 (SHA1) (which is what LinkedIn had reportedly been using at the time of the 2012 hack) where a plain text password runs through a mathematical cryptographic algorithm that turns and stores the text password (“1234”) into a set of numbers and letters that look like this:

sha1:  7110eda4d09e062aa5e4a390b0a572ac0d2c0220

Therefore, the password should never be stored in the database as plain text, but rather as a stored hash. When a user logs into their account by entering their text password “1234,” the hash of the password is checked against the stored hash of the password. If the hashes match, the user is allowed access. If the hash does not match, the user will not be able to gain access. When using the SHA1 method, without adding the salt, the plain text password of “1234” will always create the same hash, meaning “1234” will always hash to the following SHA1 hash value:

7110eda4d09e062aa5e4a390b0a572ac0d2c0220

In theory, a hacker who has stolen user accounts that use the SHA1 mathematical algorithm with non-salted hashed passwords should not be able to use the hash to get the original text password. However, the bad news is that there are ways to reconstruct the text string from the hash. If a hacker has access to a database that has a SHA1 hash dictionary that has already been converted into the password plain text string it equals, they will have easy access to the password.

It would look something like this:

Figure 1

If the hacker cannot succeed in cracking passwords through brute force or by guessing the passwords, there are other methods that can be used, such as lookup tables and rainbow tables.

Lookup tables provide hashes that have already been computed and stored in a password dictionary with their corresponding plain text password string such as the ones listed in the table above.

Rainbow tables are lists of known hash values that equal a plain text password, somewhat like in the table above. Rainbow tables work in a similar manner to Lookup tables with a few minor differences—mainly that they sacrifice hash cracking speed to reduce the size of lookup tables. What is important to take away is that both lookup tables and rainbow tables have databases of plain text passwords and the exact hash string that matches each password.

The reason lookup tables and rainbow tables work is because each password has been hashed exactly the same way. This means that if SHA1 has been used and two people have the password “1234”, the password hash will be identical.

[adsense size='1']

If I go to a website such as https://sha1.gromweb.com/ which uses an SHA1 dictionary that has many pre-converted hashes, I can find the password I’m looking for:

Next, I will enter the hash from the password “1234”:

After clicking the reverse button, I come up with the hash string:

You can also choose to reverse the hash value to get the password text string as shown below:

It is really that simple. I was able to get the password by simply taking a millisecond to retrieve the password from a website. Kind of scary.

So what can we do? This is where salts comes in. This type of hack can be prevented by employing a unique salt which will make each plain text password converted to hash different. This way no two identical passwords will have the same hash. A salt is a unique string of bytes that is included with the password ineach hash calculation. If done properly, salts makes lookup tables and rainbow tables ineffective (at least at the present time). However, it is important to use salts correctly. It is crucial to use a unique salt every time a user and account/password is created and when a user changes their password. In other words, never use the same salt for each password and hash.

Here’s a great depiction of how the password “foobar” without a salt will always hash to the same hash string:

[adsense size='1']

Figure 1

Here’s the salting process and how the password “foobar” now has a unique hash string:

Figure 2

So if both users, John and Sean, have the same SHA1 plain text password string “1234”, we have established that without a unique salt, the hash will be the same. Remember, without a salt, the hash for the password “1234” will be hashed to identical hash strings:

John:7110eda4d09e062aa5e4a390b0a572ac0d2c0220

Sean:7110eda4d09e062aa5e4a390b0a572ac0d2c0220

However, by adding a unique salt each time, the hash will be different. This is a simplified example, but by going to a site like https://online-code-generator.com/sha1-hash-with-optional-salt.php which allows you create hashes with or without salts based on a plain text password, you can see that the hashes are different.

From this site, I chose to use the password “1234” and a salt string of characters before the string:

Notice how the hash is now different for the password “1234” than it was without the salt added:

However, remember to always use a different salt each time. In the next example, I again used the password string “1234” and the same salt string and once again put the salt before the string:

Notice the hash string is exactly the same as the prior example. This is because I used the same text string with the same salt in the same location:

Now, what if I use the same text password and choose to use a different salt string of characters? Will this make the hash string different and unique?  Let’s see below:

And the result:

If you guessed that it would be different, you were correct. Notice that the hash string is different even though the text password “1234” is the same. This is a vital point to understand. You must always use a different salt string of characters for each and every user plain text password string, just in case two users end up entering the same password string.

You now have a basic understanding of how hashing and salting work.  Please use these techniques to help keep your site and user passwords better protected.

Remember:

• Always use a strong mathematical hashing algorithm. Some research will help determine which one will work best for you.
• Always make sure your system is set up to use a unique salt string every time a user enters a text password or changes their password so that you can help thwart attacks such as lookup and rainbow tables.
• Make sure that you have a system set where your users must create complex passwords. (Inspired eLearning offers many courses that discuss password best practices. Please find more information by going tohttps://www.inspiredelearning.com
• Make sure that you follow current cybersecurity standards and require users to change their passwords on a regular basis.
• Have users use different passwords for all of their various accounts.

Source for Figures 1 and 2: https://weblogs.asp.net/jcogley/symmetric-salting-remember-that-salt-goes-with-more-than-just-hash