[Discuss] salt question
Eric Chadbourne
eric.chadbourne at gmail.com
Mon Oct 21 14:31:01 EDT 2013
Most excellent answers! I grok it now.
Thanks,
--
Eric Chadbourne
http://theMnemeProject.org/
------ Original Message ------
From: "Dr. Anthony Gabrielson" <agabrielson1 at comcast.net>
To: "Eric Chadbourne" <eric.chadbourne at gmail.com>
Sent: 10/21/2013 12:23:45 PM
Subject: Re: [Discuss] salt question
>
>On Oct 21, 2013, at 11:22 AM, Eric Chadbourne
><eric.chadbourne at gmail.com> wrote:
>
>> Hi,
>>
>> I have a basic question about salt.
>>
>> I was reading this:
>> http://www.openwall.com/articles/PHP-Users-Passwords
>>
>> And don't quite understand this line:
>> "Salts are normally stored along with the hashes. They are not
>>secret."
>>
>> So if they are not secret what is the advantage if your site is
>>exploited? Such as if the salt is stored in a config file couldn't the
>>attacker utilize this with his rainbow tables? Also I see in PHP
>>crypt() you don't have to supply a salt. How does that work? Is there
>>a distinct salt per hash, and if yes, where is this stored?
>>
>> I have a log in system I wrote myself with sha1 but from everything
>>I've been reading this seems inadequate.
>>
>> Thanks for any tips!
>>
>> --
>> Eric Chadbourne
>> http://theMnemeProject.org/
>
>Hi Eric,
> Think of salt as a multiplier which makes (pre-computed) rainbow table
>generation more complicated. When verifying a password, the equation is
>straightforward: crypt(salt, passwd_to_verify) == stored_passwd_hash.
>The original salt idea was to make it difficult for attackers because
>it should take a certain amount of time to compute a hash and the
>amount of space to store pre-computed rainbow tables for all salt
>values would be preventive. In reality storage space has dropped in
>price considerably and the rainbow table generation process is really
>easy to solve with a cluster; I know more than a few people
>continuously generating rainbow tables across all salt values. It is
>still better to use salt because there isn't a good alternative without
>going to Multi Factor Authentication.
>
>Anthony
More information about the Discuss
mailing list