Can you please open a tracker item for this? I don't think the tracker item mentioned in the original PR does fit. The scope of this PR is much bigger.
Some description what exactly you want to solve should also be added.
Also can you provide some testing instructions? This would help the people who have to reproduce the issue and test the fix.

I'd also add that we need to be sure to extensively test this on different server environments as well on sites moving from 3.1.5 / 3.1.6, as well as sites currently running 3.2.0.

Here is the tracker item: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=32804&start=0

To assist with testing this, I've built test packages based on master plus this pull request (synced to Hackwar/joomla-cms@2d8f524). Packages are available at http://developer.joomla.org/PR-packages/2589/ and will allow testing for all scenarios (new installs and updates from 2.5 forward).

It also removes the arbitrary truncation of passwords to 55 chars that was falsely introduced.

Comment from Elin in the original tracker put here for reference:

The problem with allowing longer passwords is that it is not forward compatible. Users using such password that were always truncated will then have non working passwords if the bcrypt limit is ever changed.

Further too long passwords can be an attack. It's also totally unrelated to the issue at hand.

I would add here that truncating passwords (even if done by PHP password_hash() natively) without telling the user is certainly not transparent.

1. We are truncating passwords in JForm already to 100 chars max.
2. bcrypt internally indeed uses only the first 55 chars as it seems. But that is a limitation that the bcrypt implementation has to care for.
3. Also, if we ever switch away from bcrypt again, for example to scrypt, why should we have the arbitrary limit of bcrypt in our code? Similarly, why should we have that limitation if we are not using bcrypt, but SHA256 right now?
4. Last but not least, password_hash() takes care of all of these issues for us. If we use longer passwords, it truncates the password internally. If we use a different algorithm, it automatically hashes to that new algorithm and still validates the old passwords. Hashes created with password_hash() will always be verifyable with password_verify(), except for everything before 5.3.10.

If there is one thing that is not forward compatible, its forcing the passwords to an implementation specific length.

I would recommend implementing bcrypt in 4.0 and not earlier and at the same time dropping the SHA256 code that is in the verify-method.

-1

I disagree with this approach. Rolling back to a password hashing algorithm that's currently trivial to crack and sticking with it for 2-3 years is irresponsible.

In 2010 a password cracking rig capable of computing 33 billion hashes per second used to cost $2,500 USD (Whitepixel). In 2013, a password cracking rig of the same capacity costs about $600 USD (using Hashcat). Extrapolating from that thought, a password cracking rig capable of cracking the majority of passwords in a realistic amount of time will cost petty cash in 2-3 years and will be much faster than the previous iterations. Moreover, in the last 3 years we've seen strides in password cracking techniques. I don't know if anyone noticed how much and how fast stolen password databases are being cracked these days (cough Adobe cough).

Maybe we should stop being hypocrites and think of the bigger picture. We are hypocritically shouting "BUT, BACKWARDS COMPATIBILITY!" when we trash it in small, yet significant, ways in every minor release of Joomla! without any good reason. Ask extension developers, they know. Now we have a really damn good reason to break b/c: security! So what do we do? We decide to screw it up... Is supporting crap hosts which haven't been updated in the last 5 years worth putting our users (and their users!) at risk for the next 3+ years? That's the question we should all be asking.

This proposal is actually meant to provide a foundation from where we can move forward. It cleans up the code and fixes the bugs, concentrating the necessary changes for a different hashing system in one place. Right now we are flopping around, discussing about a dozen different issues at once and we aren't getting forward, because we don't agree on the hashing algorithm. So this is the proposal to fix all the other bugs and pushing the hashing algorithm to another thread. I didn't want to leave the trunk in a non-working state, so I added MD5 back in for the time being. When we decide how to proceed, I'm more than happy to change that.

"Nicholas K. Dionysopoulos" notifications@github.com schrieb:

-1

I disagree with this approach. Rolling back to a password hashing algorithm that's currently trivial to crack and sticking with it for 2-3 years is irresponsible.

