Passwords remain the most common method of user authentication. Yet, they’re not the most secure. One solution to certain security concerns with password authentication involves hashing, a form of one-way encryption that transforms one string of characters in a password into a completely different string using a mathematical hashing function.
To improve the safety of your hashing algorithm, you can also use security techniques such as salting, where you add a “salt value,” or a set of random characters, to the password before hashing it. Using techniques like salting exponentially increase the computational cost for attackers to decipher the hash if your system is ever breached.
In this article, we will discuss what salting is, how it improves the strength of a hash, and what the differences are between salting and peppering. Then, we’ll discuss some best practices for salting a hash and highlight how Stytch’s Passwords solution uses salting to enhance security and protect against hackers.
What is salting?
Salting is the process of modifying the password string that is to be hashed by adding a salt value to that initial string. A salt is a string of characters that could either be a legible word or, preferably, a set of random characters.
For example, you might have a password like Pa$$word, with a salt value of Df)0!2. Instead of storing the hashed password as-is, the system will add the salt somewhere to the string — usually before the password, though it can also be after.
The string that will be hashed will be the salt plus the password: Df)0!2Pa$$word, in this example. This new string will then get hashed and saved into the database. So, even if there were to be a data breach and the hashed passwords were to be leaked, the added salt would make even common passwords tough to crack.
The value of salting in addition to hashing passwords becomes clearer when you consider how attackers will attempt to crack hashed passwords that are exposed in a data breach. While storing passwords in plaintext is the worst password storage hygiene, rainbow table attacks make the sole act of hashing passwords inadequate when it comes to securing your users. “Rainbow table attacks” leverage pre-computed lists of password hashes to infer the plaintext value of a leaked hash value. By adding a salt to your password hashing process, you remove the ability for hackers to leverage these pre-computed lists.
Salting versus peppering
Salting and peppering, at the core, have the same goal. Both involve altering the initial string by adding a random value to it before being hashed. The key difference between them is where they are stored.
Peppering also describes the adding of a pepper (a random value) to a password during hashing, but unlike salting, the value isn’t kept with the password in the database — instead, it’s saved separately in a different location and form, like in the application code or a Hardware Security Module.
One peppering technique is to randomly select a pepper from a list of strings. The pepper used isn’t saved, so each login attempt means the application needs to try each pepper in the list until it finds a matching hash. This is very effective against attacks but places a huge load on the software doing the authentication as you will essentially create multiple log-in attempts while cycling through the list of peppers.
Another notable difference is that salting is usually unique per password, whereas peppering would use the same value, or one value of a list of peppers, for each password. The salt would be saved with the hashed password in the database, and the pepper would be in the codebase, in a secure key vault type of service.
Unfortunately, this causes peppering to be more hardware intensive than salting, and the computational cost exponentially increases the more users you have. It also causes the login process to be much slower than salting due to the calculation processes.
Salting best practices
When implementing salting as part of a password storage and hashing process, there are some best practices to follow:
- Use unique salts: Each unique salt will exponentially increase the computational load to crack the hashed passwords because cracking one password has no bearing on the rest of the passwords. Ideally, there is a unique salt per password, so when a user changes their password, that user-password combination would receive a new salt. This means you shouldn’t:
- Use usernames as the salt value
- Use actual words as salts
- Instead, you use randomly generated strings that draws from upper- and lower-case characters, symbols, and numbers.
- Use longer salts: The more characters a hash has, the more computational cost is involved in breaking the hash. Since each hash algorithm outputs a consistent hash length, it’s wise to have a salt of the same character length as what the hash would be.
- Add extra security to your hashes: Add a key to the hash, which should be kept off-site on a separate server. That way, if a hacker were to access a database containing the hashed passwords, they would need to gain access to this separate server as well to get the key.
You can also run the password through the hash algorithm multiple times.
Salting with Stytch
Instead of trying to implement salting yourself, you can turn to Stytch to ensure your salting technique is thorough, advanced, and secure. Our new Passwords solution implements all of the best practices outlined above, offering the most secure, properly salted hash available. We wanted to ensure this password solution used the most efficient and secure hashing algorithm, so we’ve used Scrypt to support our salting and hashing algorithm.
Stytch also provides breach detection, helping to prevent the use of credentials that have been compromised, and password strength detection, which makes sure that each link in the chain is as strong and secure as possible. This helps dramatically reduce account takeover risk.
Since new ways are constantly being developed to hack passwords, one solution is to move away from passwords entirely. Stytch offers passwordless authentication, meaning users can use things like biometrics, OAuth, Magic Links, SMS and WhatsApp Passcodes, and other passwordless forms of authentication that keep your users — and your systems — secure.
But if you’re not quite ready for passwordless, that’s okay! Stytch’s password solution is the most secure option available and will help keep your sensitive information safe.
Protect your passwords with Stytch
Salting is a necessity when storing passwords, as it protects yourself as well as your users. It provides that extra set of uniqueness to a password and, in turn, makes the password exponentially more secure — on top of the base level of security that password hashing offers.
Stytch uses best practices to ensure that the salts used are unique and that each password is properly hashed and secure. To see Stytch’s salting strengths in action for yourself, get started with Stytch today.
Share
