Why Using a Password Salt and Hash Makes for Better Security
The Imperva Bad Bot Report 2021 revealed that 34% of all login attempts are malicious bots attempting account takeover attacks (ATOs). Password salting and hashing can help you secure your employees’ and customers’ passwords to keep them out of the hands of cybercriminals — here’s how
Verizon’s 2021 Data Breach Investigation Report states that credentials were the most sought-after data type in data breaches, comprising nearly 60% of compromised data. So, as a business owner, it’s vital that you take all possible steps to ensure that the passwords used by your employees and customers are secure. You can make the cybercriminals’ job more difficult by hashing and salting all passwords prior to saving credential-related info to your server. But what does using a password salt and hash combination have to do with password security? Let’s take a look.
Why You Need a Password Salt and Hash for Stronger Account Security
Storing your plaintext passwords in a database somewhere is one of the biggest mistakes your organization can make when it comes to password security. Storing passwords in plain text is like storing your company’s intellectual property in an unlocked file cabinet; anyone who knows where to look can find it without much effort.
So, what can you do to make them more secure? The National Institute of Standards and Technology (NIST) says you should secure your passwords (i.e., memorized secrets) is to salt and hash them (more on each of those terms momentarily). Why?
- Plaintext passwords are insecure secrets; if someone gains access to that database, it’ll spell disaster for your organization and users.
- Adding a salt to your passwords prior to hashing them makes them more resistant to brute force, dictionary attacks and rainbow table attacks. (More on that in a moment.)
- Trying to brute force salted password hashes it too cumbersome, resource-exhaustive, and costly for hackers.
As you’ll soon learn, when we talk about “password salt and hash,” we’re referring to the combination of the two methods — salting and hashing. Passwords are first salted to add a unique element to each password, then each password-salt combination gets converted into a character string of a fixed length (thanks to the use of the hashing function). The resulting value is a unique password hash, so it can’t be used in most credential-focused attacks. Let’s apply salt and hash to our example password:
But to really understand the importance of salting and hashing, let’s explore each of these concepts individually.
What Is Password Salting?
Password salting means adding a random value to a password prior to hashing to enhance its strength. What this does is ensure that password hashes for two separate users aren’t the same, even if they’re using the same passwords as the original inputs. Typically, salts are stored along with the password hashes in the password database.
Password salting is very much like seasoning your French fries. Fries are yummy on their own, but adding salt makes them even tastier. Likewise, adding a salt to your password enhances the security of this secret.
Salting makes it much more difficult for criminals to carry out the following attacks:
- Dictionary attacks—an attack where the criminals try all the words in their dictionary to attempt to crack a password.
- Database lookup attacks — where criminals send SQL query statements to the website database to trick it into coughing up valuable information.
- Brute force attacks—criminals use trial and error to try password-username combinations until they find the correct one for an account.
- Credential stuffing attacks— previously leaked or breached passwords are compiled in databases and used in subsequent attacks.
- Rainbow table attacks — these attacks rely on massive tables of passwords and hashes that can allow an attacker to look up password hashes quickly.
How Salting Makes Password Hashes More Secure
When you typically hash a password (without salt), it results in the creation of a hash value. But what happens when two people use the same password? If you apply a hash function to two identical passwords, you’ll wind up with two identical password hash values. This is bad news because if one of those users’ passwords becomes compromised, then an attacker can figure out their corresponding hash values and use them to create tables. To avoid this, you’ll add a salt.
When the password is salted, one or more random integers is added to the password. The characters used in the salt are unique for each password input — so, even if two users have the same password, once a salt is added, their resulting password hashes will be completely different.
Let’s look at an example of a salted password:
Let’s say your password is ‘h@ckPr00f.’ Once you add the salt to it, a unique password hash is created that is different from hashes for identical passwords. This means you wouldn’t recognize it after adding salt to it and neither would a criminal.
This is one part of the “password salt and hash” thing we mentioned earlier. Let’s explore the second part of that concept.
What Is Password Hashing?
The second part of password salt and hash is, of course, the hash. Hashing converts your plaintext password into a fixed-length, unique string of hexadecimal characters that’s totally different from the original text. Hashing is known as a one-way function because a hash value can’t be converted back to the original text; the process is essentially irreversible (because it would take way too much time and resources to conceivably do so). After hashing, the password hash is stored in the site database.
So, what does a hash look like?
These days, some hashing algorithms are available to automatically salt passwords so we don’t need to do it ourselves. Available tools include:
A Word About Peppering
If you want to go the extra mile to protect your stored passwords, then think about those French fries again. What can you do to make your fries more mouthwatering? Well, you could add pepper. Well, in cryptography, peppering is also a concept that applies to password hashing.
The Internet Engineering Task Force (IETF) describes peppering as “a secret added to a password hash like a salt. Unlike a salt, peppers are secret, not unique, and are not stored alongside the hashed password.” They should be stored in a separate location from the salts, such as in a hardware security module (HSM). Isolating the pepper helps to ensure that the bad guys can’t access the hashes, even if they use SQL injection techniques to exploit vulnerabilities in the database.
The IETF document also states that for the PBKDF2 key derivation function, the minimum pepper length should be 32 bytes.
Final Words on Why a Password Salt and Hash Make for Better Security
Password security doesn’t end with users simply creating and using strong passwords; as an admin, you have to protect their stored passwords. If cybercriminals get hold of your users’ stored passwords, they can use them to easily penetrate their accounts, networks, or cause a litany of other issues for your organization and users. This is why it’s crucial to only store salted password hashes.
The answer is to incorporate both a password salt and hash into your password security and storage processes and policies. Together, salting and hashing make it much more difficult for criminals to access your users’ passwords, making for better security.
2018 Top 100 Ecommerce Retailers Benchmark Studyin Web Security
5 Ridiculous (But Real) Reasons IoT Security is Criticalin IoT
Comodo CA is now Sectigo: FAQsin SectigoStore
8 Crucial Tips To Secure Your WordPress Websitein WordPress Security
What is Always on SSL (AOSSL) and Why Do All Websites Need It?in Encryption Web Security
How to Install SSL Certificates on WordPress: The Ultimate Migration Guidein Encryption Web Security WordPress Security
The 7 Biggest Data Breaches of All Timein Web Security
Hashing vs Encryption — The Big Players of the Cyber Security Worldin Encryption
How to Tell If a Website is Legit in 10 Easy Stepsin Web Security
What Is OWASP? What Are the OWASP Top 10 Vulnerabilities?in Web Security