Thank you for your bug report.

In your example, you use a salt beginning with $6$, which tells crypt to use SHA512. However, this usage is not described in the PHP manual. It does not seem to work correctly in PHP 5.2 and is does not seem to work at all in PHP 5.3. I think crypt() does not support SHA256 or SHA512, since it does not work correctly and is not in the manual.

Of course, it would still be nice if crypt() supported this or gave a decent error message.

Agreed, I already make it portable with blowfish support and other. There is some issues with the implementation which can be fixed later as well (see internals archives for the discussion).

 

crypt works fine for sha256 and sha512, except when using salts larger than 9 bytes. This is cause (I checked the source) at compile time it detects what the system supports and limits salt lengths based on that (in this case MD5).

The problem with this is, systems that support sha512, rhel5, ubuntu 8.04/8.10/9.04 if they use sha512 or sha256, crypt works just fine, and php will pass it just fine, EXCEPT if the salt is >9 bytes.

So if the system used a salt >9 bytes, php will be unable to check those passwords, even though the underlaying crypt function can do so.

Since ubuntu just changed the default to sha512, I'm sure there will be a flood of people having problems soon.

I currently tested sha512 on php 5.1.6 and 5.2.10 on rhel5 and ubuntu 8.04 and it works fine with 8byte salts. So in my application I limited it to using 8bytes, but 16 would of been nicer.

If linux crypt supported blowflish, then this would be a non-issue cause the salt would be set to 60bytes.

Debian/Ubuntu should really stop to do stupid things with PHP.

Which version do you use (of ubuntu)? And have you tried using 5.3.0RC4? If not, please try.

Ok, I tried php-5.3.0RC4 on ubuntu 8.04

It didn't work at first, and I found out it's cause it didn't detect crypt_r, so php used it's internal routines, so that was to be expected.

It seems configure doesn't test for crypt_r in libcrypt

So I overrode that, and it worked fine (same results though).

salt is truncated cause php only detects crypt_md5, and truncates salts to 12bytes. If I hack the salt_max then everything works as expected.

same results using rhel5

What I would like to see is this:

We can use the new php builtin crypt function for hashs it can understand, like des, md5, and blowfish (I think it does md5)

For hashs it doesn't understand, by matching the the has type in the supplied salt, if it start with $ and follows a type unknown, pass it off to the system crypt function (or crypt_r). If one doesn't exist (windows) then it can just fail.

Then it wouldn't matter if new crypt hashs come into being and php can't handle them internally, as long as the system libs can.

Yes, it can be a solution.

We can also simply implement the missing algo in php and always use them, for the users benefits (portability).

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.