"salt" makes a rainbow attack computationally unfeasible (reference: http://ruby.railstutorial.org/chapters/modeling-and-viewing-users-two#fn:7.8 ). 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 keep the encrypted pw in your database). Then later, to use the password, 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 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 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: http://ruby.railstutorial.org/chapters/modeling-and-viewing-users-two#sec:implementing_has_password

def encrypt_password
self.salt = make_salt if new_record?
self.encrypted_password = encrypt(password)
end

def encrypt(string)
secure_hash("#{salt}--#{string}")
end

def make_salt
secure_hash("#{Time.now.utc}--#{password}")
end

def secure_hash(string)
Digest::SHA2.hexdigest(string)
end

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 right?!

Edit 9:58pm: OHHH, the salt is an encryption of [the time AND the password]. Then you encrypt [the already-encrypted salt AND the password... again]. So actually you don't want to generate a rainbow table to figure out the salt, because to generate it, you would have to use every possible time AND every possible plaintext password (that's a lottttt more than just "every possible time"... you'd have to try every possible password with one possible time, and do that for every possible time)............ ?!?!?!!!!! And then you'd have to make another rainbow table of the [ [time and password] hashed with [password] ] to get the encrypted_password? Wait, wouldn't you have the plaintext password after getting the salt (theoretically, though I don't even know if it's possible with today's technology given a big enough salt/password), or is it possible (again theoretically) for a [some salt 1] hashed with a [some password 2] to give you the same string as [some other salt 3] hashed with [some other password 4] so you're not sure until you've made yet another rainbow table ... .... AUUGHHH SOMEBODY HELP ME
Shared publiclyView activity