 The only thing worse than a security consultant who doesn't know anything is a security consultant who doesn't know anything who then goes on to write the security policy for an organisation. Not too long ago I came across a security policy where the policy stated that passwords in storage must be encrypted. Now half of you probably sitting there thinking, well, yeah, it sends stiff information, it should be encrypted. And the other half of you just want to take a gun to your head. The common person might just use the term encryption. That's not a problem. We're not talking about the common person here. But if you're writing a policy or if you're a journalist commenting on a technical issue, you should get your terminology correct. And I attempt to illustrate it by using my shoe. Now this represents a password. This is a password. Whoever has this shoe is allowed entry into this house. What does encryption do? Encryption can be defined by this box. You take the shoe, you put the said shoe into the box and you close the lid. That shoe is now encrypted. You know there's something in there or there might not be anything in there at all. It might be my shoe, it might be Gelsin's shoe, but there is something in here. Pretty safe. No one can see it. No one can guess it. But if I was an administrator of that system, I could simply open it up and I would have your entire password. You see, encryption is good. But it's only good where you want to retain the data. So you encrypt the data, you unencrypt the data, you see it again. Absolutely useless for passwords. Because passwords, we don't want anyone to know. We want the user to just input it once and then keep it in their head. The system should have no record of it. That's why in storage applications should hash the password using the weak collision prone MD5 or the new and improved SHA. Old and busted, shiny hotness. Now what SHA is, it's a type of encryption algorithm, mathematical type stuff that basically is a one way. So you can generate a hash from the password, but you can't convert it back into the password. Again, using my shoe and a piece of paper. I'll illustrate. You put it down like that. If you draw all the way around it, I've done it already, but here's one I prepared earlier, that is the outline. That outline is unique to the shoe. If I had a stiletto, not that I have any, but if I had one that would generate a different image. Now that is a hash. So that shoe will always generate that hash. But from that, you can't create a shoe like that. That's just a piece of paper with an outline on it. Badly drawn for all that. So password hash. So you create it once, you take the shoe away, the password away and you're left with your hash and this goes in your database. So no one then knows or they can't recreate what your password is. True. If I went to a shop which sold loads of shoes and I've got every single shoe out there and I created the template of all of them. I've got every shoe I could get my hands on and create that template. That is a rainbow table in effect. It's where I've taken all the different types of shoes, pre-created all the hashes. So all the passwords I've inputted, this many characters, this many numbers, generate all of the hashes. So what do we do? We add salt into it. What salt? Salt is, if we again use this, salt is a random piece of data that we generate. So it could be a big X that we put through it like that. Now what's that done is that if you got the exact same shoe and you didn't use the salt, that random bitness that you inputted into it, it wouldn't generate that same one. Now the key is you have to use a different salt for each user password held within your database. Sounds tricky but it's not. There are applications out there and if you're a developer I'm sure you can use whatever framework you use to figure it out. But that's the theory. So you have the hash which is individual and then you have a salt which is this bit of randomness. It could be an X, could be a circle, could be a triangle, but it's something unique to each one user and you saw that in the database too. Now sure someone could use a rainbow table, again you're saying, but what they have to do then is they have to calculate the salt independently and the hash independently because the salt is different for each user. If you use the same salt for everyone then that's just stupid. But if you use a different salt, a different hash, they'll have to calculate them all individually. They're not saying it can't be done, it still can be done, but it'll take them, you know, a lot longer to do. So encryption, hashing, salting. Three things, very different. We don't use encryption for passwords, we use a good hash with a random individual salt for each of them. Stay secure my friends.