On Sat, 2008-01-19 at 23:17 -0500, Nathan Nobbe wrote:
> thanks for the great responses guys.
> i guess what im really getting at though is, if crypt() will embed
> a salt in the value it returns automatically, is there any benefit to
> creating a salt to pass to the second argument and storing that
> as well?
> conceivably, passwords already have a salt using the
> default crypt() behavior, so the general benefit of salting should
> be supplied by said default behavior.
> my guess is that there would be *some* benefit to creating a user
> supplied salt. greater entropy or something, im not sure what...
> im just trying to rationalize creating a salt in userspace
> and storing that in the database as opposed to not. any takers
> for either case?
Andrés Robinet wrote up a good response about why having a salt is a
good idea-- it exacerbates the problem when attempting brute force
attack on encrypted data since you can't use a premade dictionary
lookup. And if you have a different salt for each password (or at least
a large number of possibilities) then the attacker must generate a
dictionary for each salt.
Now to answer about using the salt when PHP will happily provide you
with a random salt... There absolutely is a good reason to use a user
supplied salt. The following gives away the purpose:
"The encryption type is triggered by the salt argument.
At install time, PHP determines the capabilities of
the crypt function and will accept salts for other
encryption types."
So for instance, try producing crypt()'d strings using the numbers from
1 to 10. On my system I get the following:
$1$gcEomRxT$YibOA/5WcjlCC4hseZ6bk/
$1$dDsWYLJK$RPXPnBRCAVDebiHiPkKJK/
$1$XzT/Az1t$QlONw/QqZMjNANMcnZcp/.
$1$CSgiFjsQ$3isYQqh9lFj/ZvX0ocsnx0
$1$8HHAUR5/$YzxMhT7rMfM13M/yRf2ET.
$1$G/WgK8zD$k3VZ2PAOIi1kcWVsyvnF10
$1$4fh1himm$wRqRYotHmw2Ps/SIkqhBq/
$1$.sTqbfpQ$RXhPwgyNGtS93OQ6jrzYl0
$1$tUCw0Rze$vtJ4i2Ed1k4oyrvod9X0R.
$1$W14JfJsx$WbyTs2Nqh9eXIpNgKBsCT0
I don't know what crypt() system produces that, but it's not the default
version of crypt() that I remember from my MUD server programming. In
fact if I supply a user salt (let's say "zz") I get the following:
zzsF/.LubwLnI
zzF7BImpLw88c
zzwyg0kWM1qv.
zzg9FBoQ.0O/o
zzjyi10UWoOtY
zzs2WwvhylXdQ
zzk7FKWJk8XiU
zzyIn0BmVxHbU
zzteAzJnPG9JE
zz8WHA83j.CZI
And THAT does remind me of my MUD server programming :) So it would
seem, by supplying a user defined salt you can ensure compatibility with
legacy systems that used the older (and largely deprecated) crypt()
system. In fact, the description given by PHP worries me a little. It
says, "Some operating systems support more than one type of encryption.
In fact, sometimes the standard DES-based encryption is replaced by an
MD5-based encryption algorithm". This suggests that you can't rely on
crypt() producing the same output on two different systems if you don't
supply a salt :| So in closing, I'd just go ahead and use SHA1 or
something else that is clearly defined :)
Cheers,
Rob.
--
...........................................................
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...........................................................
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
