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