In 2010 a password cracking rig capable of computing 33 billion hashes per second used to cost $2,500 USD (Whitepixel). In 2013, a password cracking rig of the same capacity costs about $600 USD (using Hashcat). Extrapolating from that thought, a password cracking rig capable of cracking the majority of passwords in a realistic amount of time will cost petty cash in 2-3 years and will be much faster than the previous iterations. Moreover, in the last 3 years we've seen strides in password cracking techniques. I don't know if anyone noticed how much and how fast stolen password databases are being cracked these days (cough Adobe cough).

Maybe we should stop being hypocrites and think of the bigger picture. We are hypocritically shouting "BUT, BACKWARDS COMPATIBILITY!" when we trash it in small, yet significant, ways in every minor release of Joomla! without any good reason. Ask extension developers, they know. Now we have a really damn good reason to break b/c: security! So what do we do? We decide to screw it up... Is supporting crap hosts which haven't been updated in the last 5 years worth putting our users (and their users!) at risk for the next 3+ years? That's the question we should all be asking.

---

Reply to this email directly or view it on GitHub:
#2589 (comment)

@Hackwar I understand your point of view and I agree with it. Since I'm not PLT I can only say how I would handle this situation in a way that's both backwards compatible and future-proof:

• Release Joomla! 3.2.1 with your patch. This fixes broken sites which is a pressing objective.
• Release Joomla! 3.3 with a proper bCrypt implementation and the minimum PHP version requirement increased to 5.3.7.

This way we can both fix broken sites and not put our CMS' future in harm's way. In this context I agree with your PR, i.e. I agree with the PR providing a clean slate on which we can develop a proper bCrypt implementation a.s.a.p. and not in 2-3 years. In so many words, I disagree with your "I would recommend implementing bcrypt in 4.0 and not earlier" comment. Implementing bCrypt in 4.0 is too little, too late.

@nikosdion

+1. I see no other sensible solution.

Now that it seems like we're coming to a consensus on things, if this is the patch we are going to go with, then it will require careful testing across various supported server environments and dealing with all scenarios:

• Users updating from 2.5 thru 3.1 to 3.2.1
• Users updating from 3.2.0 to 3.2.1
• New installs of 3.2.1

To assist with testing this, full install and update packages are available at http://developer.joomla.org/PR-packages/2589/. You'll need to download and install the packages through the Extension Manager, a XML file for testing updates via the update component hasn't been built (yet).

Please note that all testing results and issues should be reported at http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=32804&start=0. Let's try to leave this PR for code related discussions unrelated to the testing of this patch from here on.

Looking at our code coverage report, we really should try and get this code unit tested too.

I tested this and it doesn't work for one important use case...

TL;DR
Upgrade from 3.1.6 to 3.2.0 to 3.2.1 causes failure, users cannot login on 3.2.1 when strong passwords are enabled in 3.2.0 and user updates password.

Full test description on JoomlaCode

Posting here because not everybody monitors JoomlaCode.

Thank you for that @KISS-Web-Design - that is exactly the type of testing and feedback we need on this issue.

Joomla! site upgraded from 3.0.x to 3.1.5 to 3.2.0 to 3.2.1; Strong passwords were ENABLED.

Login with existing user: NEGATIVE

• Before the upgrade I checked the database. The Super User password is hashed using bCrypt (signature $2y$).
• Installed Joomla!3.2.1-Stable-PatchPackage (from loaction provided by @mbabker) via Extensions Manager
• Tried to log in: FAILURE
• Replaced the password in the database with an MD5 hashed one from a different user, now I was able to log in.

Login with new user: SUCCESS

• Create a new super user
• I was able to log in with the new super user
• Checked the database, the password is hashed with salted MD5

Ergo: this patch is unable to authentication using passwords hashed with the botched bCrypt implementation

** FIX FOR THIS ISSUE **

In plugins/authentication/joomla/joomla.php add the following code in line 58, right after
$match = JUserHelper::verifyPassword($credentials['password'], $result->password, $result->id);

        // Work around for Joomla! 3.2.0's botched bCrypt implementation
        if (($match === false) && (substr($result->password, 0, 4) == '$2y$'))
        {
            $password60 = substr($result->password, 0, 60);

            if (JCrypt::hasStrongPasswordSupport())
            {
                $match = password_verify($credentials['password'], $password60);
            }
        }

