Most excellent answers! I grok it now.
Thanks,
--
Eric Chadbourne
http://theMnemeProject.org/
------ Original Message ------
From: "Dr. Anthony Gabrielson" <[email protected]>
To: "Eric Chadbourne" <[email protected]>
Sent: 10/21/2013 12:23:45 PM
Subject: Re: [Discuss] salt question
On Oct 21, 2013, at 11:22 AM, Eric Chadbourne
<[email protected]> 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
_______________________________________________
Discuss mailing list
[email protected]
http://lists.blu.org/mailman/listinfo/discuss
