Salt, Pepper, Key-Stretching

The scenario

In our scenario we have a database, and on that database we have a table with both usernames and passwords on there. So obviously this is bad: there's somebody out there that now has our usernames and passwords.

Thankfully, the way we stored our passwords was using a hashing algorithm. So the passwords got put into a hashing algorithm and then we store the hash values here instead of the actual clear text password. That's going to make it more difficult for any hacker to be able to hack these passwords.

So what are they going to do? They're going to run a program against this that's going to try all sorts of combinations, perhaps thousands or hundreds of thousands or millions of different combinations, to see if it will crack this. It'll try dictionary words, patterns, common substitutions. It will just try a bunch of different combinations of things, passwords that are out there, to see if it can figure out what the passwords are.

Rainbow tables

Not only are they going to use software to try to guess at the passwords associated with these different hashes, but they're also going to use a rainbow table. What we've done is we've used some sort of algorithm, perhaps it's SHA, to switch the password into a hash. Well, there are tables out there that already have this compiled for them, so a password has already been converted into a hash, and all they need to do is look up the hash to find out what the password is.

So for this instance we have G house right here, who is in this rainbow table, and so they can look up the password. This is going to be for anybody that has bad password management or bad ways of creating their passwords, and that's going to be the majority of people unless they've been trained well, or unless they've been forced to create good passwords. So this is going to be a problem, because the rainbow tables are going to be very effective on many of the users. The majority of users aren't going to have great passwords unless they've been properly trained or they're forced to create good passwords.

Salting

So what we can do as part of our system is something called salting. What salting is, is adding an additional value to the password before it gets hashed. Once it gets hashed, the value is going to look quite a bit different than if it was just the password alone, and that's what's going to get stored in the password database. Now when a user logs in, they're going to type in their password, it's going to add the salt value to that, put it through the algorithm, and then compare it against the password table to authenticate, or make sure that that person is who they are.

Rainbow tables do have their limits. They have to be pre-populated, so it goes through a lot of different combinations of passwords and then it figures out the hashes for those, and at some point in time longer passwords become unfeasible to really create a hashing table from, or a rainbow table from. So longer passwords are what gets rid of, or doesn't get rid of it entirely, but helps mitigate against rainbow table attacks. By adding the salting to this, we added so much length to it that it becomes a lot less likely that it's going to show up in these rainbow tables.

Salting does have some limitations though. Although it guards against these rainbow table attacks, these values need to be stored somewhere. The salt values need to be stored somewhere, and it's per user, so because it's per user it's probably going to be stored on the same table or same database that these usernames and passwords are stored on. So if somebody steals the database, they've now stolen the salt value with that. It still guards against the rainbow table in this scenario, but it doesn't guard against guessing, because they still can guess a lot of different passwords and just add the salt value that's inside of this database, and then be able to figure out what the hashed value is, or guess against the hash value. So it still doesn't guard against guessing.

Pepper

Pepper is a very similar concept. It creates a pepper value that, with the password, creates a very unique hash here. But the difference is that instead of storing this pepper value with the table or in the database, it stores it in another location. Perhaps it's some sort of hardware location, perhaps it's within the code. So it's stored in another location instead of with this information, so if this information is stolen, the pepper value is not compromised, and it becomes that much more difficult for an attacker to be able to figure out what these passwords are.

There are a couple of problems with pepper though. Number one is that to store this in a separate location for each one of your users could have a compute problem with it. It could slow down this whole process of authentication and be problematic, plus take up a lot of resources, so it could just be resource intensive. What we can do often to combat that is we just have one pepper and we store it inside the code or somewhere else. The problem with that though is that if that one pepper gets compromised, it makes it easier for a hacker to be able to hack these, because it's just a known value. It's one of the reasons why we'd want to do both a salt and a pepper. But it still doesn't guard against something like an internal threat who has access to both of those.

Key stretching

One thing we can add to all of this is called key stretching. If this was a stolen database and somebody was trying to figure out the password to this user right here, they could try a bunch of different values to see if they come up with the same hash value, and they're going to try a lot of different calculations to do that, a lot of different passwords to do that. But if, on every iteration, every time they try to guess at a password, we can stretch how long that takes to computationally figure out, that is going to create a barrier for the person trying to hack these databases, trying to figure out what these hashes are.

So what we do is we create this computational load on there that's high enough that somebody can't make a lot of guesses over and over and over again, but doesn't create such a big load on it that we have difficulty calculating it ourselves. So we need to make sure we keep that in mind as well.

There are multiple ways that we can stretch out the processing power of this, but one example is maybe that instead of just putting it through our hashing algorithm once, we put it through a hundred times, or maybe it's a thousand times, or it's a lot of times that we're going to put it through this whole process. So that whole process of taking the pepper or the salt and adding it to the password and then running it through our hashing algorithm takes a much longer computational time to be able to figure out what this hash is, therefore slowing down somebody's ability to test a lot of passwords against a lot of users all at the same time.

Pulling it together

We started out with the scenario of our database getting stolen that had usernames and passwords on it. We talked about how using salt with the password before it gets hashed can help mitigate or help guard against the use of rainbow tables. We also talked about how adding pepper will help guard against the brute force attacks of just guessing a bunch of different passwords, and how key stretching can help add additional levels of security to our database in case it ever got stolen.