Password Salting: A Savory Way to Secure Your Secrets
1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5.00 out of 5)
Loading...

Password Salting: A Savory Way to Secure Your Secrets

Password salt is a critical element of database security. Without password salting, any password hashes you store on your server are susceptible to dictionary & rainbow table attacks and risk compromise that can land your organization in some devastating headlines

When many people think about password security, there’s often a misconception that you should encrypt your secrets in order to keep them secure on your server. But when it comes to passwords, encryption isn’t the solution; there’s another cryptographic process that’s far better suited for the task. This involves salting passwords and then hashing them to store their hash values instead.

We’ve briefly talked before about the difference between encryption, hashing, and salting and the relationship of the latter two to password security. But we figure that it’s a topic that deserves a little more TLC and attention than it’s gotten in the past. So, here we are with a new article that will dive more in depth into salted password hashing.

But what is password salting and why is it so critical to secure password storage?

Let’s hash it out.

What Is Password Salting? A Password Salt Definition

Password salting is the process of adding a random, unique integer or string to every password to prior to hashing it. A salt is a random, large, unique value that’s generated using a cryptographically secure random number generator (RNG), or what’s sometimes called a random bit generator (RBG). Salts are traditionally stored on your server alongside your password hash values.  

Here’s an example of salts that were auto generated and added to a WordPress config.php file:

A screenshot example of WordPress salts
Image caption: No, you’re not having vision issues. We’ve blurred the main portion of the WordPress salted hash values that serve as an example of a salt string of data.

More technically speaking, the Internet Engineering Task Force (IETF) Network Working Group’s Request for Comments (RFC) 4949 defines a salt as:

“A data value used to vary the results of a computation in a security mechanism, so that an exposed computational result from one instance of applying the mechanism cannot be reused by an attacker in another instance.”

But what’s the point of using a password salt? Password salting allows you to create a unique hash value for every password. A hash is a method of taking an input of any size and converting into a random string of gibberish of the same length. This masks the size and any identifying information about the original input and can be used for data integrity verification. This helps to secure your stored password hashes against dictionary attacks (a type of brute force attack) and rainbow table attacks should cybercriminals get their grubby hands on your database. (We’ll speak more to the reasons why a little later in the article.)

Basically, the big takeaway here is that storing salted password hashes instead of plaintext passwords or unsalted password hashes is the difference between:

  • Enabling attackers to easily search your database for plaintext passwords or hash values that match common passwords, and
  • Making it too impractical and cumbersome to figure out individually.

(Don’t worry, we’ll speak more to hashing in a minute or two. And, no, hashing isn’t the same thing as encryption.)

The idea here is that you’re enabling every individual password input to have its unique hash value by salting your passwords before hashing them. This means that their hash values will be entirely different even if you have two separate users using identical passwords (say, password123).

Of course, you want to make sure that no one knows which salt you’ve used. This is why you need to add a unique, randomly generated salt to each password before hashing it. While it’s true that the salt gets stored next to your password hashes, it would be too time consuming and labor intensive to try to calculate each password using each individual salt. Taking that individual approach wouldn’t be worth it to cybercriminals who are trying to crack thousands or even millions of common passwords quickly using scripts and automation.  

An Example of How Salting Alters Your Password Hash Value

Ideally, users should be using unique passwords or passphrases to secure their accounts. But we know that not everyone follows password security best practices and will sometimes use common passwords. This is why it’s important to salt your passwords; it prevents a hacker from simply searching your database for password hashes that match the hashes of common passwords. 

Knowing this, let’s explore a quick example of how an MD5 salted hash value looks using the common password password123 as an example:

482c811da5d5b4bc6d497ffa98491e38

Now, let’s consider what happens when you apply the salt value +Oa8kFpYobjX to the same password. It results in the following entirely unique hash value:

e72fd887c202a4367b8a96d42d1a1e10

Without salting, two separate users would wind up having identical password hash digests. This would be bad news because it means that if a user’s password gets compromised in a data breach, hackers can use that known value to check against known hash values until they find a match.

But why would two users with identical passwords wind up with the same hash digest? This is because strong hashes are deterministic in nature. What this means is that any given input (i.e., your plaintext password) will always return the same hash value. So, a password like password123 will always return the same hash value when using the same hash function unless you do something to change the input, even just a little bit:

  • For example, if you changed a capitalization in the password password123 and made it PassWord123, it would generate an entirely different hash value (28d2464b121f120a41f4cd5c496cae2c).
  • If you take the same original password and just add a salt to it, as we explored in the example a few moments ago, it’ll create an entirely unique hash value.  

But salting isn’t the only way to add additional values to your passwords to increase their security. There’s also a related, lesser-known cryptographic process known as peppering.

Password Salting vs Peppering in Cryptography

A graphic that explains that salts and peppers are both values that can be added to plaintext passwords prior to hashing to increase the security of secrets.

Something that’s very common in cryptography — and cybersecurity in general — is that different terms are sometimes used interchangeably. This is the case with salt and pepper — while they’re related, they’re not the same thing and should be treated as separate elements.

Yes, a pepper is kind of like a salt in that it’s a value (a large integer or string) you tack onto passwords to add another layer of security. But, unlike a salt, a pepper is a secret value that can be reused. According to the Internet Engineering Task Force (IETF), a pepper is a value that can be reused over and over again.) Furthermore, because they’re intended to remain secret, peppers shouldn’t be stored along with the password hashes in your database.

The IETF also says that peppers should be able to be rotated and swapped out with alternate peppers:

