Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

So, as I understand it, you prepend a password with salt before you hash it so that the resulting hash can't be used with a rainbow table to find the original password, as you could if the password alone was hashed. But what's to stop someone from recomputing a new rainbow table with the salt prepended if the salt is known? I thought knowing the salt wasn't supposed to matter security-wise?

share|improve this question

3 Answers 3

up vote 9 down vote accepted

One word: cost.

It is much more costly to built the table than to directly try to break the password. Trying to brute-force the password requires only a trivial amount of memory; a rainbow table requires a huge storage space.

The only point of a table is that someone else has computed it and you can now use it. Many people using one table (or the same person using the table several time) pays up for the cost of building that table. If you are going a table once (for one password), there is just no point.

If every password in a given (really big) password database was using the same salt, that would be a different story. But would be a gross misuse of the salt: the point is that every password uses a different salt, so a rainbow table can never pay up.

Salting does not imply that you cannot try to break-force the password directly. Not only you can, but it is not more difficult when there is a salt. What you cannot do is reuse previous computing efforts (unless the system so broken as to not be able to generate a different salt each time).

share|improve this answer
    
So salting one particular password does not protect the password any better? –  John Jun 30 '12 at 2:38
    
@John In a world where there is exactly one hashed password with a given hashing function? No, it does not. –  curiousguy Jun 30 '12 at 4:05
1  
+1 "One word: cost." It is amazing how many people use one universal salt. I blame the books with titles like "Learn A in B minutes" –  Kurt Jun 30 '12 at 7:50
3  
Car factories are very efficient ways to make cars. But if you only need one car, you wouldn't go to the trouble of building a factory just to make it. Rainbow tables are like car factories. Expensive to build, but worth it because they can make attempts on many passwords. Salting makes rainbow tables useless. It's more work to make the table than just try to brute force the password. –  David Schwartz Jul 1 '12 at 12:30
1  
@John "is there a risk that the password could be hacked?" Do you store enough informations to check the user password? If not, you couldn't even verify the provided password. If so, with these informations, an attacker can check any number of passwords. For example, an attacker can try dictionary words, dictionary words plus one digit, etc. You could slow down that process, but you can't prevent it. May I ask why how the attacker would get the hash? –  curiousguy Jul 1 '12 at 19:23

Absolutely nothing: you can calculate a rainbow table for each salt just like you do for an unsalted hash. The rainbow table is a space/time trade-off, and the purpose of the salt is to make that more costly.

Every bit of salt you add doubles the storage requirements. So, one bit of salt means twice the storage space. 8 bits of salt, 2^8 or 256 times the storage requirement. 32 bits - 4 characters - of salt, 2^32, or 4,294,967,296 times the storage space to fully calculate the rainbow table.

share|improve this answer
    
Since the salt for a password is know, it is suggested to compute a rainbow table for just this particular salt value, not a generic table for every possible salt. Which is of course costly and pointless. –  curiousguy Jun 29 '12 at 23:35
1  
@curiousguy: There would be no point in computing such a table. You might as well just try to brute force that one password. What advantage does the table give you other than wasting a bunch of storage space? –  David Schwartz Jul 1 '12 at 12:32
    
@DavidSchwartz Establishing records? I thougth rainbow tables were about establishing new records in size. –  curiousguy Jul 1 '12 at 13:32

When you build a rainbow table, you compute the attacked hash function on many inputs. Any input value which you did hash during table building will be attacked successfully; and the table will not break any other. Due to some unavoidable quirks in the building process (that's a byproduct of the rainbowness of the table), you will hash some input values several times. Taken all together, a rainbow table which can break N possible passwords has a building cost of about 1.7*N, i.e. 70% more than simply hashing all these passwords in a basic brute force cracking.

So table building is worth the effort only if the table can be used at least twice, to (try to) crack two passwords or more. Salts prevent that. With salts, each table would be specific to a single hashed password (strictly speaking, to a single salt value).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.