#48664 [NEW]: crypt truncating salt values
From: patrickdk at patrickdk dot com
Operating system: linux 2.6.x
PHP version: 5.2.10
PHP Bug Type: Strings related
Bug description: crypt truncating salt values
Description:
Salts passed to the crypt function are truncated to 12 char lengths.
Reproduce code:
---
echo
crypt('test','$6$abcdefghijklmno$tQbBMthtllLykS8KyZiaZfkQjbTMyodcVype.b5CBDLWR5KYALlguf6YFXnE1H2I/LHQUA/3d4pc2XTCyaTPT/');
Expected result:
$6$abcdefghijklmno$tQbBMthtllLykS8KyZiaZfkQjbTMyodcVype.b5CBDLWR5KYALlguf6YFXnE1H2I/LHQUA/3d4pc2XTCyaTPT/
Actual result:
--
$6$abcdefghi$mZusigXFSGzFIySkaCAxY4PJrrBypV.jI7bF1LK0V.vNF2COAEzCQtWCI2noXXHUs6nUYgNURmoDVCLo6Eol//
--
Edit bug report at http://bugs.php.net/?id=48664&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48664&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48664&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48664&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48664&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48664&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48664&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48664&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48664&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48664&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48664&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48664&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48664&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48664&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48664&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48664&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48664&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48664&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48664&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48664&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48664&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48664&r=mysqlcfg
#48664 [Com]: crypt truncating salt values
ID: 48664
Comment by: patrickdk at patrickdk dot com
Reported By: patrickdk at patrickdk dot com
Status: Assigned
Bug Type: Strings related
Operating System: linux 2.6.x
PHP Version: 5.2.10
Assigned To: pajoye
New Comment:
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.
Previous Comments:
[2009-06-24 18:27:13] paj...@php.net
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).
[2009-06-24 17:36:37] sjoerd-php at linuxonly dot nl
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.
[2009-06-23 16:23:58] patrickdk at patrickdk dot com
Description:
Salts passed to the crypt function are truncated to 12 char lengths.
Reproduce code:
---
echo
crypt('test','$6$abcdefghijklmno$tQbBMthtllLykS8KyZiaZfkQjbTMyodcVype.b5CBDLWR5KYALlguf6YFXnE1H2I/LHQUA/3d4pc2XTCyaTPT/');
Expected result:
$6$abcdefghijklmno$tQbBMthtllLykS8KyZiaZfkQjbTMyodcVype.b5CBDLWR5KYALlguf6YFXnE1H2I/LHQUA/3d4pc2XTCyaTPT/
Actual result:
--
$6$abcdefghi$mZusigXFSGzFIySkaCAxY4PJrrBypV.jI7bF1LK0V.vNF2COAEzCQtWCI2noXXHUs6nUYgNURmoDVCLo6Eol//
--
Edit this bug report at http://bugs.php.net/?id=48664&edit=1
#48664 [Com]: crypt truncating salt values
ID: 48664
Comment by: patrickdk at patrickdk dot com
Reported By: patrickdk at patrickdk dot com
Status: Feedback
Bug Type: Strings related
Operating System: linux 2.6.x
PHP Version: 5.2.10
Assigned To: pajoye
New Comment:
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
Previous Comments:
[2009-06-24 18:48:36] paj...@php.net
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.
----
[2009-06-24 18:45:17] patrickdk at patrickdk dot com
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.
[2009-06-24 18:27:13] paj...@php.net
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).
[2009-06-24 17:36:37] sjoerd-php at linuxonly dot nl
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.
----
[2009-06-23 16:23:58] patrickdk at patrickdk dot com
Description:
Salts passed to the crypt function are truncated to 12 char lengths.
Reproduce code:
---
echo
crypt('test','$6$abcdefghijklmno$tQbBMthtllLykS8KyZiaZfkQjbTMyodcVype.b5CBDLWR5KYALlguf6YFXnE1H2I/LHQUA/3d4pc2XTCyaTPT/');
Expected result:
$6$abcdefghijklmno$tQbBMthtllLykS8KyZiaZfkQjbTMyodcVype.b5CBDLWR5KYALlguf6YFXnE1H2I/LHQUA/3d4pc2XTCyaTPT/
Actual result:
--
$6$abcdefghi$mZusigXFSGzFIySkaCAxY4PJrrBypV.jI7bF1LK0V.vNF2COAEzCQtWCI2noXXHUs6nUYgNURmoDVCLo6Eol//
--
Edit this bug report at http://bugs.php.net/?id=48664&edit=1
#48664 [Com]: crypt truncating salt values
ID: 48664 Comment by: patrickdk at patrickdk dot com Reported By: patrickdk at patrickdk dot com Status: Feedback Bug Type: Strings related Operating System: linux 2.6.x PHP Version: 5.2.10 Assigned To: pajoye New Comment: 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. Previous Comments: [2009-06-25 02:16:13] patrickdk at patrickdk dot com 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 [2009-06-24 18:48:36] paj...@php.net 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. -------- [2009-06-24 18:45:17] patrickdk at patrickdk dot com 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. [2009-06-24 18:27:13] paj...@php.net 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). [2009-06-24 17:36:37] sjoerd-php at linuxonly dot nl 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. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/48664 -- Edit this bug report at http://bugs.php.net/?id=48664&edit=1
#49713 [NEW]: global vs static usage
From: patrickdk at patrickdk dot com Operating system: Ubuntu PHP version: 5.2.11 PHP Bug Type: Scripting Engine problem Bug description: global vs static usage Description: the global modifier causes http 500 errors but doesn't produce any syntax errors or other messages when used incorrectly. It's behavure isn't documented and is described next to static that works differently. Reproduce code: --- http://bugs.php.net/?id=49713&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49713&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49713&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49713&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49713&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49713&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49713&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49713&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49713&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49713&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49713&r=support Expected behavior: http://bugs.php.net/fix.php?id=49713&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49713&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49713&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49713&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49713&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49713&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49713&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49713&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49713&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49713&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49713&r=mysqlcfg
#49713 [Fbk->Opn]: global vs static usage
ID: 49713 User updated by: patrickdk at patrickdk dot com Reported By: patrickdk at patrickdk dot com -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Ubuntu PHP Version: 5.2.11 New Comment: I dunno what you mean by 'all parse problems'. I turned on as much debugging info as I can, have all warnings/notify also logged. I saw normal errors like syntax/unused vars/... in the logs, but never anything about that global line. I used the test code: http://bugs.php.net/?id=49713&edit=1
#49713 [Opn]: global vs static usage
ID: 49713 User updated by: patrickdk at patrickdk dot com Reported By: patrickdk at patrickdk dot com Status: Open Bug Type: Scripting Engine problem Operating System: Ubuntu PHP Version: 5.2.11 New Comment: did some more testing, dunno. It seems to only be that one machine though that doesn't print the syntax warning, even though warnings/errors are getting logged. Would still be good to make this clear in the php manual though. Previous Comments: [2009-10-01 04:09:17] patrickdk at patrickdk dot com I dunno what you mean by 'all parse problems'. I turned on as much debugging info as I can, have all warnings/notify also logged. I saw normal errors like syntax/unused vars/... in the logs, but never anything about that global line. I used the test code: http://bugs.php.net/?id=49713&edit=1
