> So in other words, you'd test your passwords offline before choosing them.

Yeah, pretty much.

>>>> On the other hand, salting the password trivially defeats rainbow
>>>> tables.
>>>
>>> Sure, but how many password systems don't use a salt value?
>>
>> Well, that's true enough, sadly...
>>
>> (I still remember having a 25-post discussion with Tom Kyte about this.
>> He still fails to see why salt is useful.)
>
> Salt is useful only if the way in which it's selected is useful.  If the
> salt value is predictable or easily determined, then it's not so useful.

The purpose of salt is to defeat rainbow tables. Therefore, the only 
thing that matters is that the salt is an arbitrary random string which 
is unlikely to appear in a rainbow table. (E.g., raw binary instead of 
ASCII.) Doesn't matter how predictable it is, so long as it's not 
predictable enough to be in a rainbow table. (And it's different for 
every password in the database.)

This was Tom's argument. Since (in one prospective design) the database 
table stores, username, password and salt right next to each other, he 
argued that the salt provides to added security. But in fact it does: It 
means you can't reuse the work of cracking password #1 to crack password 
#2, #3, #4, etc. faster. You have to do it the long way around.

Post a reply to this message