In this post I will explain the process of password hashing and an explanation on how to further secure your password hashes using methods known as salting and peppering. Yes, I know, it sounds like I’m preparing a meal 🙂
The purpose of this post is to provide a basic overview of password hashing, salting and peppering.
What is password hashing?
Password hashing involves putting a password through a one way hashing algorithm which converts plain text into numbers and letters. In the event a site is hacked, the hackers will only be able to retrieve the hashes, as the passwords are never stored.
Why use hashing?
You may have read or heard that a number of organisations who have been compromised have stored customer passwords in plain text. For a hacker, gaining access to passwords in plain text is similar to locating a goldmine with little effort. You may be thinking if storing passwords in plain text is not secure, why do organisations do it? Unfortunately, in most cases the organisations don’t take security seriously or they may choose to compromise security because it is much more convenient for them. However, organisations taking such risks may suffer from a loss of revenue, downtime and loss in reputation resulting in a lack of customer confidence and trust.
How does hashing work?
When a password is hashed, the original password is never stored in the database and cannot be “easily” reversed to the original password.
Let me simplify the process further, hashing a password is like mixing an apple, banana, pear, strawberries and some grapes in a blender to prepare a juice. If we were to try and reverse the process so we could turn the juice back into solid fruits it would not be possible for us to do so. Hashing works in a similar way, as the method involves a one way algorithm.
You may be thinking,
1. How does the process work when a user registers for a new account on a website?
2. What happens when the user logs in? if the original password is not stored, how is the user logging in with a plain password?
Let me introduce a visitor named Andrew to explain further,
A visitor named Andrew signs up to a website, and as part of the registration process is prompted to enter a preferred username and password which will allow Andrew to login to the website in the future. Andrew uses an email address for his username and a password of password123 (Yes, not secure, don’t do it).
Upon signing up, the password Andrew decides to use is put through an hashing algorithm, a process Andrew does not see as this process runs on the backend system owned by the third party (Website owner). The password is transformed into a hash and stored in a database similar to the hash below.
Username: andrew@…… .com
Password (Hash): 5f4dcc3b5aa765d61d8327deb882cf99
Note: the plain text password password123 is never stored, however, Andrew will continue to use password123 when he logs into the website.
The password is stored as a hash, but you said Andrew continues to login with his plain password he set at registration? how does the logon process work if the plain password is not stored in the database?
When Andrew logs into the website he registered for earlier, he enters his plain text password. The password of password123 is put through an hashing algorithm which transforms the password to a hash. The hash is then compared to the hash previously stored in the database when Andrew registered for a new account. If both hashes match, Andrew is allowed to login to the website.
Andrew does not see the hashing method being processed in the background and this happens so quickly that Andrew does not realise that his password is being put through a hashing algorithm.
Are there issues with hashing?
There is no doubt that hashing is more secure compared to storing passwords in plain text, however, we do have an issue. A hash converted from a plain text password of password123 would be possible to crack by using a number of websites. Hackers make use of rainbow tables which store a large number of reversed hashes and can be used to crack password hashes, so it is possible to work out what the password is if the hackers continuously generate hashes from passwords until they find a match. Therefore, it is still important to educate users or enforce password policies disallowing the use of simple passwords. A hash of a password does make life difficult for hackers, as there is more work involved.
Furthermore and something to know, if other users in the database have used the same password (password123), the generated hash in the database would be the same. Therefore, figuring out the hash of password123 would allow the hacker to work out the password for other users who have used the same password at signup, resulting in less effort for the hacker to work out the hashes for accounts with the same password.
Below is an example of two users who used the same password. You already know Andrew. Let me introduce Jane who has registered on the website and used the same password. Notice below that the hash for both users is the same.
Username: andrew@…… .com
Password: password123
Hash: 5f4dcc3b5aa765d61d8327deb882cf99 (same hash)
Username: jane@…… .com
Password: password123
Hash: 5f4dcc3b5aa765d61d8327deb882cf99 (same hash)
Can we secure the hashes further?
Yes, using a method known as salt and pepper.
Let’s start with salt.
To strengthen and secure the hash further, a process known as salting adds an additional unique random number of characters/numbers to each users password prior to the hashing process.
For example,
Without salting and hashing
Username = andrew@…… .com
Password = password123
With salting:
password123 + a randomly generated salt, for example, 6(7$b39
In simple terms, the salt is an additional password appended to the existing password. Both the password + salt are the hashed together.
Result:
password123 with an extra password (SALT) added to the original password changes the password altogether, therefore the hash will be different for all users even though they set the same password at registration.
Where is the salt stored?
The salt is stored with the user’s hash in the database alongside the users hash, so if the database was compromised, the hash value may look like this,
Salt value followed by password hash (in the example below, 6(7$b39 is the salt)
6(7$b39.8g6c567e9g87978r784d57894cc6712c5
With salting applied, what if user’s use the same password such as password123?
Here is an example of accounts using the same password,
Username: andrew@…… .com
Password: password123 (plus randomly generated salt)
Hash: 6(7$b39.ce7453eca9d19086ffgbg9167g7e9b87 (different hash)
Username: jane@…… .com
Password: password123 (plus randomly generated salt)
Hash: h67b!)j9.5hsd64g57g5367cb7891gb6745ns7hd4 (different hash)
As you can see from the above example, Andrew and Jane have set the same password, however, the hash stored in the database is different for both.
Can rainbow tables still be used by hackers if they have obtained a hash which includes a salt?
When salting and recursive hashing are used, rainbow tables will become difficult/infeasible to use for hash cracking as it involves a lot more effort and compute power to try and work out a password with a salt. Adding salt can help mitigate password attacks, using rainbow tables, as the process will encrypt the user’s password with a random string that would not be included in any rainbow table.
I mentioned that the salt is stored with the users hash. Correct, and adding salt makes it difficult for the hacker as more effort and compute resources are involved, so it is still possible to figure out a password depending on how much effort and compute resources the hacker is willing to put in. We have another solution to make life more difficult for the hacker.
Let’s bring in the method of peppering to secure the process further.
What is peppering and how can this technique secure the hash and salt further?
Peppering is a cryptographic process that involves inserting an additional password including random characters to the users password and salt before the password + salt + pepper are hashed. The pepper (password) is not unique and nor is it randomly created for each user password before the password is hashed. The pepper (password) is created by an administrator/developer and therefore it is critical that the password used for peppering is very strong.
Is the pepper stored with the hash in the database?
No, this is the difference between salting and peppering. Unlike the salt, the pepper is not stored with the users hash in the database. The pepper should be stored in a secure vault or a HSM (Hardware Security Module) away from the database. If a database is compromised, the strong password used for peppering is not compromised and in turn makes life for the hackers more difficult. They have access to the hash, the salt but not the pepper.
I hope this post helped explain the process of hashing, salting and peppering. All feedback is welcome so please feel free to comment below.
