Hash algorithms are one-way functions. They take any string and turn it into a fixed-length fingerprint that cannot be reversed. This means that if your data in your database is compromised, a hacker will not be able to obtain user passwords if they have been well hashed. 

Websites using hashing typically have a workflow like this:

1. The user creates an account.
2. Their password is hashed and stored in a database.
3. When a user attempts to log in, the hash of their entered password is compared with the hash stored in the database.
4. If the hashes match, the user can gain access to the account.
5. If not, a generic error message such as “Invalid credentials entered” is sent, so hackers can’t trace the error back to the username or password.

hash("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824  hash("hellu") = 3937f988aeb57b6fd75b9c71bf17b9658ec97823ba b613df438389b0c896b724  hash("danny") = 668e2b73ac556a2f051304702da290160b29bad3392ddcc72074fefbee80c55a

NOTE. Only secure or cryptographic hash functions (SHA256, SHA512, RipeMD, WHIRLPOOL, etc.) can be used to hash the password.

Unfortunately, simply cryptographic hashing of passwords does not provide security.

Hack hash

The easiest way to decrypt a hash is to just guess the password, hash the guess, and compare it to the hash of the actual password you’re trying to guess. 

The selection goes through all possible combinations of characters. While it is possible to eventually 100% crack any given password, this method is difficult to use due to its high computational cost. Some passwords, even those that are quite short in length, can take (literally) thousands of years to crack using brute force.

Trying aaa: failed
Trying aab : failed
Trying aac: failed
...
Trying acb: failed
Trying acc: success!

Dictionary attacks use a file containing commonly used words, phrases, or passwords that are likely to be the password in use. There are even databases with 100,000 (or something close) of the most commonly used passwords. The attack hashes these passwords and compares the hash with the crack password. This method is certainly faster than using a brute force attack.

Lookup tables can improve cracking performance by pre-calculating hashes so that when it comes time to guess a password, the program doesn’t have to spend time calculating by actually hashing the guesses.

In the next section, we’ll look at the “salting” that makes it impossible to 100% use these hacking methods.

Salting

The reason lookup tables, dictionary attacks, and brute force attacks can work is because passwords are hashed the same way every time. We can randomize the hash by adding a random string, called a salt, to the passwords BEFORE hashing.

hash("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
hash("hello" + "jHjdbJShdiodb") = 6f7f167a978166ee23b32c9531ce5dc23ae8fc26e412045858d938d11470831f

If the user’s password is qwerty, we will get the following hash: d8578edf8458ce06fbc5bb76a58c5ca4. If an attacker gains access to our database, to guess passwords, he can use ready-made services that already have values that give this hash, or he can guess them himself.

To protect against already prepared hash tables with values, you can use a static salt:

       $password = md5($password . "MyUniqueSault");

Now, with the same password qwerty , we will get a completely different hash bdadb0330124cda0e8499c9cd118f7bd. Ready-made tables will no longer help the attacker; he will have to use brute force. This is where the disadvantage of static salt lies: an attacker will be able to generate his own hash table with a static salt and obtain the values of most passwords from the database. To eliminate this disadvantage, a unique salt is used for each hash:

 $sault = GenerateRandomString();       $password = md5($password . $sault);

Those. Now, in addition to the login/password hash, the database will need to store the value of the generated salt for each user. Let’s look at an example: we have two users: user1 and user2. Both use the password qwerty. But the first one generated salt zxcv and the second one asdf. As a result, users with the same password will have different hashes: 1d8f3272b013387bbebcbedb4758586d and a192862aa3bf46dffb57b12bdcc4c199. What this gives: now it will not be possible to generate one hash table to find the value of hex the dynamic salt will have to be generated again.

What you should and shouldn’t salt

Not recommended:

• Reuse the same salt for each password hash
• Use short salts
• Use weird double hashes (eg: hash(hash(hash(‘mypass’)))) in salt

Recommended:

• Generating random salts using a cryptographically secure pseudo-random number generator (CSPRNG)
• Generate a new random unique salt for EACH password hash
• Generate LONG salts