One of the things we could do to fix that and to direct that to make sure from our perspective, as the implementer and the defender, that we get it right is to do something called salting. Salting is the insertion of random data that's used as initial input to further enhance the likelihood or further enhance the data stream in such a way that we're increasing the likelihood that the data will stay secure because you don't just need to figure out what we did, you got to figure out what we used along with the random string in order to figure out how to actually make sure you can decrypt properly or that your hash message, your hash is going to represent integrity or whatever it is we're doing. So, the issue here is that the salt, the insertion of randomness, is going to further complicate the attackers job by making it harder for them to figure out what the actual values are we're using, to then be able to reverse engineer the system in some way, defends against primary dictionary attacks, because this is going to the dictionary attack. Is going to be a process that allows us to say, "Hey, I've got this prefab list of passwords. ABC one, two, three. ABC capital one, two, three. A, capital ABC one, two, three. AB capital, ABC one, two, three, et cetera." And we walk down the list, and we keep trying them getting in there to figure out whether or not we got the right password. The idea here is that if we can find the hash that represents the password, this is primarily what kind of attack we're using with the brute force attack. If we're doing password guessing, and we can find the hash that equals the password phrase, then we know the password. We don't have to reverse engineer it, all we have to do is say, "Well, I know the hash of the password for the administrator that I want is this, whatever this hash represents. ABC one, two, three, four, five, six, seven, eight, nine. If I could reproduce that hash, I know I've got the passphrase or the password, and now I can go and break in." So, what the attacker is doing is simply trying every possible combination, looking for that matching key, right? Every possible combination in the pool, inside the key space, until they find the right one, when they run the right password through the hashing algorithm, and get the hash out the back end. ABC one, two, three, four, five, six, seven, eight, nine, ding, ding, ding, we got a winner. We know that we've got the password. So, what salting is going to do in this case is make it complicated for them to figure that out because the dictionary attack is that pre-made list of words, that word is going to keep using for the past where we automate this process. We feed it in and the system just walks down the list one at a time till it finds the right match, and says, "Okay. Yeah, I got the hash, I know what it is. So now I know I got the password." If we solve the password, they've got to not just get the password, they've got to get the pass string with the salt inserted into it, in the right sequence, and the right way to actually then decipher it, ultimately match the hash, and then figure out what the password is by removing that. Because even if they get it to match, they know they got the string. They don't know what part is random in the salt and what part is actually the password. So, this becomes a lot more complicated and as a result of that salting, the passwords, when we hash them in the system, is a great defense mechanism against somebody using the hashes from the directory where we store the password hashes of the security system, to then reverse them and find the actual passwords because in effect, this is what a dictionary attack does. When somebody dumps the security hive, the sum database in Windows, and gets the hashes of the passwords. Because you don't really get the passwords, you get the user hashes of their passwords. That's what we use. When you log on in Windows, or log in in any LDAP directory exchange using a username and the password, we put that information on the screen. You sit here at the screen, at the log on prompt and you type in username whatever, password whatever. You don't send that information across the wire, we don't send the username and password, we hash the username and password, and when we do that, we send the hash, the cryptographic representation of the data with integrity across the wire. And what we do is not expose the username and password but rather, would simply send the hash strings. The hash strings are then taken and they're going to be compared at the directory database or in the directory function, the LDAP function, where they are stored. So when we send them to the domain controller or the LDAP directory server, it looks it up in a lookup table, it reads the information out of the Sam database, and the security hive in Windows, and it says, "Oh, okay. User Adam got a unique ID. We know what that user is. We look up the GUID and say, oh, this is user whatever, let me look that up in the table. Yep, user here, what's the hash for username? Does the string match? Yep. What's the hash for password? Right below it. Does the string match? Yep. Okay, authenticate that user, because that user is indeed legitimate. Or do the hashes match? Oh, no they don't. Well, don't authenticate. They put the password in the wrong way." So, we're going to be comparing hashes. We're not actually sending credentials. So as a result of that, we can use salting to further enhance the security of that, because we use a salt to store the hash, then we're using randomness to insert variables that the attacker is not going to know. And so, they're going to have to figure out how to strip that out in order to be able to make sure that we have the right stuff. So, this is important, this is a really important concept, helps us to defend against dictionary attacks. Now, what we have as a defender is the idea of salting. What we have as an attacker is knowledge of how this works and something that is on our side, notice a rainbow table. We have rainbow tables down there as another kind of an attack. A rainbow table attack is an attack that is basically a dictionary attack, but what it does is it allows us to use pre-compiled lists of every possible hash variable of passwords that we may want to use. So, we can download these tables, some of them are gigabytes in size. Somebody's run through, and computed the hash equivalents for passwords using every algorithm that they can think of and every possible permutation, and they put the stuff out on the internet. If you go out and you Google, you will find rainbow tables, and you can download them. And if you've never done this, it's actually pretty interesting to do. And you could see some are small, some are big, depends on what you're looking for. You can load these rainbow tables into cracking software and use them to automate the process of running through and finding the hashes. So, they'll use different salt functions, and different variable inputs along with passwords to pre-compute everything. And you can go out and find these and attackers use them, and it makes it easier for them because they have all the heavy lifting done. They don't have to generate all this stuff, it's already there. All they do is load it into an attack tool, target whatever they're looking to ultimately get the advantage on, and they'll just run this against the system until they figure it out. They leave it chugging away in the background, they go off and they do their stuff, and they come back a couple of days later and they check on the results and see what's happened. And again, if they have the hashes already dumped, they've gotten them out of the system. They are not running this live, they're running this offline in their own environment. They're gonna eventually spit out matches, they'll get a little output table that says "Oh, yeah, these hashes over here, these match these passwords." And then they'll take those passwords, and they'll start using them to log into the system that they've compromised. So by doing this offline, having the advantage, the attacker may actually be able to gain the information they need to compromise the system if they're willing to wait long enough. So, for every countermeasure we apply like salting, we may have an attack vector that can also counter that, something like rainbow tables. So, we need to make sure we understand again both sides of the divide here. It's very important for us to understand how this is going to work because if, as defenders, we have knowledge of how the attacks take place, we're a lot more likely to be able to defend successfully against them. As attackers, if we have knowledge of what the defenders are going to do, we may be able to scale our attacks, turn them, structure them in such a way that we may actually be successful. Both parties are kind of dancing around each other warily looking, trying to figure out who's going to do what, and where they're going to go. And if we anticipate correctly, we're probably going to be successful. And so, this is what the value of salting is.
