On Fri, 12 Aug 2011 09:00:27 +0100, Invisible wrote:

>> 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.)

It can't be arbitrarily random, though, because the salt value is 
necessary to compute the hash.  Give it the wrong salt, and the value 
that comes back is wrong.

> 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.

Oh, true, if you use a salt value that progresses, but the sequence still 
has to be predictable (at least as I understand it).

Jim

Post a reply to this message