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