Now the patch tests successful with both upgraded and new installations. Moreover we give priority to a future, correct, implementation of bCrypt over the existing botched attempt as this ugly, crappy code will only run if JUserHelper::verifyPassword fails.

@nikosdion fix works for me as well. Pulled my site down (PHP 5.4 live and local, strong passwords enabled), tested update using the packages provided, could not log in with packages as posted (this PR basically). Added in @nikosdion code and got in. So I read through verifyPassword() and where it's checking the hash, it's actually using the clear text password. Changing $password to $hash in lines 332 and 342 got me into the site with @nikosdion code removed. But, the password isn't rehashed from BCrypt to MD5; is this intended (seems like no the way the code reads to me)?

And digging a little bit more, $user->save(); in verifyPassword() is returning a false. The User not Super Administrator message is getting thrown by one of the exceptions in JUser::save() for me. Ironically, I'm using my site's only account which is a Super Administrator.

And last comment spam for now. In JUser::save(), it sets $my = JFactory::getUser(); which is then checked later at $iAmSuperAdmin = $my->authorise('core.admin');. This fails to return a usable result in this case because $my returns a JUser instance of a guest user. So either JUser::save() will have to be adapted for this specific case or the rehash will have to be done after the user is authenticated and JFactory::getUser() returns an instance of the logged in user.

And that is why I want more people to look over this, to find these snafus. I updated the PR to fix these issues and we should be good/better now. May I ask for another round of testing? Thank you!!

Looking at the commit, looks like the issues are fixed. I'll make new
packages when I get home later today to test with.

On Thursday, November 28, 2013, Hannes Papenberg wrote:

And that is why I want more people to look over this, to find these
snafus. I updated the PR to fix these issues and we should be good/better
now. May I ask for another round of testing? Thank you!!

—
Reply to this email directly or view it on GitHub#2589 (comment)
.

