Re: [PHP] password hashing and crypt()
- From: ssskibeh@xxxxxxxxx ("Mike Potter")
- Date: Mon, 21 Jan 2008 14:37:12 -0500
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
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 wouldIn fact, it looks like you are saying that a 13-char hash is better
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.
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
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?
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
is true that the random salt is less valid than the custom supplied
- Re: [PHP] password hashing and crypt()
- From: Robert Cummings
- Re: [PHP] password hashing and crypt()
- Prev by Date: Re: [PHP] a better way to do a data import?
- Next by Date: Re: [PHP] password hashing and crypt()
- Previous by thread: Re: [PHP] password hashing and crypt()
- Next by thread: Re: [PHP] password hashing and crypt()