“salt” makes a rainbow attack computationally unfeasible (reference). You take a plaintext password, give it some salt (usually a timestamp, so no one else will have the same salt as you), then take the password and the salt together and put them through your encryption method, and then put the encrypted pw in your database. Then to be able to use the password later, you have to store the salt along with the encrypted password (so that you can take the password the user gave you and mash it with the old salt and see if you get the same encrypted_password that is in your database). So I was confused… since the [encrypted] salt AND the encrypted password are in your available, if an attacker has access to your encrypted password (from your database), then ey also has access to the associated salt. So can’t the attacker take the salt, mash it in with their rainbow table, and then eventually (after a long ass time) potentially get a match with the encrypted string (to get the plaintext password)? I didn’t really understand salt for that reason.
Wikipedia says: A simple dictionary attack is still very possible, although much slower since it cannot be precomputed.
So that means that I was right about an attacker making a rainbow table with the salt, but it would take forever and ever and ever and a lot of space and would only work after you had your hands on the salt already. And every salt is different. Hence they say it is “computationally unfeasible” instead of saying it is “IMPOSSIBLE”. Cuz like if my salt sucked (or if my salt was great but we also had faster-than-light travel and human teleportation and all the space and computing power in Hermione’s magical purse) then ey could just pre-generate a bunch of tables of all the possible salts with all the possible plaintext passwords and stuff. Is this correct?
Here’s what I’m talking about, pulled directly from my rails tutorial book:
self.salt = make_salt if new_record?
self.encrypted_password = encrypt(password)
Hash it once, hash it twice, [something] makes the [something] taste nice. Isn’t there a children’s song that goes like that?
But I’m still confused. Let’s say I’m a hacker and I got this database. I make a rainbow table for all the possible salts and find the Time.now.utc that made the salt. Then I make another rainbow table where the entries are all of the format “[the salt I figured out]–[all possible strings for a plaintext password lol this would still take forever]” until I get one that matches the encrypted password. Right? I mean I understand that this makes it more secure than without salt, because you can’t precompute it, and it would take forever, but what if like the president was a member of this website and I wanted to hack into eir account, and I was willing to make multiple rainbow tables (and wait forever) to make it happen? Then I could get the password for that one account, right?!
So if all that is correct, then the reason we use salt is that… people would only make rainbow tables if there was the hope of getting a lot of users’ info (to make it worth it), because it’s just not worth it to to it for 1 person (which you would have to do if the passwords were salted) (but if you really REALLY REALLY wanted to for 1 person, you still could). Right? D:
Also pepper is better anyway.
(xposted at g+)