Re: [PHP] password hashing and crypt()
On Sat, January 19, 2008 2:11 pm, Nathan Nobbe wrote: http://www.php.net/manual/en/function.crypt.php has a second parameter, $salt, which, if not supplied will be automatically generated and presumably become a prefix or suffix of the returned string. Or, in some algorithms, gets buried in the middle at a known offset. Go figure. now, the article on the phpsec website http://phpsec.org/articles/2005/password-hashing.html recommends to externally create a salt and to store that in a separate field in the database, which would then be used for subsequent password verification. You would not need to store it separately, as it is built-in to the crytped value anyway. theoretically, however, if the password is generated without a user supplied salt, there is a salt already embedded in the password anyway. True. so, i have the following questions 1. is the phpsec technique bloated or unnecessary A bit of bloat, but you have to have a million records or it to even start to matter, really... Disk space is cheap, and not going to be your bottleneck. 2. is it better to create a user supplied salt, and why or why not Do *NOT* let PHP pick the salt for you. Here is why. Suppose server/host A has Blowfish, Twofish, Redfish, etc, all installed. PHP will pick the best one, and choose the salt that makes sense for that algorithm. Now suppose server/host B does NOT have that algorithm installed, and you have moved to server/host B. Suddenly, PHP is picking a different algorithm, and your database has two different kinds of passwords in it, and all kinds of problems ensue. If YOU pick the appropriate salt length/format, PHP will know which algorithm you are using, and will error out if that algorithm is not installed, which means you can do something intelligent (like install the dang thing) rather than fill up your DB with incompatible password algorithms. This has happened to me, and it was a royal PITA. :-) 3. is crypt() 'intended' to be used w/o a user provided salt, since it is a stable algorithm I think the intent of making it optional was Good, but in Practice, it's just a Bad Idea (tm). -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] password hashing and crypt()
On Sat, January 19, 2008 8:24 pm, Eric Butera wrote:
I always make sure that I use a site specific salt which is just
appended on the user supplied value. I started doing that when I read
that people had created huge databases of hashed values that they can
just search on. At least this way no matter what the password isn't a
dictionary word. As for if that really adds value in the end I can't
say as I'm not really a security expert.
Eg. hash('sha256', $input.$salt);
The Bad Guys create humongous databases of every dictionary word with
every possible salt... So what salt you use does not matter...
So I don't think you are really adding any extra security here...
--
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] password hashing and crypt()
Richard Lynch wrote:
On Sat, January 19, 2008 8:24 pm, Eric Butera wrote:
I always make sure that I use a site specific salt which is just
appended on the user supplied value. I started doing that when I read
that people had created huge databases of hashed values that they can
just search on. At least this way no matter what the password isn't a
dictionary word. As for if that really adds value in the end I can't
say as I'm not really a security expert.
Eg. hash('sha256', $input.$salt);
The Bad Guys create humongous databases of every dictionary word with
every possible salt... So what salt you use does not matter...
Sure it does. I could use my server name or the application's url, the
current time, whatever I like and put all of that in the salt. There's
no way they'll have that in their dictionary.
As long as I store the salt I know how to compare it again later.
--
Postgresql php tutorials
http://www.designmagick.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] password hashing and crypt()
On Tue, January 22, 2008 7:43 pm, Chris wrote:
Richard Lynch wrote:
On Sat, January 19, 2008 8:24 pm, Eric Butera wrote:
I always make sure that I use a site specific salt which is just
appended on the user supplied value. I started doing that when I
read
that people had created huge databases of hashed values that they
can
just search on. At least this way no matter what the password
isn't a
dictionary word. As for if that really adds value in the end I
can't
say as I'm not really a security expert.
Eg. hash('sha256', $input.$salt);
The Bad Guys create humongous databases of every dictionary word
with
every possible salt... So what salt you use does not matter...
Sure it does. I could use my server name or the application's url, the
current time, whatever I like and put all of that in the salt. There's
no way they'll have that in their dictionary.
As long as I store the salt I know how to compare it again later.
For the algorithms used by crypt(), the salt is IN the crypted value.
If the Bad Guy has the crypted value, they already have the salt.
They can maybe make a dictionary that is MUCH larger with every
possible salt, and do a simple comparison.
Or they can quickly write up a crypt()-based script that extracts the
salt and tries the Top 10,000 passwords for each.
Most Un*x systems come with /usr/share/dict/web2, Webster's second
edition dictionary.
It has only 235,882 words in it.
How many possible salts are there?
DES only lets you have 2 chars, a-z, right?
235,882 X 26 X 26 is not exactly a HUGE database of possible values to
have on hand.
The 1$ and 2$ salts are longer, but I suspect still not THAT much longer.
The salt only increases the difficulty by a factor of X, but doesn't
make it geometrically harder to crack -- So a Bad Guy only has to have
X times as much resources, for a relatively small X.
--
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] password hashing and crypt()
Richard Lynch wrote:
On Tue, January 22, 2008 7:43 pm, Chris wrote:
Richard Lynch wrote:
On Sat, January 19, 2008 8:24 pm, Eric Butera wrote:
I always make sure that I use a site specific salt which is just
appended on the user supplied value. I started doing that when I
read
that people had created huge databases of hashed values that they
can
just search on. At least this way no matter what the password
isn't a
dictionary word. As for if that really adds value in the end I
can't
say as I'm not really a security expert.
Eg. hash('sha256', $input.$salt);
The Bad Guys create humongous databases of every dictionary word
with
every possible salt... So what salt you use does not matter...
Sure it does. I could use my server name or the application's url, the
current time, whatever I like and put all of that in the salt. There's
no way they'll have that in their dictionary.
As long as I store the salt I know how to compare it again later.
For the algorithms used by crypt(), the salt is IN the crypted value.
Yeh - I pointed that out here:
http://marc.info/?l=php-generalm=120095678525654w=2
But Eric's example was using sha256, not crypt.
--
Postgresql php tutorials
http://www.designmagick.com/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] password hashing and crypt()
alright, so you guys have responded and im really appreciative.
you have me thinking now..
so what are the real issues here?
1. portability
2. security (obviously)
im wondering now if crypt() is really even so practical. especially
considering the deal where only 2 characters are prepended as the
salt.
in the article i referenced, what theyve done is written a function
that creates a password with a salt whereby the entire salt
will be used in the resultant hash (actually a definable portion thereof):
define('SALT_LENGTH', 9);
function generateHash($plainText, $salt = null)
{
if ($salt === null)
{
$salt = substr(md5(uniqid(rand(), true)), 0, SALT_LENGTH);
}
else
{
$salt = substr($salt, 0, SALT_LENGTH);
}
return $salt . sha1($salt . $plainText);
}
i must admit that i didnt realize they were not using crypt() in this
function.
i must have glazed over it :(
after all this discussion, im now mostly looking for a reason to use crypt()
rather than to implement a function such as the one above. it has the
advantage of a known, consistent algorithm, that will be used to generate
the hash, rather than one that could potentially change on a per system or
future release basis; and the salt isnt limited to 2 characters.
-nathan
Re: [PHP] password hashing and crypt()
On Wed, 2008-01-23 at 00:40 -0500, Nathan Nobbe wrote:
alright, so you guys have responded and im really appreciative.
you have me thinking now..
so what are the real issues here?
1. portability
2. security (obviously)
im wondering now if crypt() is really even so practical. especially
considering the deal where only 2 characters are prepended as the
salt.
in the article i referenced, what theyve done is written a function
that creates a password with a salt whereby the entire salt
will be used in the resultant hash (actually a definable portion thereof):
define('SALT_LENGTH', 9);
function generateHash($plainText, $salt = null)
{
if ($salt === null)
{
$salt = substr(md5(uniqid(rand(), true)), 0, SALT_LENGTH);
}
else
{
$salt = substr($salt, 0, SALT_LENGTH);
}
return $salt . sha1($salt . $plainText);
}
i must admit that i didnt realize they were not using crypt() in this
function.
i must have glazed over it :(
after all this discussion, im now mostly looking for a reason to use crypt()
rather than to implement a function such as the one above. it has the
advantage of a known, consistent algorithm, that will be used to generate
the hash, rather than one that could potentially change on a per system or
future release basis; and the salt isnt limited to 2 characters.
Other than supporting legacy apps that used crypt() I don't see any
reason to use it now.
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
Re: [PHP] password hashing and crypt()
My apologies Robert, Gmail sucks. I'm bouncing this back to the list, where it belonged in the first place. Feel free to make corrections if I've mischaracterized what you wrote. Good luck with that, btw, but don't expect me to engage. Robert Cummings wrote: 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. In fact, it looks like you are saying that a 13-char hash is better than a 34-char hash, and with your zz $salt exposed to anyone who can tell hash from grits. No, I'm not at all saying that a 13-char hash is better than a 34 char hash. I'm saying that you get different types of encryption depending on how you use crypt, then I illustrated the point. Tying your example(s) to older (read: broken) encryption mechanisms. Then I tied that back to older code I've worked on that produces the encryption variety experienced when supplying a user defined salt... this is then used to make the case that legacy support can be obtained via the user defined salt. If we are dealing with how the Server handles the scripts, why is legacy a factor in the first place? Fit your scripts to the server, this is not some burger joint where you get it your way. And don't try to go international on me, the rest of the world had 128-bit encryption and was free to use it before the US populace could legally possess it for international transactions. Do you remember the Munitions Act? It says, Some operating systems support more than one type of encryption. So? Did you mean to say, control is needed on which type is used? I haven't looked into the crypt() function supplied by PHP beyond having read the initial manual for it and producing examples of output. That sounds like I don't know. So your earlier statement ultimately means I don't know??? Obviously, the defining the salt and not defining the salt have profound differences on the result produced (as illustrated). Per your examples, it's the difference between 13-char (hard) and 34-char(harder) differences. And with your 13-char example giving the $salt away in the first two columns (the scenario is a cracker who accessed your user/pass table and is trying to find matches), it doesn't take that cracker long to recognize equal values above and below the divisor. Solve for what is left. So this was a roundabout way of saying, verify the encryption mechanism? How does that make the random $salt less valid than the user-supplied $salt? No, You should have said yes and quit while you thought you were ahead. that was me saying that there is certainly a good reason to use a user defined salt-- legacy compatibility. The random salt is useless if you need to create a crypt()'d string that will match the crypt()'d string created by a C program 10 years ago-- Given that the scenario is a cracker who has your user/pass ID table, that was never a stated goal, purpose or anything. and so in this context, Okay, you win. I can't provide enough real world data to illustrate exactly how wrong you are, in your view because, in your view all this real world data does not get parsed properly. Myself and this is what you were talking around but wouldn't embrace, I think the $salt and encryption method both count for a lot. Given the same encryption method, why would a user-supplied $salt necessarily be better than a random $salt? Answer that only, if you can and expect a reply. --Doc it is true that the random salt is less valid than the custom supplied salt. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] password hashing and crypt()
On Mon, 2008-01-21 at 14:37 -0500, Mike Potter wrote: You should have said yes and quit while you thought you were ahead. I'm not trying to get ahead... I didn't know I was competing. Are we competing? I thought I was just answering posts. that was me saying that there is certainly a good reason to use a user defined salt-- legacy compatibility. The random salt is useless if you need to create a crypt()'d string that will match the crypt()'d string created by a C program 10 years ago-- Given that the scenario is a cracker who has your user/pass ID table, that was never a stated goal, purpose or anything. and so in this context, Okay, you win. I can't provide enough real world data to illustrate exactly how wrong you are, in your view because, in your view all this real world data does not get parsed properly. ??? Myself and this is what you were talking around but wouldn't embrace, I think the $salt and encryption method both count for a lot. Given the same encryption method, why would a user-supplied $salt necessarily be better than a random $salt? Answer that only, if you can and expect a reply. I never said it would. I didn't even come close to saying a user defined salt would be better than a random salt given that the encryption method is the same. From what hat did you pull that? I merely indicated reasons why the user defined salt was necessary. 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
Re: [PHP] password hashing and crypt()
Nathan Nobbe wrote: hi all, recently ive been debating a bit about the use of the crypt() function and the best practice thereof, im hoping you can help to clarify this for me. so, the crypt function http://www.php.net/manual/en/function.crypt.php has a second parameter, $salt, which, if not supplied will be automatically generated and presumably become a prefix or suffix of the returned string. now, the article on the phpsec website http://phpsec.org/articles/2005/password-hashing.html recommends to externally create a salt and to store that in a separate field in the database, which would then be used for subsequent password verification. theoretically, however, if the password is generated without a user supplied salt, there is a salt already embedded in the password anyway. so, i have the following questions 1. is the phpsec technique bloated or unnecessary 2. is it better to create a user supplied salt, and why or why not 3. is crypt() 'intended' to be used w/o a user provided salt, since it is a stable algorithm crypt has some issues which I haven't seen anyone else mention. The salt is actually contained in the crypted string as the first two characters, there's no need to store it separately. ?php $string = '12345678'; echo crypt($string, 'ab') . \n; ab1iBa.N.U2C6 echo crypt($string, 'cd') . \n; cdsmm9tFWz3CI The next problem (more importantly) is that crypt only looks at the first 8 characters when generating a hash. It doesn't matter how big you make the string, it's the same as chopping it off at 8 characters. echo crypt(str_repeat($string, 40), 'cd') . \n; cdsmm9tFWz3CI The man page explains this (I think): http://linux.die.net/man/3/crypt However if you use md5 or sha1 or something else, then yes store the salt separately because that is *not* part of the hash that gets returned. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] password hashing and crypt()
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
[PHP] password hashing and crypt()
hi all, recently ive been debating a bit about the use of the crypt() function and the best practice thereof, im hoping you can help to clarify this for me. so, the crypt function http://www.php.net/manual/en/function.crypt.php has a second parameter, $salt, which, if not supplied will be automatically generated and presumably become a prefix or suffix of the returned string. now, the article on the phpsec website http://phpsec.org/articles/2005/password-hashing.html recommends to externally create a salt and to store that in a separate field in the database, which would then be used for subsequent password verification. theoretically, however, if the password is generated without a user supplied salt, there is a salt already embedded in the password anyway. so, i have the following questions 1. is the phpsec technique bloated or unnecessary 2. is it better to create a user supplied salt, and why or why not 3. is crypt() 'intended' to be used w/o a user provided salt, since it is a stable algorithm any other direction or hints you can supply are much appreciated. thanks, -nathan
Re: [PHP] password hashing and crypt()
Nathan Nobbe schreef: hi all, recently ive been debating a bit about the use of the crypt() function and the best practice thereof, im hoping you can help to clarify this for me. so, the crypt function http://www.php.net/manual/en/function.crypt.php has a second parameter, $salt, which, if not supplied will be automatically generated and presumably become a prefix or suffix of the returned string. now, the article on the phpsec website http://phpsec.org/articles/2005/password-hashing.html recommends to externally create a salt and to store that in a separate field in the database, which would then be used for subsequent password verification. theoretically, however, if the password is generated without a user supplied salt, there is a salt already embedded in the password anyway. so, i have the following questions 1. is the phpsec technique bloated or unnecessary I can't see a dictionary attack being thwarted by the salt given that the salt is made available when a password is checked. I'm struggling to see how a salt will help if it's made available. but it's late, may be better brain can enlighten us :-) then again your question is a little skewed due to the fact that sha1() is used in the phpsec article and your talking about crypt - which encryption is better as it stands is the first question to ask no? AFAIK sha1() is recommended over DES but maybe I'm misinformed. 2. is it better to create a user supplied salt, and why or why not 3. is crypt() 'intended' to be used w/o a user provided salt, since it is a stable algorithm depends on the use - i.e. using it inconjunction with a .htpasswd file will required no salt (auto-generated salt), other usage recommends using an explicit salt. all this salt is hurting my eyes - I have a blind spot. any other direction or hints you can supply are much appreciated. thanks, -nathan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] password hashing and crypt()
On Jan 19, 2008 8:02 PM, Jochem Maas [EMAIL PROTECTED] wrote:
Nathan Nobbe schreef:
hi all,
recently ive been debating a bit about the use of the crypt() function and
the best practice thereof, im hoping you can help to clarify this for me.
so, the crypt function
http://www.php.net/manual/en/function.crypt.php
has a second parameter, $salt, which, if not supplied will be automatically
generated and presumably become a prefix or suffix of the returned string.
now, the article on the phpsec website
http://phpsec.org/articles/2005/password-hashing.html
recommends to externally create a salt and to store that in a separate field
in the database, which would then be used for subsequent password
verification.
theoretically, however, if the password is generated without a user supplied
salt,
there is a salt already embedded in the password anyway.
so, i have the following questions
1. is the phpsec technique bloated or unnecessary
I can't see a dictionary attack being thwarted by the salt given that the salt
is made available when a password is checked. I'm struggling to see how a salt
will help if it's made available. but it's late, may be better brain can
enlighten us :-)
then again your question is a little skewed due to the fact that sha1() is
used in the phpsec article and your talking about crypt - which encryption is
better as it stands is the first question to ask no? AFAIK sha1() is
recommended over DES but maybe I'm misinformed.
2. is it better to create a user supplied salt, and why or why not
3. is crypt() 'intended' to be used w/o a user provided salt, since it
is a stable algorithm
depends on the use - i.e. using it inconjunction with a .htpasswd file
will required no salt (auto-generated salt), other usage recommends using
an explicit salt.
all this salt is hurting my eyes - I have a blind spot.
any other direction or hints you can supply are much appreciated.
thanks,
-nathan
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
They say sha1 has been compromised.
http://en.wikipedia.org/wiki/SHA_hash_functions
I always make sure that I use a site specific salt which is just
appended on the user supplied value. I started doing that when I read
that people had created huge databases of hashed values that they can
just search on. At least this way no matter what the password isn't a
dictionary word. As for if that really adds value in the end I can't
say as I'm not really a security expert.
Eg. hash('sha256', $input.$salt);
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] password hashing and crypt()
-Original Message-
From: Eric Butera [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 20, 2008 12:24 AM
To: Jochem Maas
Cc: Nathan Nobbe; PHP General List
Subject: Re: [PHP] password hashing and crypt()
On Jan 19, 2008 8:02 PM, Jochem Maas [EMAIL PROTECTED] wrote:
Nathan Nobbe schreef:
hi all,
recently ive been debating a bit about the use of the crypt()
function and
the best practice thereof, im hoping you can help to clarify this
for me.
so, the crypt function
http://www.php.net/manual/en/function.crypt.php
has a second parameter, $salt, which, if not supplied will be
automatically
generated and presumably become a prefix or suffix of the returned
string.
now, the article on the phpsec website
http://phpsec.org/articles/2005/password-hashing.html
recommends to externally create a salt and to store that in a
separate field
in the database, which would then be used for subsequent password
verification.
theoretically, however, if the password is generated without a user
supplied
salt,
there is a salt already embedded in the password anyway.
so, i have the following questions
1. is the phpsec technique bloated or unnecessary
I can't see a dictionary attack being thwarted by the salt given that
the salt
is made available when a password is checked. I'm struggling to see
how a salt
will help if it's made available. but it's late, may be better brain
can enlighten us :-)
then again your question is a little skewed due to the fact that
sha1() is
used in the phpsec article and your talking about crypt - which
encryption is
better as it stands is the first question to ask no? AFAIK sha1() is
recommended over DES but maybe I'm misinformed.
2. is it better to create a user supplied salt, and why or why
not
3. is crypt() 'intended' to be used w/o a user provided salt,
since it
is a stable algorithm
depends on the use - i.e. using it inconjunction with a .htpasswd
file
will required no salt (auto-generated salt), other usage recommends
using
an explicit salt.
all this salt is hurting my eyes - I have a blind spot.
any other direction or hints you can supply are much appreciated.
thanks,
-nathan
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
They say sha1 has been compromised.
http://en.wikipedia.org/wiki/SHA_hash_functions
I always make sure that I use a site specific salt which is just
appended on the user supplied value. I started doing that when I read
that people had created huge databases of hashed values that they can
just search on. At least this way no matter what the password isn't a
dictionary word. As for if that really adds value in the end I can't
say as I'm not really a security expert.
Eg. hash('sha256', $input.$salt);
--
Let me share what I've read in a cryptography book some time ago. I hope to
remember it well, but for me it served as an explanation about what the
SALT is all about (for those of you who don't have a clue, like me). I
will put aside any cryptographic considerations like the strength of the
algorithms or steganography analysis.
Let's build a scenario (yeah, I was kind of a teacher in the past, lol). For
the sake of simplicity, let's assume the following:
1 - You have a database (actually, a table) of 10 rows with user encrypted
passwords, and somebody (the cracker) had made it to sniff in and get access
to it. Let's assume passwords are encrypted using MD5 and the cracker knows
it.
2 - No other data has been compromised, or no other compromised data means
anything to the cracker. He only wants to reverse engineer your passwords,
meaning by that to get valid passwords that match the encrypted (hashed is
the word) ones. Let's say that having those passwords, the cracker can
login to your system and do some interesting stuff, which is the only
ultimate goal of his.
3 - The cracker has a dictionary of 100 words to try, he hopes to find a
match within that dataset. Whether he finds one or more passwords using the
dictionary is not relevant to this scenario, but the metric here is how much
computational effort he has to make to reverse engineer the encryption.
Now, what would the cracker have to do to get one or more valid passwords?
Probably something like:
1 - Apply the MD5 function to the words in the dictionary. He gets a hashed
dictionary which probably he has already built long a go (for doing some
other obscure task).
2 - Compare each of the values in the hashed dictionary to the passwords
table to find matches.
Step 2 can be optimized in several ways, but I'll not get deeper into it (I
won't either give you O[X] values, as I don't have a clue, but some figures
can be made). Also, there's the chance that two users chose the same
password, and the hashes would be equal (in this case you would have only 9
passwords
Re: [PHP] password hashing and crypt()
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? -nathan
