Hash and Salt

Author: Cody J., Inflow Software Engineer

On the back-end, securing passwords on the server is more important than having a secure password. Storing passwords in plain text is simply stupid; there is nothing to stop someone from gaining access to the network with someone else’s account and, once in, it’s much easier to make new accounts, install backdoors, or just view the available data.

It’s easy to tell if a website is storing your password in plain text. When you make an account and either receive a notification from the website telling you what your login is, or, if you forget your password (why aren’t you using a password manager?), the site will send you your login information. If the site does either of these, then it’s storing your password in plain text.

The correct way to store passwords is to run user passwords through a hashing algorithm, preferably with a “salt”. A hash is essentially a one-way encryption: once a password is hashed (producing what is called a “digest”), there is no way to reverse the hash in order to recover the password.

Salting adds a random string of data to the password prior to being hashed; the caveat being that the salt needs to be different for each password. If it is the same, then once a single hashed password is cracked, it’s incredibly easy to figure out the salt and then use it to break the rest of the hashed passwords. Hashing and salting passwords is nearly an art in itself; to do it properly, you should look at more examples (such as this) than what I can go into here.

The way hackers can figure out passwords from a list of hashes is by running a variety of “attacks” on the hashes. Basically, a number of different criteria is used to generate a copious amount of random passwords. These passwords are passed through the hashing algorithm and the results are compared to the original hashes. If there’s a match, the hacker knows what the original password is.

To clarify, once a password is hashed, it can't be recovered directly. However, by running a variety of suspected passwords through a hashing algorithm, the resulting hashes are compared to the legitimate password hash. If the two hashes match, then the hacker knows what the password is (see “collisions” below for clarification). That’s why having a salt is so important; without it, it’s incredibly easy to find the original password.

As you might be able to guess, the type of hashing algorithm makes a difference, both in the security of the passwords and in the ease of cracking them. Some older algorithms, such as MD5 and SHA-1, are susceptible to "collisions", which occur when two different input values produce the same output hash. This collision can then be exploited when comparing hash values.

As mentioned, a collision occurs when two different input values produce the same hashed output. Because the input can be nearly anything and have an unlimited length, and the output is a fixed length string of characters, it is inevitable that collisions will occur in time. The time it takes a collision to occur is dependent upon the size of the output digest.

Why should you care about hash collisions? The idea of the birthday attack should help clarify why it is important. Essentially, the birthday problem considers a room of 30 students. The odds that any student was born on a particular day is about 8%. However, the odds that two students have the same birthday is closer to 70%. If the number of students is doubled, the final odds are nearly 100%.

Once one or more fraudulent hash digests are found, they can be substituted for the real one. Ergo, if someone is trying to use passwords to break into a system, they don't necessarily need the original password, just a password that creates the correct hash. The fake digest may or may not be the “true” password, but the system doesn't care; it only checks to see whether the password that is provided by the user matches the hash digest that is stored in the password database.

The speed in which an algorithm generates a hash is also important. Some algorithms are slower than others; when it comes to generating passwords, slower is actually better. When a user account is initially made, a slow algorithm won’t be noticed when compared to a faster one. However, when attempting to generate password hashes to compare against a company’s stolen hash database, slower algorithms can make a huge difference.

As discussed in collisions above, a hacker doesn't have to necessarily find the true password for an account, just a password that generates the correct hash. Thus, the longer it takes an algorithm to generate a hash digest, the more time it takes the hacker to find a possible substitute.

You can see this by going to https://asafaweb.com/HashSpeed . This site allows you to enter a password (don’t enter a real one) and see how many hashed values are generated in 100 milliseconds, depending on the algorithm used. In a test run, bcrypt generated less than 20 hashes compared to thousands for the others (nearly 40,000 for SHA512).

If you were a hacker attempting to crack a hashed password file, being able to generate only 200 passwords in one second vs. 400,000 obviously makes a huge difference in the amount of total time it will take to crack the password file.

Therefore, anything that can be done to slow down the password cracking process should be used: long and secure passwords, slow hashing algorithms, salting, encrypted files and hard drives, encrypted Internet connections, etc. While it is impossible to make a completely invulnerable system, you can make it so difficult that it’s easier for an attacker to look somewhere else.

 

At Inflow we solve complex terror and criminal issues for the United States Government and their partners, by providing high quality and innovative solutions at the right price through the cultivation of a corporate culture dedicated to being #1 in employee and customer engagement. We Make it Matter, by putting people first! If you are interested in working for Inflow or partnering with us on future projects, contact us here