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.
.

Relevant Pages

  • A key stretching algorithm with pre-shared keyword for symmetric encryption
    ... I'd like to discuss a key stretching algorithm for symmetric encryption for secure file exchange with pre-shared keywords. ... My idea is to use an intermediate key and two different salt where the final key hash will be computed in two separate hashing sessions but additionally inside each hashing session the salt will be altered also by a special function, in the example Python listing below just two simple byte swap of hash values followed by a bit-wise exclusive or calculation in order to generate a "rolling" salt. ...
    (sci.crypt)
  • Re: How to encrypt/decrypt a file
    ... Modified to use random IV value (and random salt). ... (and for CTR mode of operation counter IV gives much better IND-CPA security). ... get a cryptographically random salt (different for each encryption invocation) ... and the server is watching that this exact data is not stored on the server... ...
    (microsoft.public.dotnet.security)
  • Re: How to encrypt/decrypt a file
    ... However random IV (in addition to password's salt) is better and more secure solution anyway. ... (and for CTR mode of operation counter IV gives much better IND-CPA security). ... get a cryptographically random salt (different for each encryption invocation) ... even so your customer's requirement looks quite strange - the server is processing the data and the server is watching that this exact data is not stored on the server... ...
    (microsoft.public.dotnet.security)
  • Re: How to encrypt/decrypt a file
    ... Mitch's sample doesn't use have salt that I was talking about, but a password salt is not redundand... ... get a cryptographically random salt (different for each encryption invocation) ... The question is, from a security perspective, should the IV also be derived from a RNGCryptoServiceProvider ... even so your customer's requirement looks quite strange - the server is processing the data and the server is watching that this exact data is not stored on the server... ...
    (microsoft.public.dotnet.security)
  • Re: Not enough salt for high speed server connection
    ... > they are free to be of any design the management approves. ... > information is considered quite sensitive so strength of encryption is ... How is this salt used? ... > As you would expect the machines with higher clock speeds were able to ...
    (sci.crypt)