“If a pepper is used, consideration should be taken to ensure that it can be easily rotated. For example, multiple peppers could be stored. New passwords and reset passwords would use the newest pepper and a hash of the pepper using a cryptographically secure hash function such as SHA256 could then be stored in the database next to the salt so that future logins can identify which pepper in the list was used.” 

IETF also warns that peppers and salts should not be combined because the salt isn’t a secret value; therefore, it may appear in the final hash value output.

 Password SaltPassword Pepper
Minimum Length16 bytes (128 bits)32 bytes (256 bits)
What It IsA randomly generated integer or string that’s combined with a password prior to hashing to create a unique hash valueA recyclable value that can be reused for multiple password hashes. This recyclable integer is kept secret so it’s reusable.
Storage MethodsSalts are stored alongside the passwords’ hash values in your databasePeppers are typically not stored with the passwords; however, it sometimes can be stored separately (typically though hard coding)
Where a Salt or Pepper Value Gets PlacedTypically added at the beginning or end of the plaintext password input  Typically added at the end of the plaintext input

So now that we know what salt and pepper are (aside from two tasty spices and the naming inspiration of a female 80s/90s hip-hop duo), it’s time to see where they fit in terms of cryptography — more specifically, within terms of hashing passwords and password security.

Hashing Serves as a One-Way Cryptographic Function

Hashing is a cryptographic function that converts a plaintext input into a fixed length string of random characters. This means you could take the content from every website on the internet, combine it all together, hash it, and the resulting string of hexadecimal characters would be the same length as an input that’s the sentence “G’day, mate!” Crazy, huh?

The purpose of hashing is to serve as a one-way method of verification. It allows you to confirm whether an input has been altered in any way since it was originally processed. It’s often used in combination with digital signatures, which are also cryptographic elements that, essentially, attach the digital identity of an organization or individual to the data in question. Using a digital signature offers assurances that the data is authentic because it came from the legitimate person or entity.

Hashing is a cryptographic process that is practically irreversible. What we mean by this is that it requires too many resources and too much time to try to use modern computers to take a hash digest and try to figure out its original input. This differs from encryption, which is intended to serve as a two-way function — meaning that the intention of encrypting data is for an authorized user (i.e., a private key holder) to be able to decrypt the data on the receiving end.

Hashing is used in a variety of functions, including:

  • Creating password hash values that can be stored in lieu of plaintext passwords
  • Ensuring the integrity of code, software, and other executables through code signing
  • Ensuring the integrity of email messages (via S/MIME certificates)
  • Protecting the integrity of data transmitted between users and web servers (via SSL/TLS connections)

Why Storing Only Salted Password Hashes Matters in Password Security

Storing salted hash values means that the original plaintext inputs are never uploaded to the server. This helps to protect them against dictionary and rainbow table attacks. It also makes them inaccessible to both your employees (who can’t inadvertently give access to your database that houses them by falling for phishing scams) and cybercriminals (who use various hacking or social engineering methods to gain access to the database).

Let’s compare three approaches to storing login credential-related information to see which method is the most secure:

  • Storing plaintext passwords. If you opt to save the plaintext passwords in a database on your server, then you run the risk of those passwords being compromised via SQL injections, XML injection attacks and other similar scenarios.  
  • Storing unsalted password hashes. This method involves only storing the hash values that are generated by applying a hash function to the passwords. This can result in multiple users sharing the same hash value because their inputs (i.e., their passwords) were identical. This method leaves their credentials vulnerable to rainbow table attacks and a type of brute force attack known as a dictionary attack. 
  • Storing salted password hashes. This method only involves storing the entirely unique hash values, which are practically irreversible because of the sheer processing power and time required. Furthermore, since adding a salt creates a unique hash value, rainbow table attacks are ineffective.

TL;DR? Here Are Your Password Salting Highlights

This article isn’t one of our usual tomes that dives super in-depth into a topic, but that doesn’t mean that you have 15 minutes to read the technical nitty-gritty of it, either. That’s why we’ve got your overview right here on password salting and your organization needs to do it:

  • Password salting is considered a password security best practice by the Internet Engineering Task Force. 
  • A salt itself is created entirely (or in part) via an approved random bit generator.
  • Salted password hashing is a way to securely store credential-related information in a way that doesn’t jeopardize the security of the passwords themselves.
  • Adding entirely unique salts to a list of passwords prior to hashing makes it so that even if two users have the same secret, each will have a unique hash value associated with their account. 
  • A “salt hash” (salted hash) is a way to protect your users’ login credentials against dictionary attacks and rainbow tables.

Well, that about wraps things up. We hope you’ve enjoyed this quick exploration of password salting and why using a salt hash is crucial to keeping users’ secrets secure on your server.

3 comments
  • Wonderful article. It is much appreciated. One thing I would now look for in a password management software, is it’s use of a salt. With the current pwmanagers, I presume we use the same salt value for each password we store therein?

    • This article isn’t about password managers but about storing (or not storing) passwords in an authentication database (e.g. for web services). Password managers have totally different requirements: Stored passwords must be encrypted reversibly. Otherwise you wouldn’t be able to decrypt your original passwords once they are stored in the password manager.

      So no, password managers don’t (and can’t) use salts. But they do use so called IVs, which are somewhat comparable to salts.

Leave a Reply

Your email address will not be published. We will only use your email address to respond to your comment and/or notify you of responses. Required fields are marked *

Captcha *

Author

Casey Crane

Casey Crane is a regular contributor to (and managing editor of) Hashed Out with 15+ years of experience in journalism and writing, including crime analysis and IT security. Casey also serves as the Content Manager at The SSL Store.