Comments (31)
I too would like the requirement dropped.
The situation with Debian is a little different than @tpetry mentions. Debian has backported the fixes to PHP 5.3.3-7+squeeze4 (the current version in Debian is +squeeze-14). That said, PHP 5.3.3 works with this library. Please drop the requirement from your composer.json.
from password_compat.
Indeed. Server-oriented distros will tend to backport fixes, which makes simple version checks like this useless.
from password_compat.
@tpetry, I believe that 5.3.7 is required not due to the bug in crypt, but rather due to the information provided at http://php.net/security/crypt_blowfish.php.
from password_compat.
@adduc Debian has backported all of that to it's PHP 5.3.3 version, including the new
from password_compat.
In that case I support the removal of the version check too. If we want to test something, then we should test the existence of
if (crypt('password', '$2y$01$salt$') == '*0') {
trigger_error()
But maybe we should just let the application implement this check. @ircmaxell What's your opinion on this issue?
from password_compat.
Ok, so I've been thinking about this for a while, and here's my stance:
Running crypt
every time the library is included is way too much overhead (since a composer install will load it on every page load). So that's right out from the start.
Requiring 5.3 won't work, because $2y$
wasn't introduced until 5.3.7... So lifting the version requirement is also out.
That leaves us with a bit of an issue. An issue that's directly attributable to the screwed up release processes of Debian. And yes, I call them screwed up because the second that they back ported a fix, the version ceased to be 5.3.3, and became their own branch. So calling it 5.3.3 is a huge misnomer. But that's besides this point.
I'm at a bit of a loss on to how to fix this. On one hand, removing the requirement would open significant issues for people which wouldn't be obvious (they install it on a non-debian 5.3.3). On the other, leaving it as is disables the library for debian users... So there's no really good solution that I can implement from my end.
Thoughts?
from password_compat.
My solution would be staying as compatible with old php versions as possible. I would only throw an exception while hashing when the crypt bug has been detected. This would make the api incompatible but would prevent horrible security problems.
from password_compat.
How about ignoring the PHP version requirement entirely, and checking the result of crypt
in password_hash
and triggering an error if the return value indicates incompatibility?
from password_compat.
Bonus points: make the triggered error message clear that it is due to an incompatible implementation of crypt
.
from password_compat.
IOW, duck-typing FTW.
from password_compat.
It's not just Debian, other long term support distros also backport (I would imagine CentOS/RHEL has the same issue, being officially pegged to 5.3.3 in release 6.3).
One option might be having users set a constant to signal that they don't wish to run the version check. Something like PASSWORD_COMPAT_NO_CHECK, and maybe offer a small test script to verify if their install of PHP has the vulnerable version of crypt_bcrypt?
from password_compat.
Here's what I'm thinking:
Remove the check at runtime completely. Leave the check in composer though...
I could theoretically create an installer for composer which would throw an exception if it's not supported on install... But that's not great either (there would be more code in the installer than the library itself)...
thoughts?
from password_compat.
@ircmaxell For argument's sake... what's the value in putting a hard PHP requirement into Composer rather than just documenting "dude, this don't work in PHP version X.Y.Z"? If someone installs this library on 5.3.5, say, what exactly is the problem? Is it just "avoiding 5.3.7" that is the goal?
from password_compat.
@Crell: the issue is that it won't work in regular 5.3 at all. The $2y
crypt format was added in 5.3.7. So to prevent people installing the library and winding up with bool: false
in their database (because they didn't check the output), I put 5.3.7 as the required version...
from password_compat.
Is there a specific call to crypt that would be different between < 5.3.7 vs > 5.3.7 to identify whether the $2y would be supported?
EDIT: Nevermind, read @gergoerdosi's comment earlier and tested it in 5.3.3 and 5.3.18 (only versions available to me at the moment) with two separate outputs consistent to what he was mentioning.
from password_compat.
@adduc Actually, that's a good point. I just tried this on 3v4l, and it looks like it might work... http://3v4l.org/8ugqB#tabs
On good versions, it throws the *0
error which says that it recognizes the config, but the salt is incorrect (there was an error), and no hash is actually executed (not precisely true, but close enough for our purposes here).
On bad versions, it treats it as a DES based hash, and runs a fast hash.
from password_compat.
I still don't understand why you can't remove the version requirement and instead, just do:
$ret = crypt($password, $hash);
if (!is_string($ret) || strlen($ret) <= 13) {
return false;
}
if (strncmp("$2y$", $ret, 4)) {
trigger_error("password_hash(): crypt() function not compatible, see http://php.net/manual/en/password_compat.requirements.php", E_USER_ERROR);
}
This eliminates the "the version number is a lie" problem, and eliminates the "don't waste CPU cycles checking for compatibility when the library is sourced" issue, and this blows up as it should on incompatible systems so that users won't silently think everything's working when it's not.
from password_compat.
I'm not exactly well-versed in GitHub (or Git in general), but I was able to make a few repos for testing an installer class for this library.
The forked version of this repo with a fixed composer.json is at https://github.com/Adduc/password_compat, a version of the installer at https://github.com/Adduc/password_compat_installer, and a sample repo testing out the functionality at https://github.com/Adduc/password_compat_use
from password_compat.
My thinking is along the lines of what dossy is suggesting. Basically, rather than version number detection in Composer, do feature detection in PHP. You can download the library, but if you try to run it on a known-broken system (or on a not-known-good system) it fails hard with an Exception. Not quite as nice as not letting you download it in the first place and getting your hopes up, but more accurate about when it will work.
from password_compat.
I agree with Crell. That also solves a potential problem where people use Composer to download this library on a machine with a good PHP version, but rsync or push all their code to a machine with a bad PHP version. The runtime detection (as opposed to install time detection) would warn the user about the issue.
from password_compat.
I just pushed 1.0.0, and in it I removed the run-time version check and the composer dependency.
Run version-test.php
to determine if your php version is compatible. If it returns false, it's not. Now it's on you to determine the version correctly...
from password_compat.
I'm re-opening this, as I just ran a test against 5.3.3-debian on Squeeze (6.0.7), and it failed. It appears that $2y$
is not available on Debian Squeeze with a stock install of php5-cli
...
If anyone can elaborate as to how it possibly could have worked, I'm all ears. The version-test.php
file definitely fails.
If not, I am going to re-instate the version check, as there isn't a way to actually run it under 5.3.3-debian...
from password_compat.
I see at:
http://stackoverflow.com/questions/12459896/password-compat-for-older-php-version/12461336#12461336
you mention:
Now, what can you do if you're stuck on a lower version? You could fork the library and adjust
$2y$ to$2a$ . That will at least get you to work. Passwords generated in this manner will be portable with future versions (the library is designed to be able to verify older crypt() passwords).
Please excuse my lack of expert knowledge in this area, but is there scope to use
from password_compat.
We run PHP 5.3.3-7+squeeze14 with Suhosin-Patch on Debian and have the same problem ($2y$
returning false). The research I did indicates that the bug has indeed been backported, however the new 2y
prefix has not been. My understanding was it is safe to use 2a
since the bug is no longer present (from memory the specific backported patch can be found here).
I made an API breaking change to the library to accomodate this, adding a new constant PASSWORD_COMPAT_2A
that when true switches to the 2a
algorithm (see here). I don't necessarily think this is a nice solution, however I wasn't able to come up with a better one.
from password_compat.
@phindmarsh and @mvl22 My main concern here is that providing support to 2a
which has known vulnerabilities against it the majority of installations. I feel the better alternative is to just educate people to upgrade to a better, more stable, and more secure version. If you're on Debian, switch to a DotDeb repo and install PHP from there. If you're on CentOS, switch to REMI. The point is the alternatives exist...
And I don't think it should be the role of a security library to compromise security for pretty much any reason...
from password_compat.
@ircmaxell agreed, I knew the implications of my changes so was happy to do so. My circumstances dictate that I can't update my php version at the moment, however when that changes I'll be reverting back to the original library.
From my (limited) understanding the Debian philosophy is to not introduce any new functionality in a security patch, hence why I assume the 2y prefix was not backported with the fix. I agree this is a dangerous edge case to leverage and I don't think it's the purpose of this library to accommodate that. As you said, education is a better solution here.
from password_compat.
Just to throw in a little... ...additional impetus to this issue, the Debian Version 6.0 with backports from dot-deb seems to have halted at:
php --version
PHP 5.3.6-6~dotdeb.0 with Suhosin-Patch (cli) (built: Apr 17 2011 12:27:20)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
I believe this may render the library completely incompatible... ...would be nice if there were a way around that?
Admittedly, 6.0 is now just beyond it's support period as well, but I expect it's very prevalent on servers on the web.
from password_compat.
Even though Debian didn't backported the $2y$
prefix to their 5.3.3 package, they did add $2x$
, that supports the flawed version. So you can test if the $2a$
prefix is secure using this:
$always_flawed = crypt('password_with_utf8_éèçù', '$2x$04$0123456789012345678901$');
$maybe_flawed = crypt('password_with_utf8_éèçù', '$2a$04$0123456789012345678901$');
if($maybe_flawed === $always_flawed) {
trigger_error('flawed $2a$');
}
However, this would only work for debian 5.3.3 packages, as $2x$
is probably not available before 5.3.7 in other distros.
from password_compat.
# php -v
PHP 5.3.3-7+squeeze17 with Suhosin-Patch (cli) (built: Aug 26 2013 07:26:12)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
from password_compat.
I think a require
directive for "php": ">=5.3.7"
is needed for the general public. The backporting and security patching of past PHP releases is branching off PHP.
IMHO having a security vulnerability before 5.3.7
is the common case and the other is the exception.
It is better to inform users of this library in any way possible they might be affected. If users know their distribution of PHP is fixed then they could install the library by just copying the file, adding a submodule or whatever.
It is not OK to leave this out only because a part of the users may not be affected. Constraints are always better when it comes to security.
from password_compat.
By the way, Debian moved to 5.4.x
https://packages.debian.org/wheezy/php5
from password_compat.
Related Issues (20)
- password_verify fails for hashes from crypt() HOT 3
- mysqli_real_escape_string
- PASSWORD_ARGON2I Algo Support HOT 1
- Password verify issues HOT 1
- php7 Compatibility problem HOT 5
- PHPCompatibility ruleset for password_compat
- Trouble with PHP 5.6 & Password Verify HOT 1
- A HOT 1
- A
- Function not outputting the same hash as built-in function HOT 8
- E_USER_ERROR vs warning HOT 1
- function_exists('PasswordCompat\\binary\\_strlen') needed? HOT 4
- password_hash("foo") returning false on 5.3.2-1ubuntu4.30 HOT 7
- Cannot verify the password after hashing HOT 1
- Suggestion: use *.phpt tests from php-src to improve compatibility
- Problem with verifiying the hashed password HOT 3
- Using the project on a newer version of PHP HOT 2
- This Repo HOT 7
- use password_compact in codeigniter HOT 2
- This lib on php 5.5 HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from password_compat.