[Discuss] salt question

[eric.chadbourne at gmail.com (Eric Chadbourne)]

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