New packages are posted (same URL, http://developer.joomla.org/PR-packages/2589/).

Tested.
3.1.5=>3.2.0
Creating new user. I get this password BEFORE saving the joomla user plugin:
7f77c8caabbe7e4f7620d44e64067e86
Can't login

Updating by using Michael package http://developer.joomla.org/PR-packages/2589/Joomla_3.2.x_to_3.2.1-Stable-Patch_Package.zip

That user still can't login
(PHP 5.3.14)
Users with md5 or bcrypt passwords can login OK

That is the one situation where Joomla currently does not generate a proper hash at all, it seems.

7f77c8caabbe7e4f7620d44e64067e86 looks like an unsalted MD5 from what I understand, or am I wrong?

It is an unsalted MD5 hash. I have never seen one of these in Joomla! 2.5 and 3.x. I do, however, know that this is the kind of passwords users are told to create when they want to perform a manual password reset when they are locked out of their site. This stupid thing is found in our own documentation http://docs.joomla.org/How_you_reset_an_administrator_password%3F

I believe that step number 7 in the "Directions" is most misleading. I have not seen Joomla! magically convert passwords to salted MD5. That was only relevant in the Joomla! 1.0 days, when salted MD5 was first added and, indeed, an automatic password hashing upgrade was included.

@infograf768's case is legit. He followed the Joomla! documentation instructions and ended up with a bricked site. Apparently we have to modify our code to be able to compare against unsalted MD5 hashes :( And someone please update the documentation. I can't figure out the bloody CAPTCHA on the docs site!

Thing is: It already works with unsalted MD5. That hash is something else.

See the line comment. It is not an unsalted MD5, it is in fact a salted MD5, but the salt is not attached. So whatever we do, we can't recover those passwords. We could stand on our heads and wont be able to convert/verify those. These people will have to use the reset feature.

Oh, and a quick FYI: If the MD5 has no salt, its updated to have a salt with this implementation in the future.

RFC: Actually to make life easier to the poor users, as it's Joomla 3.2 that does that very buggy lock-out, if the authentication meets such a salted (with salt lost) password that doesn't match, a password recovery email be sent to the user automatically (with a message displayed) (and then allowed also for super-admins in that very particular buggy case of unsupported unrecoverable buggy password stored) ?

Only minus-risk I see for this convenience idea is if the admin email is not up-to-date, then recovery+access info is sent to wrong address.

@beat what would happen in this case if the user just mistyped the password? Would he not get that email as well? I don't think there is a way to distinguish between a wrong password and a wrong hash.

I think we will have to make a prominent message (read: postinstall message and in release announcement) that those users need to manually reset their password.

@Hackwar Do you know in which cases those wrong passwords were generated so we could put the scenario into the message as well. Like is it happening only on certain PHP versions, only if "Strong Passwords" were enabled/disabled/nothing saved?

@Bakual This is for everyone who updated to 3.2.0 and did not save the Joomla user plugin and then a new user is registered. So basically everyone who updated and who allows user registration. Those new users can not login.

@beat Since missing hashes could also be from manual password resets, there is no way to distinguish those. I'm very hesitant to send out mails on that notion.

@Hackwar manual password resets should also have salt in 3.2.1. So it's same case: salted-md5 without salt should just be considered as invalid entries coming from 3.2.

@Bakual If a user mistyped a password, but the hashed password stored in the database is a valid format, nothing special happens.

Yes, red message that password reset is needed is a good idea (with at least a link to wiki page for howto, or...additionally, more friendly, a button to reset the password, with maybe a field to type-in the admin's email for additional verification to cover the case of an outdated email address that i raised as only negative).

@beat The documentation instructions on a manual password reset through the database (not through Joomla!'s "Forgot your password" link which may not be visible in the front-end) tells people to create unsalted MD5 sums for a good reason: explaining unsalted MD5 is hard enough, trying to explain the salted version is incomprehensible for many people.

Regarding the button to reset the password from the administrator's login page, it's a bad idea. Think about it. It's best to change the password reset page and tell users to first visit index.php?option=com_users in the front-end. If that fails (they've forgotten the password and their email) just ask them to go through the database.

Also, if you want to be thorough, the password reset page should check the two factor authentication status of the user and request the secret code on top of the password reset token. But that entire discussion is outside the scope of this PR anyway.

Re-tested with the latest patches, 3.1.6 -> 3.2.0 -> 3.2.1

Same method as before, unfortunately same result.

User can't login in 3.2.1 after 3.2.0 enables strong passwords and user changes the password.

@nikosdion You didn't understand my proposal. But agreeing that it's outside the scope of this PR.

Only think that might be of use (since super-admins are not allowed to reset their password) is in admin login when we detect a password hash with salt missing for a super-admin, to display a red error with the link to the wiki. And that too is out of scope of this bug-fixing PR.

@KISS-Web-Design Many thanks for your tests.

@beat Sorry, my wording was confusing and I did not adequately describe my proposal.

I am against sending an email automatically as a result of a failed administrator login or having a password reset button in the back-end for security reasons. I'd rather do a small and easy change to the login error message in the administrator back-end: add the URL to the Joomla! Documentation Wiki page on password reset. In this context I said that we should add the instruction to visit index.php?option=com_users in the front-end etc etc. I was simply extending on this thought of yours: "red message that password reset is needed is a good idea (with at least a link to wiki page for howto)".

@KISS-Web-Design Can you please check your #__users table before upgrading to 3.2.1. Does the password field start with $2y$ and if so what is its length?

Only think that might be of use (since super-admins are not allowed to reset their password) is in admin login when we detect a password hash with salt missing for a super-admin, to display a red error with the link to the wiki. And that too is out of scope of this bug-fixing PR.

@beat Is this a possible error condition? I think updating users already have an existing superadmin which they can use. Given the explanation from Hannes a user would have to follow this steps to run into this problem:
1. Update Joomla to 3.2.0
2. Create a new SuperAdmin user
3. Delete the existing SuperAdmin user without testing the new one.

@beat No problem.

@nikosdion

The password does indeed begin with $2y$

93 characters long AFTER update to 3.2.1 (see below for a copy of the hash taken after the update)

$2y$10$spwvewJfWE2B7.bm1zu3HOfUXR/KlJHQbqiatMU8SIcbmLXSTc32q:MeFMMZNwjIPeBJ3iD5GNO7K68ALqVsfL

@Bakual Indeed, a good point which is correct if they do the upgrade from within Joomla (but not if they don't overwrite files or using their hosting control panel to do the upgrade). But that good point makes me think that there might be less people with exactly that problem than we think. End of the proposal, thanks for the feedbacks. Back to fixing the bugs and testing (I wish i had more free time these days to help in code and testing as this is really urgent).

I had a client of mine, JC Muller (who doesn't have a GitHub or JoomlaCode login) test this patch. His site is a fresh Joomla! 3.2.0 installation and he only has the Super User account created during installation and two test users. He had a problem with newly registered users under 3.2.0, they couldn't log in unless he changed their password in the User Manager. He installed the (latest) Joomla! 3.2.1 patch and he reported that:

• He could log in as a Super Administrator
• Newly registered users had no problem logging in, without him having to change their passwords manually

He is using PHP 5.4.21, MySQL 5.1 and he's hosted on 1&1 (UK). He asked me to post here on his behalf, thanking everyone for the patch.

I haven't been able to test as I'm not near a dev site to apply, but I read through the code and I think this patch has a similar issue to what 3.2.0 had where the password is always re-encrypted on login.

In the /plugins/user/joomla.php file is the following block in onUserLogin:
if (strpos($oldUser->password, '$2y$') === false || password_needs_rehash($oldUser->password, PASSWORD_DEFAULT))
At that point, $oldUser isn't defined, so the user's password hash is always going to be updated, regardless of whether it was updated before.

I think that should be updated to $instance instead of $oldUser.

Will test when I get a chance, but wanted to point that out right as I read through it.

Otherwise, looks like good updates from a read-through (but no actual testing).

Fixed it. Thanks for the find.

I've again updated the packages with the latest commits. http://developer.joomla.org/PR-packages/2589/

Again took my site's backup, restored to local, updated from 3.2.0 to 3.2.1 using patch package linked above. Logged out of admin and logged back in. Login successful, password rehashed from BCrypt to MD5. Went to front end and registered new user. Enabled user via admin. Logged in test user on front end successfully. Created a second test user via admin and checked front end login, user was able to log in successfully. Logged out of admin and logged back in, password not rehashed. Without e-mail services configured on my local environment, I think this is the extent to which I can go.

We've done a bit of testing with 3.1 sites upgraded to 3.2.0+this patch and 3.2.0 -> this patch. In each case, there were existing users that were able to login after the upgrade. This is a PHP 5.4 installation, so we were not testing the SHA256 case.

We also were doing testing with our 3rd social networking integration extension, which uses the API to create users and set a 'random' password for them. This functionality, which did experience some issues with the 3.2.0 release, is working as expected with this patch.

So, from what we see, the patch fixes things for our 3rd party extension as well as standard Joomla usage cases.

We seem to have quite a few successfull testers now, including tests with 3rd party extensions. Should we call this then fixed and commit the changes?

Remember, that we still have to add the notice for raising PHP requirements for the next version and that the remember me feature still also needs to be checked upon. Still lots of stuff to do before 3.2.1...

This patch also fixes a similar issue we had with Akeeba Subscriptions. On Joomla! 3.2.0 newly created user accounts could not log in. With this patch this issue is resolved. I didn't have the time to check any other aspects of the patch (they were already fixed in the previous version of the patch) so you get my tentative +1.

I'm testing this according to a very real world scenario that I'm facing right now. Unfortunately, unsuccessfully.

I have migrated a Joomla 1.5 site to 3.2 on my local dev server, which is running Ubuntu 12.04 / PHP 5.3.10. The production server is running Ubuntu 10.04 / PHP 5.3.2. The site works fine locally, but I am unable to log in it on the production served. As I have FTP access, I've tried overwritting the files on the production server using Michael's update packages, both the 3.2.x to 3.2.1 stable update and the 3.2.1 stable update. Neither package resolves the issue and I am unable to log into the site.

The Ubuntu 10.04 / PHP 5.3.2 environment is available as a Vagrant box at https://www.dropbox.com/s/t8fpuit9pnqvdyr/lucid32-amp.box

Hi Matt, this is the situation that we can't solve and that I warned against. Hashes from PHP 5.3.10 and those from versions below that differ and thus a site that moves from a >5.3.10 to a system <5.3.10 will not be able to authenticate the old hashes. There is nothing that we can do. You can only use the password reset feature to reset your PW.

@Hackwar thanks. I was suspicious this would be the case. Do you to know if disabling strong passwords, and then resetting the password on the php 5.3.10 install, would also solve the issue?

It should do - but I think the non-bcrypt stuff is the stuff that's foobar'd

@betweenbrain I wouldn't count on it that disabling strong passwords will help. There are too many issues for that I could put my hand into the fire for that.
However the password resetting will work with 3.2.1 for sure.

@Bakual @wilsonge thanks. I'll test different recovery methods and see if I can document them.

Re-tested with the latest patch, 3.1.6 -> 3.2.0 -> 3.2.1

Same test method I used previously.

Summary

2 users / passwords setup on 3.1.6, upgrade to 3.2.0. Both can login. Changed one in the frontend and one in the backend. Both can still login. Upgrade to 3.2.1. Both can login :-)

Checked database, 3.2.1 password is rewritten as MD5 hash on user login...
12b8a5b70ba09c47b93c0b7981b10e8f:jbe7K4Y8p9leCwDWdyVYd6Fz4HtYCvxk

on 3.2 it was using bcrypt (i.e. it began with $2y$).

Shiny happy people...

Same server as before (php 5.4.16; MySQL 5.5.32-cll; linux server running cPanel 11.40.0 (build 26); apache 2.2.24)

Chris.

I tested http://developer.joomla.org/PR-packages/2589/

New installation on

• ubuntu 12.04
• php version: 5.3.10-1ubuntu3.8
• joomla! 3.2.1

Results:

Admin login after installation -ok
New user created in FE - ok
New user created in BE - ok
Password changed in BE - ok
Password resetting FE - ok

Passwords looks like "05c9e83394fad8c1ab8baadb765162c9:BnRrQ5piy8HR48xMs2IhFOOr6EIr2fQV"

I tested also and for me all is good !

Merged. Now that the broken API is fixed, let's focus on the other TODO items that have come out of these discussions. Thanks to everyone for assisting with testing and code review.

I have created another PR that gives enhanced security on the passwords by implementing (PHPass)[http://www.openwall.com/phpass/].

#2656

I had originally implemented crypt-sha256 (since it was @ircmaxell's second-best solution) but was (sadly) reminded by @mbabker that we still need to support 5.3.1, and crypt-sha256 was added in 5.3.2. So I updated the PR again to use Anthony's 3rd best solution, which was implementing PHPass.

I know you all did a lot of testing here already, but would you mind one more round so that we aren't falling back to low security for the remainder of the 3.x series? Thanks.

Are we happy to upgrade requirements to 5.3.2. I think the problem that we
had was the number of people on 5.3.3 and that's still fine if we upgrade
requirements to 5.3.2?

Thanks for your work Don! Will try and test later

On Tuesday, December 10, 2013, Don Gilbert wrote:

I have created another PR that gives enhanced security on the passwords by
implementing (PHPass)[http://www.openwall.com/phpass/]. #2656#2656

I had originally implemented crypt-sha256 (since it was @ircmaxellhttps://github.com/ircmaxell's
second-best solution) but was (sadly) reminded by @mbabkerhttps://github.com/mbabkerthat we still need to support 5.3.1, and
crypt-sha256 was added in 5.3.2. So I updated the PR again to use
Anthony's 3rd best solution, which was implementing PHPass.

I know you all did a lot of testing here already, but would you mind one
more round so that we aren't falling back to low security for the remainder
of the 3.x series? Thanks.

—
Reply to this email directly or view it on GitHub#2589 (comment)
.

Are we happy to upgrade requirements to 5.3.2.

No, can't upgrade minimum at all, even to 5.3.2, although I would love it, because it would reduce our dependencies on 3rd party libraries.

As far as I remember, 5.3.0 up to 5.3.3 had a bug in the Late Static Binding implementation (correct me if I'm wrong). I'm also convinced that Joomla! RAD won't run on this kind of ancient PHP versions for this reason and we do use Joomla! RAD in our Control Panel. Have we ever actually tested Joomla! 3.2 on PHP 5.3.1 or are we just making a wild guess about our minimum version requirements?

5.3.1 is our documented minimum as decided last summer (don't remember where those discussions occurred at the moment).

I'm not questioning what's documented, I'm questioning whether it reflects reality. We can document that it runs on a tin can full of sardines, but if nobody tests whether it does run on a tin can full of sardines we are just documenting a wild guess. My question is: has anyone ever tested Joomla! 3.2.0 against PHP 5.3.1? Not just guess, but test, like install, use and make sure it actually does work without blowing up. The reason I am asking is because I've not seen PHP 5.3.x less than 5.3.3 in the last 18 months in the wild. So maybe this entire "can we raise min req to 5.3.2" is a moot point because a. we might not actually be shipping software running on PHP 5.3.1 and b. we might not have enough users with servers running PHP 5.3.1 to justify a degradation in security. The 5.3.1 figure has come from the Platform. Now the Platform is no more, we have modified it in 3.1.x and 3.2.x, yet we still use that figure without questioning it.

So, I am asking again: has anyone actually tested that Joomla! 3.2.0 runs on PHP 5.3.1?

Answering the question, the answer is 99% likely to be a no.

On Tue, Dec 10, 2013 at 9:05 AM, Nicholas K. Dionysopoulos <
notifications@github.com> wrote:

I'm not questioning what's documented, I'm questioning whether it reflects
reality. We can document that it runs on a tin can full of sardines, but if
nobody tests whether it does run on a tin can full of sardines we are
just documenting a wild guess. My question is: has anyone ever testedJoomla! 3.2.0 against PHP 5.3.1? Not just guess, but test, like install,
use and make sure it actually does work without blowing up. The reason I am
asking is because I've not seen PHP 5.3.x less than 5.3.3 in the last 18
months in the wild. So maybe this entire "can we raise min req to 5.3.2" is
a moot point because a. we might not actually be shipping software running
on PHP 5.3.1 and b. we might not have enough users with servers running PHP
5.3.1 to justify a degradation in security. The 5.3.1 figure has come from
the Platform. Now the Platform is no more, we have modified it in 3.1.x and
3.2.x, yet we still use that figure without questioning it.

So, I am asking again: has anyone actually tested that Joomla! 3.2.0
runs on PHP 5.3.1?

—
Reply to this email directly or view it on GitHub#2589 (comment)
.

At least nobody raised an issue on JoomlaCode that it breaks on 5.3.1. That means either nobody cares or it works.
I'm testing on 5.3.3 which is the lowest I have available.

Exactly - which is why I think we can rise to 5.3.2 minimum safely - will
still support the reasonably large number of people on 5.3.3 but we can
support sha256 now

On 10 December 2013 15:14, Thomas Hunziker notifications@github.com wrote:

At least nobody raised an issue on JoomlaCode that it breaks on 5.3.1.
That means either nobody cares or it works.
I'm testing on 5.3.3 which is the lowest I have available.

—
Reply to this email directly or view it on GitHub#2589 (comment)
.

OK, I'll take it up to myself to test with PHP 5.3.1. FYI, I found out that XAMPP 1.7.3 did indeed ship with PHP 5.3.1. Now I'll just have to find a way to install it on a machine and test Joomla! 3.2...

Thanks @nikosdion. I was looking for installing 5.3.1 locally, but it seems all those resources are gone now. I was also looking for a vagrant box setup with 5.3.1 but have so far come up empty.

If you have access to windows then wampserver still has php 5.3.1 available

localhost: Unable to start Joomla 3.2 on wamp php 5.3.1 (apache 2.2.9).
Reverting to php 5.4.3 (apache 2.4.2) with same joomla install - it works
fine again.

Should have added - this is the browser error page I received on php 5.3.1:

"Error displaying the error page: Application Instantiation Error"

I couldn't find 5.3.1, but I did test on 5.3.2, and it works as far as I can tell.

Thanks Hils!

@Hils Your test is a red herring. What actually happened is that WAMPserver's PHP 5.3.1 has some issues connecting to the database server using hostname localhost instead of 127.0.0.1 (i.e. trying to connect via socket instead of over TCP/IP).

I did some testing with PHP 5.3.1 and 5.3.13, the only versions I could find for WAMPserver. I discovered some interesting issues:

• Joomla! 3.2.0 comes with the strong passwords enabled by default
• You cannot log in to the site's back-end when strong passwords are enabled. You can, however, log in to the front-end
• I switched to PHP 5.3.13 and turned off strong passwords. I logged out and back in, my password wasn't converted to salted MD5. Grrrr.... I had to edit my user account and save my password again to convert it to MD5.
• Switched back to PHP 5.3.1. Now that my password was salted MD5 I could log in to the back-end and front-end without a problem.
• I observed no problems with regards to the Joomla! RAD Framework. I was wrong, FOF does run on PHP 5.3.1. I stand corrected.

Takeaway: Joomla! 3.2.0 is already NOT running on PHP 5.3.1. However, nobody ever said anything in the forums, well over 1 month after its release. As a result it is safe to assume that nobody actually uses it with PHP 5.3.1. As a result there seems to be no reason not to bump the min req to PHP 5.3.2, allowing us to provide a better password hashing fallback. Therefore I propose to raise the minimum requirement to PHP 5.3.2 and change our documentation to reflect this.

Thanks for that info Nicholas. My wamp was set up by Nic Savov specifically
for testing Joomla & both those php versions had worked previously with 3.1

• ah well! Cheers :)

Joomla! 3.2.0 is already NOT running on PHP 5.3.1.

Given all the issues related to "strong passwords", I'm not that sure it's specifially related to 5.3.1. 3.2.0 is probably just broken on anything lesser than 5.3.10.

I observed no problems with regards to the Joomla! RAD Framework. I was wrong, FOF does run on PHP 5.3.1. I stand corrected.

You should know better than to doubt your code

At the risk of being the fly in the ointment my local server is PHP 5.3.1. The live server is 5.3.27.
Just before taking the local installation live, I upgraded to J3.2 and could not log in. When I did manage to get in (by rebooting the server) I disabled "use strong passwords" and everything worked.
Now I am contemplating whether to upgrade XAMPP to version 1.8.0 which uses PHP 5.4.4. And set the optional PHP level to 5.4 on the live server. Seems this will be necessary from this discussion.

It would be a very wise decision.

@rgmears - Def update both your dev and live servers. PHP5.3 is not recommended by PHP, and is actually end-of-life, although security releases are still being produced (5.3.28 is the latest 5.3 release, and recommended if you can't move to 5.4 or 5.5).

Please note that the PHP 5.3 series will enter an end of life cycle and receive only critical fixes as of March 2013. All users of PHP are encouraged to upgrade to PHP 5.4.

Although 5.4 is stable and supported for bug fixes and security, it is actually considered 'legacy' because 5.5 has been released!

5.4.23 was released earlier this month, and is the stable version you should use for 5.4 (5.5.7 was also released and is considered the current stable version).

It is always recommended to update to the latest version in the branch you are using, as these contain the latest bug fixes and security updates.

Thanks Hannes and Chris.

In case anyone is interested old versions of XAMPP can be found here: http://www.oldapps.com/xampp.php?old_xampp=46&ModPagespeed=noscript