Proposal to change minimum required PHP version to 5.3.10 for Joomla 3.2.1+

[Beat]

Following a long discussion on https://github.com/joomla/joomla-cms/pull/2555 , proposal has been made to change our minimum required PHP version  to 5.3.10 for Joomla 3.2.1+ for multiple security reasons.

Ubunutu 12.04 (latest LTS) has 5.3.10, and both CentOS and Debian have newer stable releases available, normally with newer PHP versions too.

Michael asked to bring that question on this list. Done! :-)

Thoughts ?
Objections ?
Comments ?
Feedbacks ?

[Michael Babker]

FWIW, this isn't something that hasn't been decided (or deeply discussed) by PLT yet.  But there are some of us with opinions (mine in that thread).  There are going to be reasons for and against change, this is why I'd like to see the discussion on it before deciding.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

--
- Michael

Please pardon any errors, this message was sent from my iPhone.

[Daniele Rosario]

Beware that anyone on Debian 6 has 5.3.3 (and trust me, a lot of hosts still stay on that one because that's what's distributed with Debian)

I would me more for a warning about the php version being old.

Just my 2cents

Daniele Rosario

[Hannes Papenberg]

Hi,
since no one mentioned this in the thread yet:

The reason that we want to raise the requirements to PHP 5.3.10 is, that
all versions below that have serious security flaws in the area of
password hashing with bcrypt and password_hash(). This means that
passwords are not secure when processing them with those older PHP
versions. If we want to change our password format from the salted MD5
that we had up to 3.1.6, we will have to have at least PHP 5.3.10.

If you now ask "Do we want to change away from MD5 then?" Yes, we want
to. We are actually far behind on that one, since the single MD5 hash
that we did so far is not secure at all. bcrypt has been around for
quite a long time, although its usage was a bit complicated. With the
"new" functions password_hash() and password_verify(), this has been
simplified to a point that it really is not much more than one line of
code. Other projects have implemented better hashing methods years ago
(however, not as good as using bcrypt), sometimes by simply iteration
MD5 over this a few thousand times. So the answer is yes.

Making this optional is also not really a possibility here. It would
complicate the whole process immensely and especially in an area like
this, security is not optional.

So, I'm voting for the requirements change. We should however
communicate this better on joomla.org. The requirements should be near
the download links. Right now I had to visit at least 5 seperate pages
to find them. ;-)

Hannes

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

[Mark Dexter]

It sounds like we should make this change. Since 3.x is still an STS release, I don't see a problem with it. If we don't already, we should make it very clear that people running STS releases are expected to be able to keep up with current versions of the software stack. If you can't do this, you should stay with the LTS release imo. Mark

[infograf768]

FYI, stats from http://blog.pascal-martin.fr/
Pour PHP 5.3 :

• 5.3.0 : 2,087 — 0.09%
• 5.3.1 : 2,626 — 0.11%
• 5.3.2 : 46,730 — 2.02%
• 5.3.3 : 238,690 — 10.32%
• 5.3.4 : 2,301 — 0.10%
• 5.3.5 : 14,398 — 0.62%
• 5.3.6 : 23,788 — 1.03%
• 5.3.7 : 542 — 0.02%
• 5.3.8 : 39,915 — 1.73%
• 5.3.9 : 6,371 — 0.28%
• 5.3.10 : 167,133 — 7.22%
• 5.3.11 : 671 — 0.03%
• 5.3.12 : 305 — 0.01%
• 5.3.13 : 29,505 — 1.28%
• 5.3.14 : 10,964 — 0.47%
• 5.3.15 : 16,500 — 0.71%
• 5.3.16 : 20,822 — 0.90%
• 5.3.17 : 16,679 — 0.72%
• 5.3.18 : 22,831 — 0.99%
• 5.3.19 : 20,143 — 0.87%
• 5.3.20 : 14,115 — 0.61%
• 5.3.21 : 84,397 — 3.65%
• 5.3.22 : 17,214 — 0.74%
• 5.3.23 : 30,510 — 1.32%
• 5.3.24 : 25,176 — 1.09%
• 5.3.25 : 31,389 — 1.36%
• 5.3.26 : 66,989 — 2.90%
• 5.3.27 : 245,825 — 10.62%
  
  JM
  

[Bakual]

While I fully understand the wish to raise the requirements, I think we are at a point in the release cycle where this isn't possible anymore.

Yes we are on a STS release, but we never said that users may end up with an unsupported version and being unable to update due to raised requirements. On the contrary we especially recommend the 3.x series for new sites and we promised it will be an easy update path to the upcoming LTS version 3.5.

Imagine someone running Joomla 3.2.0 on a productive site with PHP 5.3.3. If we are now going to raise the requirements, he will be stuck on an unsupported version of Joomla which may miss on important security fixes. I think this will be a much higher risk for him than having an outdated "unsecure" password storing algorythm.

Yes, he should have updated his PHP version months ago, but that doesn't allow us to basically add more potential security holes to his system without an option to fix them.

An of course, raising the requirements on a patch release (3.2.1) is against every understanding of release managements in itself, let alone semver. Affected users will just not understand that move.

If we want to do that, we can talk about raising it for a 3.3.0 release and announce it prominently and well ahead of time (maybe using a postinstall message in 3.2.1 with a deadline), so users can prepare for it and ask/switch their hoster in advance.

You can't surprise them from behind and leave them with a vulnerable Joomla.

Personally, I think we should just "swallow the toad" (as we say in german) and code around this issue. Probably by disabling the option to use "strong passwords" for users with PHP < 5.3.10 and have those users use the old password mechanism like it was in 3.1.5.

[kisswebdesign]

From those numbers 16.32% (377,448) are using 3.5.9 or lower.

Thats more than I thought would be on such outdated versions.

I still think that security trumps everything, and the minimum supported version should be raised.

Yes, there will be pain. However, all it takes is one high profile password leak from a site running Joomla and bang goes the party - especially as we are discussing this in public (as it should be), any cursory search will show that the weakness was known about but nothing was done. That kind of publicity is something nobody needs. Clients (and potential clients) read the news, and getting new Joomla work after such a public fail would be hard - not to mention people that will move from Joomla to another CMS.

It hasn't happened yet, and maybe it never will, but I really don't want to take the risk.

As for semver, I don't think we adhere to that strictly at the moment - although we should - so for a serious security issue we can break semver rules again.

I've no objection to doing it in a 3.2.1 or as a 3.3 release, as long as it is sooner rather than later.

The other option is to shelve the entire 3.x release as is, change to 4.0 as of this change and tell eveyone to move of the 3.x tree. 4.0 becomes the secure STS release, with a higher php requirement (even push for 5.4 rather than a release that is already in its end of life cycle). We could then merge in the GSOC stuff for 4.1 or 4.2, and begin strict following of semver.

That would be a brave and scary thing to do, but I think it is worth considering, we can break b/c moving to 4.0 - and admit that 3.x had some problems that we have fixes for. State that we are bravely shelving the 3.x tree because it does not meet our minimum security requirements. It may be easier from a PR / Marketing POV to 'sell' that than it is to sell the 3.2.x breaks b/c even though we said it wouldn't.

In this 4.0 scenario, the 4.0 release is actually the 3.2.1 that is planned. The existing 4.0 in the plans simply becomes 5.0 (just the number changes, not the code/direction/etc).

Having a clean break could help with the GSOC inclusions, new features added in an x.2.1 or x.3 release is not normal for Joomla and an exception is being made just for the GSOC stuff (which I also think is the right thing to do).

Anyway, my 0.02 Bitcoins, now I'm going to run and hide.

Chris.

[Hannes Papenberg]

Please keep in mind that 3.2.0 is out there and 3.2.0 automatically
updates your passwords to bcrypt. So we already have a bunch of people
out there that have bcrypt hashes instead of MD5 and we can't simply
revert everything to 3.1.6.

Hannes

[Hannes Papenberg]

Ok, after much consideration, I'm officially asking the Joomla project
hereby to pull the Joomla 3.2.0 version in order to stop more damage
from happening.

What is the current situation?
1. The bcrypt feature was implemented. Due to bugs in PHP, this feature
is not possible with our current requirements. It was implemented anyway.
2. People that updated to 3.2.0, can't downgrade again, because their
password hashes have already been changed to bcrypt.
3. We can't raise the PHP requirements since about 15% of our users wont
be able to run Joomla anymore. Those users also can't downgrade, see 2.
They are effectively stuck on 3.2.0 until their hosts upgrade their server.
4. We also can't make this optional, since sites don't always stay on
the same server. What might work on the system of the site developer,
might not work on the customers server.

Right now this means that everybody who updated to 3.2.0 is f&%ked.
Considering that >230,000 copies have already been downloaded, I thereby
ask the project to remove that download again.

Thank you,

Hannes

Am 20.11.2013 17:31, schrieb Bakual:

[Bakual]

I don't know enough about encryption that I could comment on this.

I just know that a lot of people are still stuck on PHP < 5.3.10. If we suddenly raise the minimum requirement in a patch release without a warning beforehand we will make a lot more users angry. If there is any way to code around the issue, even if it needs clunky workaround code, then I think we should do that. Otherwise users will end up with outdated Joomla versions on top of outdated PHP versions which probably is even worse than what they currently have.

I would still prefer adding a warning postinstall message stating that the next minor release (3.3 or 3.5 or whatever it is) will raise this requirement. Then we can remove the workarounds again. And postinstall messages are actually the only way to get the attention of the users. It has also the advantage that we can check the version and only show the warning if needed. I don't think a blog post on joomla.org or similar will be enough.

Another approach could be that we release a 3.3.0 with this bcrypt fixes applied and maintain a 3.2.x branch where only security fixes are applied. Similar to the 3.1.6 release we did when 3.2.0 was released. This way we don't leave users with vulnerable systems (besides maybe the bcrypt issue) and still can fix it properly. But it would mean that we released 3.2 and 3.3 in a very short time.

[Michael Babker]

I agree with not raising the tech requirement in a maintenance release given the arguments in this thread.  So it seems we can come to a consensus on doing it for the next minor series.  For that, I highly suggest we get code in the update component (2.5 and 3.2) to check PHP versions pre-upgrade.  Whether it be a solution Nicholas D. already has elsewhere, the JCompatibility code that was started earlier in the year... We just need something.  We also don't want to update sites only to show a PHP version unsupported message.

So, now we have to deal with the workaround piece.  As with many, I don't quite understand the encryption code myself enough to offer sound advice, but I'm open to arguments on the approach to take and why.

Lastly, and this is my personal opinion, but throw the concept of timed releases out for the next few months.  Let's get a 3.2.1 out that's working and fixes the mistakes we made then after the new year we can look at 3.3 or whatever longer term plan we come up with.  It won't be the easiest thing to explain, but we'll have time to pool the resources and get an effective plan in place so that when the change is introduced into the wild, we have everything we need to answer the 5 W's at least.

[Bakual]

+1

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

[Hannes Papenberg]

I think the only way to solve this in a matter that will work for our
users is to revert this whole bcrypt move and instead move back to MD5,
adding code back in that will verify bcrypt hashes and then migrate them
back to MD5. We can't have this feature without PHP 5.3.10, not even as
an option, and we can't raise the requirements.

Hannes

> > an email to joomla-dev-cm...@googlegroups.com <javascript:>.

> > To post to this group, send an email to

> joomla-...@googlegroups.com <javascript:>.

> > Visit this group at
> http://groups.google.com/group/joomla-dev-cms

> <http://groups.google.com/group/joomla-dev-cms>.

> > For more options, visit https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.
>

[brian teeman]

After a quarter of a million (whooppee) downloads and upgrades of 3.2 from joomlacode alone and not include direct hosting panel installs pulling the release is not a practical solution. 

[Thomas J]

There are no good answers to this issue, only solutions which have varying degrees of a negative impact. I would start with the following postulates:

1.  The current MD5 implementation is no longer a viable security approach.
2.  bcrypt is a good solid security approach going forward.
3.  PHP < 5.3.10 contains a serious security flaw that renders the bcrypt approach insecure.
4.  Joomla 3.2.0 has already been released and is being actively used. It is not feasible to pull it at this point.
5.  The LTS version of Joomla 3.x (which will be Joomla 3.5) needs to have a good security architecture to ensure its continued adoption.

I believe that if Joomla 3.5 continues Joomla's support for weak security approaches, a number of companies will decide to move away from Joomla. Joomla already has (I believe undeserved) a rep as being weaker in security than Drupal.

I would note that the new Drupal 8 (which is currently in alpha) has a minimum PHP requirement of 5.4, so commercial hosts which support both new versions of Joomla and Drupal will need to upgrade their PHP in any event.

I believe that we need to commit that at a minimum, Joomla 3.5 (LTS) will require a minimum of PHP 5.3.10. The only question we face is what do we do between Joomla 3.2.1 and Joomla 3.5. Our two choices are:

     a. Do an interim release (like a 3.3) which bumps up the PHP requirement
     b. Put a big notice on the 3.2.1 release (and any future 3.2.x releases) about this issue if people are using a PHP version earlier than 5.3.10.

I'm not sure that we need to do a 3.3, as long as we let everyone know that 3.5 will require a minimum of 5.3.10, and we make it clear to everyone about the security vulnerability.

[Andrew Eddie]

My 2c.

I think it's acceptable for us to drop support for some platforms as a last resort when presented with serious security or stability issues. In other words, support for PHP < 5.3.10 ends at 3.2.0 effective immediately.

The only think I'd vote against is breaking API b/c.

Regards,

Andrew Eddie

[Beat]

On Wednesday, November 20, 2013 11:40:11 PM UTC+1, Thomas J wrote:

I'm not sure that we need to do a 3.3, as long as we let everyone know that 3.5 will require a minimum of 5.3.10, and we make it clear to everyone about the security vulnerability.

Just to clarify: The hashing itself is not an exploitable vulnerability by itself, as it can only be taken advantage of if there is a separate real exploitable vulnerability (e.g. a SQL injection vulnerability on a host without proper security measures, e.g. mod_security SQL-injection-patterns filtering rules) allowing access to the database.

Even with bcrypt, provided you have enough computing power and time, and the password is of usual length, a password can be brute-force guessed. It's just a matter of budget and time and lenght of password (and algorithm). This table gives you the cost (to be divided by 2 every 18 months and as this table is 18 months old, you can divide the shown cost by 2 for current costs) to brute-force a password within 1 year:
http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html

Best Regards,
Beat
http://www.joomlapolis.com/

[Beat]

Ok, thanks all for the feedbacks :-)

Based on the feedbacks, and as Michael said, we should not raise PHP minimum requirement for Joomla 3.2.1.

I will now propose to use a battle-proven alternative fall-back PHP 5.3.1-compatible implementation using the similarly-secure NIST-certified PBKDF2 instead of the current plain salted-SHA256 fallback on the github thread discussing the salting, so that we solve the fallback implementation for PHP < 5.3.10. :-)

Thanks all for the feedbacks and very useful information provided here!

Best Regards,
Beat
http://www.joomlapolis.com/

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cms+unsubscribe@googlegroups.com.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

[Hannes Papenberg]

I disagree with that decision that you are making here. I don't think we
are at the end of this discussion. Because simply switching to another
hash wont solve a thing here, especially if we actually want to do good
practice and use the stuff that PHP is providing us, which is the
password_hash() function. And that all is besides the fact that I don't
trust a "NIST-approved, NSA-weakened" hash as far as I can throw it
("it" being the NSA). I also don't want to take all this up again in
time for 4.0 either!

What we can agree on is, that we will have to revert the implementation
of bcrypt that went into 3.2.0 and start over with that one.

Hannes

Am 21.11.2013 08:54, schrieb Beat:
> Ok, thanks all for the feedbacks :-)
>
> Based on the feedbacks, and as Michael said, we should not raise PHP

> minimum *requirement* for Joomla 3.2.1.

> <http://joomla.org> or similar will be enough.

> <http://groups.google.com/group/joomla-dev-cms>.

> > For more options, visit
> https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.

>
> --
> You received this message because you are subscribed to the
> Google Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to joomla-dev-cm...@googlegroups.com.
> To post to this group, send an email to
> joomla-...@googlegroups.com.
> Visit this group at
> http://groups.google.com/group/joomla-dev-cms

> <http://groups.google.com/group/joomla-dev-cms>.

> For more options, visit
> https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.

>
>
>
> --
> - Michael
>
> Please pardon any errors, this message was sent from my iPhone.
>

[Beat]

On Thursday, November 21, 2013 9:06:56 AM UTC+1, Hannes Papenberg wrote:

What we can agree on is, that we will have to revert the implementation
of bcrypt that went into 3.2.0 and start over with that one.
 

I need to make clear that the bcrypt security in 3.2.0 is OK, from an algorythm used security point of view.

It's only the SHA256-fallback for PHP <5.3.9 that is not a great implementation regarding the hashing in the table. But it is NOT a vulnerability by itself as long as the rest of the site and host/hosting is secure.

Regarding your comment about NIST and NSA (yes, both are cooperating US entities, that's why I mentioned it):

I was commenting on PBKDF2's security from an algoythmic point of view.

It is to be noted that nowadays (at least as I saw in latest meetings), both algorithms have the best reputation for password storage in crypto-experts circles.

Regarding the NSA insight suppositions, only the future will tell the truth, but I wouldn't be betting that PBKDF2 has more flaws than bcrypt.

Actually the brute-force CPU-power needed to guess a bcrypt2-hashed password is less than for bcrypt. However bcrypt is probably less influenced by NSA than PBKDF2's internal SHA algorithm, which was developed by RSA with the help of the NSA.

But let's keep the algorythms discussion on the github, as it's duplicate work to reply to both conversations.

Regarding the PHP minimum requirement, it's clear that there is no big issues raising up to 5.3.3, but there is an issue for raising to 5.3.10, according to latest stats and feedback. And that's something we can not ignore.

The ball is now in the github algorythms+implementation discussion, and if we don't find a good technical solution there, we will certainly come back here.

[Valentin Despa]

From my point of view +1 for this, security should always prevail.

From PHP 5.3.1 to 5.3.10 from what I've seen there is only one backwards incompatible change. http://php.net/releases/5_3_3.php. Not to mention that from 5.3.1 to 5.3.27 there are lots of security issues addressed.

We have the Post - Installation messages, the next minor release can prepare the users for an upgrade.

Is there the issue that the hosts will refuse to upgrade and leave the users stuck with 3.2? An opinion from a hoster would be a nice thing to this discussion.

Valentin Despa

[Hannes Papenberg]

And that is where I disagree. The bcrypt implementation in 5.3.7 and
below is not secure and that is the whole reason that we are talking
about this. Otherwise we wouldn't have the stupid idea of a fallback in
the first place. A fallback also doesn't help you if your site moves
between hosts, as I described earlier. We are not talking about
something that is optional here. Its not like "Ok, we can't write to the
filesystem directly, so lets use the FTP layer" or "My server does not
allow server-to-server communication, so I have to upgrade manually".
This is "Either it works or it doesn't." Because if it doesn't work on
this system, but we already have bcrypt hashes in our DB because of it
being on another system, we are screwed. You CAN'T rehash those
passwords on the new system unless you authenticated first. If that
authentication does not work, because the hashing function is broken in
YOUR version of PHP, you can't rehash those passwords. That means that
everyone who was unfortunate enough, now needs to use the password reset
function to obtain a new password. There is no way that we can implement
a "fallback" here, unless you guarantee that a site will never switch
servers or a stupid hoster never downgrades its PHP version because of a
bad backup or something.

We have to agree on the lowest common denominator, which is given by our
system requirements and either we raise those or we move back to MD5,
waiting for 4.0 to raise the system requirements then and implementing
bcrypt at that point.

Hannes

Am 21.11.2013 10:11, schrieb Beat:
>
>
> On Thursday, November 21, 2013 9:06:56 AM UTC+1, Hannes Papenberg wrote:
>
> What we can agree on is, that we will have to revert the
> implementation
> of bcrypt that went into 3.2.0 and start over with that one.
>
>
>

> I need to make clear that *the bcrypt ***security* in 3.2.0 is OK,
> from an algorythm used security point of view*.

>
> It's only the SHA256-fallback for PHP <5.3.9 that is not a great

> implementation regarding the hashing in the table. But *it is NOT a
> vulnerability by itself* as long as the rest of the site and

[Matias Griese]

After talking to Elin I have come into conclusion that it's possible to implement bcrypt safely even on the broken PHP versions (with the old hashing $2a$).

It will still raise minimum PHP version into 5.3.3, but that would only affect 2% of the users, which I find reasonable as that would allow strong passwords for all users by using a single implementation -- albeit two variations of it. Also most of those 5.3.3 installations would already have fixed version of the algorithm, which means that most of the users would be using strongest algorithm anyway.

Here is the bug that caused the vulnerability:

"Versions of jBCrypt before 0.3 suffered from a bug related to character encoding that substantially reduced the entropy of hashed passwords containing non US-ASCII characters. An incorrect encoding step transparently replaced such characters by '?' prior to hashing. In the worst case of a password consisting solely of non-US-ASCII characters, this would cause its hash to be equivalent to all other such passwords of the same length."

The fix is very simple. On the affected systems we can keep most of the entropy just by filtering the highest bit ($char & 0x7f and perhaps dealing with 0x00) for all letters inside the password. That would make the passwords containing non-ascii characters almost as strong as in the fixed versions. This special case would be easy to detect even after upgrading the PHP as they have different prefix. Also most passwords would not be affected at all, because of most of the (western) people do not use special characters in their passwords.

This also rises another question: do you allow people to use UTF8 in their passwords? If you don't, there's no vulnerability in here...

So the question is: is it possible to raise minimum version requirement from PHP 5.3.1 to 5.3.3, which is the lowest supported PHP version in all major distributions?

[Beat]

Thanks Matias!

Could you please paste this reply (if possible with citation-reference URLs) on the github thread https://github.com/joomla/joomla-cms/pull/2555 for discussing the algorithms in a single place ?

Happy to continue that discussion there. :-)

Once we have done the discussion there, we can come back here regarding PHP version discussion. :-)

Best Regards,
Beat
http://www.joomlapolis.com/

[Donald Gilbert]

The minimum required PHP version is set at the beginning of a major series, and cannot be changed for that series. This is not something explicitly stated, and is something that I'm going to work in to the new development strategy.

I realize there may be times when there is absolutely no other way to solve an issue, but it's still not something that can be taken lightly. I would say we need unanimous support from the community and the leadership teams in order to make such a change.

[Mark Dexter]

Maybe I'm missing something here, but here is my understanding of the situation. 

1. There is no problem for folks running 5.3.10 and higher. They can use the latest/greatest password hashing without issues.

2. For those running 5.3.1 to 5.3.9, imo we just need a solution that is at least as good as MD5 -- and better if possible. After all, MD5 was ALL we had until 3.2.0. I don't see why we need to raise the minimum PHP version to force folks to use improved hashing. If someone needs the best security, they need to get a current PHP version. If they want to run with older PHP and can accept the older, less secure hashing, that's their choice. We can do our best to encourage everyone to upgrade their PHP, but there may well be good reasons for folks to stay on an older PHP version in specific situations.

Obviously, if we can improve the security for some or all older supported PHP versions, that's great and we should do it. But as long as 3.2.x works on PHP 5.3.1 as well as (or better than) it ever did, what's the problem? Mark

On Thu, Nov 21, 2013 at 6:49 AM, Donald Gilbert <dilber...@gmail.com> wrote:

The minimum required PHP version is set at the beginning of a major series, and cannot be changed for that series. This is not something explicitly stated, and is something that I'm going to work in to the new development strategy.

I realize there may be times when there is absolutely no other way to solve an issue, but it's still not something that can be taken lightly. I would say we need unanimous support from the community and the leadership teams in order to make such a change.

--

[George Wilson]

See my post on github as I don't want to repeat myself twice. But for the TL/DR I'm now in favour of upgrading to 5.3.10 minimum but with the caveat of using JCompatability so there is a flow for users between 5.3.1 and 5.3.10

I'd also add mark there have been significant issues for those on 5.3.1-5.3.7 implementing the non-bcrypt approach

Kind Regards,

George

[Bakual]

Agree fully with Mark

Those which run on PHP < 5.3.10 don't bother about their security anyway. Otherwise they would have updated PHP long ago. :)

Let's look for a solution which works with MD5 for users on < 5.3.10 and implement a clean bcrypt for users on 5.3.10 and higher.

The only real problem as I understand it is how to convert users back to MD5 if their password is already converted to bcrypt. Worst case being that they have to reset their password.

[Radek Suski]

Ok, so here are some my thoughts: I am a hosting provider. Seriously. I manage 4 root servers by myself. The thing is that I don't have the experience of people managing real hosting for clients. I'm managing those servers for my own needs. As I am a lazy person I'm probably a really bad hosting provider. My software, inclusive the PHP version is mostly outdated. The most important issue here that I'm not a huge exception just those other providers offering their server for real clients. The last time I updated PHP was because Joomla! 3 requirements.

You're debating about loosing some potential users. If we would proceed this politic we would still have to worry about PHP4. Believe me, there are server providers providing it for clients. 

People don't care much about hosting. They want Joomla!. The see that this is an awesome software. They want have it. They're going to install it at some crapy server and it won't work. We have already a preflight checker. Let's increase the requirements and put a link to a good article why we can't support PHP < 5.3.10.

We are doing it with SobiPro (XSLT is a huge issue) and from my experience in that case people are going to the hosting company and those companies including the needed functionality in most cases.

I can't imagine it would be much different in case of Joomla!. Let's try to educate our users and simply try to explain to them why we are requiring higher PHP version. Security is a huge issue and most people would understand it as people are very careful now. 

[George Wilson]

I disagree. It's the linux users who get PHP 5.3 in their lamp stack on an LTS version (see http://www.sasaprolic.com/2013/02/list-of-current-php-version-in-major.html). Debian is not an insignificant number of users.

Also many just can't upgrade. My cheap rubbish host is sitting on PHP 5.3.22 and however much I moan at them they refuse to upgrade.

Kind Regards,

George

[Radek Suski]

On Thursday, 21 November 2013 21:44:50 UTC+1, George Wilson wrote:

I disagree. It's the linux users who get PHP 5.3 in their lam

I don;t think it would be a huge issue to talk to Debian's people. Not to mention that if a hosting provider is using the regular stack then it is not a real hosting provider. 

 

Also many just can't upgrade. My cheap rubbish host is sitting on PHP 5.3.22 and however much I moan at them they refuse to upgrade.

Well, then I can give you the advice I'm (successfully) giving our clients; search for a real hosting company. 

[George Wilson]

Actually debian applied PART of the bcrypt stuff - but in a odd way that means we still can't really take advantage of it. Also it's the 5.3.10 fix that was mentioned on GitHub that's in some ways more of a concern. But I'm definitely open to exploring it if we can :)

If someone will charge me less than a 10 pounds for hosting with cpanel with 2 domains sure I'll swap to a better host. Until that day arrives ......... :P 

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/GRlyfBfbMpU/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to joomla-dev-cm...@googlegroups.com.

[Radek Suski]

10 pounds a year or month?

Forget the question, if you value the price over the security and outdated software ... well don't get me wrong but http://sobi.it/1g ;)

[Tuum]

My 2cents

+1 for increasing minimum PHP version to 5.3.10 - security should always be more important than sticking to minimum requirements stated at the beginning of a new Joomla series. We have a very good reason to explain to people why this change is necessary.

I'm quite concerned about the talk of dropping the Joomla 3.x series and going straight to 4.x. This would create lots of confusion for the average user, like when we skipped 2.0. Do you really want to spend the next 12 months explaining version numbers again? We've been putting out the message that the 2.5 series is the long term stable which most people should use, and only early adopters should use the short term 3.x releases. Early adopters are more willing to go through a little bit of pain than the average user. Increasing minimum PHP version of current series is a much better outcome and screwing up the series numbering.

regards

Tim

[kisswebdesign]

£10 per month, or year?

Bandwidth required? Disc space?

Just curious, as I maintain a small hosting environment for clients.

[Mathew Lenning]

First I'm going say I object to this 10000% this isn't an issue of security. This is a matter of principals. The Joomla! Project has promised every single person that choose to use Joomla! For their sites, that B/C would be protected in the 3.x series. Now this is harder said than done, so of course there have been issues, but what you are proposing is intentionally breaking B/C just for the hell of it. If the new encryption is a problem pull it and put it back in ver. 4.0.

Why? Because the project didn't promise two stage security. It promised B/C in the 3.x series. Not keeping your promises is the first stage of the end.

Think about it. In what industry do you invest anything in someone that you know cannot keep their word? Internet or otherwise.

[Andrew Eddie]

On 22 November 2013 10:32, Mathew Lenning <mathew....@gmail.com> wrote:
> Think about it. In what industry do you invest anything in someone that you know cannot keep their word? Internet or otherwise.

There are two concepts here. b/c of the API and b/c of the supported
platforms. The first, b/c of the API within a minor version is
non-negotiable. You cannot break API b/c without going to CMS 4.0 for
example.

The other aspect is raising the minimum requirements within a minor
series. Providing you can prevent upgrading, that is acceptable.
Regrettably, that is impossible so it falls back to assessing the
risk. If the only way to keep the majority of the 3.x sites safe is to
bump the PHP requirements, I say go for it. However, if there are code
workarounds that leave us no worse off than we are now, but better if
you are on PHP 5.3.10+, that is the most prudent course of action and
that avenue should be exhausted first. Unfortunately I've not had time
to study all the code arguments well enough to give an engineering
opinion (and my former post was probably a bit hasty).

I also agree with a "soft" increase of the installation checks to PHP
5.3.10, giving a warning for less than that version.

Regards,
Andrew Eddie

[Beat]

Many technical solutions have have been proposed in the discussions here https://github.com/joomla/joomla-cms/pull/2555 .

An oversimplified summary (read thread for Lots of details):
One of the solutions requires PHP 5.3.10 ("no compromises" hashed passwords one - standard bcrypt hashes only - so the easiest implementation-wise, which triggered the question in this thread), several do not require increasing the minimum required PHP version while preserving a fall-back level of security from status-quo one up to very reasonable hashing levels using similar iterative and salted password hashings as latest WordPress or Drupal.

From a functional point of view, and with reasonable password hashing security levels and B/C, I do not see any reasons to change minimum PHP requirements.

From a highest security point of view, we should always require latest PHP, database and webserver versions, but it's not something that is not practical and that we should change during a release cycle, taking in account that Linux distros currently don't upgrade PHP versions once a distribution is released but take a lot of time to backport all major security fixes of newer PHP versions into older versions.

The discussion is not yet done, but after lots of reading and some thoughts, I recommend that we make the extra-effort on the development side instead of breaking B/C compatibility for a non-neglectible part of our users.

[Andrew Eddie]

On 22 November 2013 11:21, Beat <bea...@gmail.com> wrote:
> Many technical solutions have have been proposed in the discussions here
> https://github.com/joomla/joomla-cms/pull/2555 .

Ok - for me the problem is we have too many solutions and I find it
difficult to understand the problem in the code we are trying to
solve.

Am I right in saying that the password hash and salt we currently
store is not secure enough, or is it that it could be better?

Regards,
Andrew Eddie

[Beat]

On Friday, November 22, 2013 2:37:06 AM UTC+1, Andrew Eddie wrote:

Am I right in saying that the password hash and salt we currently
store is not secure enough, or is it that it could be better?

Regards,
Andrew Eddie

Correct!

It is only a matter of making the time and cost to guess the password out of a hashed password high enough again for a given time, and to use a PHP function that will be upgraded by the PHP team gradually as time passes to be kept state-of-the-art. It was state-of-the-art security when it got implemented back in Joomla 1.0.15 and 1.5, but so many years later it's not anymore. It is not an exploitable vulnerability by itself but if a hacker gains access to the database using another vulnerability it is a problem that needed to be fixed.

That's why bcrypt got chosen for Joomla 3.2.0 in the first place. Unfortunately a bug in PHP 5.3.0 affecting the bcrypt-hashing of 8-bit bytes got fixed only in PHP 5.3.7. And while at changing requirements, a major security vulnerability of PHP got fixed in PHP 5.3.10 (and backported by all major linux distributions into their older versions), which was the reasons I raise the question here for PHP 5.3.10 here while at it and not for 5.3.7. ;-)


"Unrelated":

A bit tired of these periodic endless minimum PHP versions discussions, I have decided to move one step forward and raised a proposal and a call for a volunteer to resolve the old PHP versions issue in Linux distrirbutions here: https://groups.google.com/forum/#!topic/joomla-dev-cms/DG1PfODkVHU

[Andrew Eddie]

On 22 November 2013 11:51, Beat <bea...@gmail.com> wrote:
>> Am I right in saying that the password hash and salt we currently
>> store is not secure enough, or is it that it could be better?
>

> Correct!

> That's why bcrypt got chosen for Joomla 3.2.0 in the first place.
> Unfortunately a bug in PHP 5.3.0 affecting the bcrypt-hashing of 8-bit bytes
> got fixed only in PHP 5.3.7. And while at changing requirements, a major
> security vulnerability of PHP got fixed in PHP 5.3.10 (and backported by all
> major linux distributions into their older versions), which was the reasons
> I raise the question here for PHP 5.3.10 here while at it and not for 5.3.7.
> ;-)

Thanks. Can you give me links to the lines of code where we are using
the bcrypt library API?

Regards,
Andrew Eddie

[Andrew Eddie]

Nevermind, I believe I've found it.

https://github.com/joomla/joomla-cms/blob/master/libraries/joomla/user/helper.php#L351

Why wouldn't you just do something like this, in pseudo-code:

if (PHP < 5.3.10) set $encryption = "the next best option";

just before you go into the switch, assuming the other options are
better than bcrypt on PHP < 5.3.10. If the other options are indeed
worse, why would we do anything at all. Case closed.

I'm obviously missing something because it can't be that simple right?

Regards,
Andrew Eddie

[Beat]

Yes, "it is that simple" :D Actually as it's not implemented very simply (and that is one of the issues discussed), which explains that you didn't find it upfront: The "if" that you are proposing is already here:
https://github.com/joomla/joomla-cms/blob/master/libraries/joomla/user/helper.php#L459
and is already in Joomla 3.2. ;-)

The only thing is that the implemented fall-back in Joomla 3.2.0 is buggy (and thus some sites on PHP <5.3.7 fail logins, and password-reset is buggy too, so lock-outs happen) and all of that needs to be fixed, and if you put your head into that code from the PR1745 you will see that it could have been quite simpler and easier to security-review. Another issue is that the new fall-back of 3.2.0 is only slightly better security-wise than the 1.0.15-3.1.5 salted-md5 because it's missing a few thousand iterations (that we could have done with the salted md5 too).

So as you see, nothing really complicated. Just lots of solutions and lots of valid opinions.

Best Regards,
Beat
http://www.joomlapolis.com/

[Mark Dexter]

I agree. Old PHP users are no worse off than they were before. The only thing that has changed is the perception that MD5, once thought to be OK, is now thought to be NOT OK. But the reality is that, if we go back to MD5 for users with old PHP, they are no worse off than they were before, except by comparison with PHP 5.3.10 users who now can benefit from improved security.

So I agree that this solution is simple and the best one I can see. If needed, I think we could release 3.2.1 now with the fallback being the old MD5 for old PHP folks. Then, if/when available, provide an improved option for old PHP users in a later release. (Obviously, we could provide the improved version for 3.2.1 if it was available very soon. But I don't think we should delay to wait for it.)

--

[Andrew Eddie]

On 22 November 2013 12:28, Beat <bea...@gmail.com> wrote:
> The only thing is that the implemented fall-back in Joomla 3.2.0 is buggy
> (and thus some sites on PHP <5.3.7 fail logins, and password-reset is buggy
> too, so lock-outs happen)

Where are the related issue reports for those?

> and all of that needs to be fixed, and if you put
> your head into that code from the PR1745 you will see that it could have
> been quite simpler and easier to security-review.

With respect Beat, that's a 129 file PR. I think I'm not understanding
your English well but I'm left with the feeling that "do nothing" is
the best course of action. I still don't understand "why" which is a
concern because I suspect most of the conversation here is not about
solving the actual problem (I include myself).

Regards,
Andrew Eddie

[Andrew Eddie]

On 22 November 2013 12:32, Mark Dexter <dexter...@gmail.com> wrote:
> So I agree that this solution is simple and the best one I can see. If
> needed, I think we could release 3.2.1 now with the fallback being the old
> MD5 for old PHP folks. Then, if/when available, provide an improved option
> for old PHP users in a later release. (Obviously, we could provide the
> improved version for 3.2.1 if it was available very soon. But I don't think
> we should delay to wait for it.)

Is MD5 better than broken Bcrypt?

Regards,
Andrew Eddie

[George Wilson]

The issues is there are various issues with low versions of PHP where users can't be created, pw resets don't work etc. I don't have time to delve through the tracker at the moment but they do exist if you go looking.

There is also the issue of people upgrading not having a pw explicitly set. Which probably should happen - rather than selecting a parameter lets hit everyone on >5.3.10 straight onto bcrypt....

Kind Regards,

George

[Beat]

On Friday, November 22, 2013 3:36:12 AM UTC+1, Andrew Eddie wrote:

Is MD5 better than broken Bcrypt?

Depends how broken it is :-D : If you use only 8 bit chars, salted-MD5 is better :-D

Here is the details:

http://us3.php.net/security/crypt_blowfish.php
And here the source:
http://lxr.php.net/xref/PHP_TRUNK/ext/standard/crypt_blowfish.c#555
the changelog:
http://lxr.php.net/history/PHP_TRUNK/ext/standard/crypt_blowfish.c
and the 8th-bit bugfix:
http://lxr.php.net/diff/PHP_TRUNK/ext/standard/crypt_blowfish.c?r2=%2FPHP_TRUNK%2Fext%2Fstandard%2Fcrypt_blowfish.c%4003315d9625dc87515f1dfbf1cc7d53c4451b5ec9&r1=%2FPHP_TRUNK%2Fext%2Fstandard%2Fcrypt_blowfish.c%40b158091ed6f725e443b9a49fe7212596bd1c218b

From the  report, it is broken for 8-bit bytes with high-bit at 1: In that case the whole byte gets replaced by "?" for the password hash (and then when you upgrade your PHP, you can't login anymore and must reset).

So in my opinion, if we don't use the 8th bit it's not broken (but would require a non-standard use), but please review the links above yourself, as it's not trivial and Anthony warned about working around that bug in his reply below.

3 solutions to workaround this have been proposed here:
https://github.com/joomla/joomla-cms/pull/2555#issuecomment-28975436
and here:
 https://github.com/joomla/joomla-cms/pull/2555#issuecomment-28977306
and just below

But it has its own pitfalls, and complexity that Security Experts hate understandably:
https://github.com/joomla/joomla-cms/pull/2555#issuecomment-28984191
(complexity increases the risk of security-affecting bugs)

All of that will be a perfect bedtime read :-D Falling asleep guaranteed :-D

Gnite :-)

[Beat]

Oh, and once you read it all, then also read very carefully this advice from Anthony:
https://github.com/joomla/joomla-cms/pull/2555#issuecomment-28984191

I recommend to follow his strong advice to not use bcrypt before the final fix of PHP 5.3.7, as there seem to be other undisclosed good reasons to not use it, but to use iterated SHA-256 instead (similarly to what WordPress and Drupal latest releases do) as he recommends in case we want to support PHP <5.3.7 with a reasonable level of hashing.

Nite!

[Andrew Eddie]

On 22 November 2013 12:52, Beat <bea...@gmail.com> wrote:
>> Is MD5 better than broken Bcrypt?
> Depends how broken it is :-D : If you use only 8 bit chars, salted-MD5 is
> better :-D

Ok, whatever. Sounds like salted-MD5 is going to be no worse that
using a new padlock on a very rusty door.

Next question. Is anyone on PHP >= 5.3.10 having problems?

George, I think we are going to need all the tracker links otherwise
we really are flying blind. Hannes, you should have them in your PR :P

Regards,
Andrew Eddie

[Andrew Eddie]

On 22 November 2013 12:59, Beat <bea...@gmail.com> wrote:
> I recommend to follow his strong advice to not use bcrypt before the final
> fix of PHP 5.3.7,

I'd opt for "will not fix". We have the right to say if you are on
5.3.7 we won't fix the bug. That does not compromise any b/c promise.
Thinking further, there is nothing wrong with preventing the
Installation app to refuse to install on anything less than 5.3.10.
Don't deliberately break sites < 5.3.10 but make it increasingly
harder for Joomla to be used on them.

Regards,
Andrew Eddie

[Radek Suski]

What has backward compatibility to do with PHP requirements?  

[Andrew Eddie]

On 22 November 2013 15:46, Radek Suski <suski...@gmail.com> wrote:
> What has backward compatibility to do with PHP requirements?

If your minimum requirements are 5.2.0 for example, and you merge code
with using PHP API that is available only from PHP 5.3.10, you
introduce a backward incompatibility. Anyone on a host that is less
than 5.3.10 upgrades and the site breaks. This would not be a problem
if we could prevent people from upgrading, but we can't.

Regards,
Andrew Eddie

[Radek Suski]

I don't think you can call it a backward compatibility. Especially in case of an STS version.

It just increased requirements in a kind of development version anyway.

Why we can't check it and prevent upgrade? As I understand Joomla! update is done via the extension manager. You can check the requirements and break the upgrade process. 

[Mathew Lenning]

@Suski,

We'll since version 3.1 was compatible with servers running the minimum required PHP version which was decided at the beginning of 3.x series, every site build with those minimum requirements will break when upgrading. 

Yes for developers this isn't a "B/C" issue, but tell that to the poor guy just trying to use Joomla! to ..... I don't know maybe manage his content. 

I agree with Andrews proposal. Make upgrading difficult to do for older versions of PHP, that way the non programmer population don't end up with a broken site and they'll put pressure on their hosts to update their servers. 

Win-win-win

P.S. Thank you for being wonderful

http://babel-university.com

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/GRlyfBfbMpU/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to joomla-dev-cm...@googlegroups.com.

[Andrew Eddie]

On 22 November 2013 15:58, Radek Suski <suski...@gmail.com> wrote:
> I don't think you can call it a backward compatibility. Especially in case
> of an STS version.
> It just increased requirements in a kind of development version anyway.

If you upgrade and your site breaks, it's a compatibility issue
between patch and minor releases. You are allowed to break stuff only
between major releases.

> Why we can't check it and prevent upgrade?

Because the code doesn't exist to check it in the current version.
You'd have to put that in 3.2.1 and then block PHP < 5.3.10 upgrading
to 3.2.2 (I would argue bump it to 3.3 in that case). However, you'd
have to make sure everyone on an older version of the CMS had to
upgrade to 3.2.1 before upgrading again (otherwise they miss the
check). I'm not sure if that's possible.

> As I understand Joomla! update is
> done via the extension manager. You can check the requirements and break the
> upgrade process.

I don't believe the code for requirements checking made it into 3.2.

Regards,
Andrew Eddie

[Michael Babker]

On Fri, Nov 22, 2013 at 12:05 AM, Andrew Eddie <mamb...@gmail.com> wrote:

However, you'd have to make sure everyone on an older version of the CMS had to

upgrade to 3.2.1 before upgrading again (otherwise they miss the
check). I'm not sure if that's possible.

We are able to target releases quite well actually in the 3 series.  Remember the fiasco with 3.1.1 to 3.1.4 and those who got the early update to 3.1.2 needing to only be able to update to the pseudo-3.1.3 package before getting back on the update path?  Same type of XML definitions can be used.

[Andrew Eddie]

On 22 November 2013 16:19, Michael Babker <michael...@gmail.com> wrote:
> We are able to target releases quite well actually in the 3 series.
> Remember the fiasco with 3.1.1 to 3.1.4 and those who got the early update
> to 3.1.2 needing to only be able to update to the pseudo-3.1.3 package
> before getting back on the update path? Same type of XML definitions can be
> used.

Ah ok. Well, at least there's a good Plan B up our sleeve. But until
we see the actual bug reports as a part of this discussion, I'm not
sure we can move too far forward.

Regards,
Andrew Eddie

[Bakual]

That would be my preferred way as well. We have an option called "Strong Passwords" which enables this whole thing from my understanding. Why can't we simply make this option conditional based on PHP version (using a custom formfield)? If it's lower than 5.3.10 we just make that option readonly and disabled with a message stating that the user needs to update the PHP version to use this feature.

That would be all that is needed and all the fallback code could be thrown away. If the option is disabled, use md5 as with Joomla 3.1.5 and if enabled use bcrypt.

Are there any issues with that approach?

We have to find a way to convert existing bcrypt passwords back to md5 for those below 5.3.10. Worst case here would be that the users request a new password if we can't do an automated migration.

And just because it was mentioned: No, I don't think we need to take into account the sitebuilder who tests the site on his local PHP 5.5 machine and then moves it to the crappy server with PHP 5.3.3. Or a hoster who downgrades his PHP version for whatever reason. There is no promise given that downgrading a PHP version will work. Any sitebuilder, developer and hoster should know better than to do such things.

[Herman Peeren]

I want to add some perspective to the discussion about security: we are mainly talking about a "second line" of defence: once some malicious person has the user-data from your database, we want to prevent them to get the original passwords from the users. The first line of defence, to prevent people from getting into your system at all or preventing them from getting data from your database, is not influenced by these security measures like using bcrypt. It is not making your site more or less secure in the sense of the first line of defence: an MD5 hashed password is never brute force reverse engineered via the login over the line; that is too slow.

I don't say the second line of defence is unimportant. I just say, that the emphasis for security must be on the first line: preventing SQL-injection, XSS, very weak and easy to guess passwords, etc. The second line is more from the pessimistic (or realistic) point of view that the first line can always be passed and we can then better mitigate the damage.


On Wednesday, 20 November 2013 15:42:12 UTC+1, Beat wrote:

Following a long discussion on https://github.com/joomla/joomla-cms/pull/2555 , proposal has been made to change our minimum required PHP version  to 5.3.10 for Joomla 3.2.1+ for multiple security reasons.

Ubunutu 12.04 (latest LTS) has 5.3.10, and both CentOS and Debian have newer stable releases available, normally with newer PHP versions too.

Michael asked to bring that question on this list. Done! :-)

Thoughts ?
Objections ?
Comments ?
Feedbacks ?

[brian teeman]

@radek and others. Please don't forget that users who install joomla with their hosts control panel scripts never see the joomla installer and its related system checks.

Thanks to Siteground I've been able to raise this issue with softaculous and they're looking into changing their scripts but other hosts eg rochen use their own installer scripts that also bypass the joomla installer and its update checks

[Andrew Eddie]

On 22 November 2013 18:13, brian teeman <joom...@googlemail.com> wrote:
> @radek and others. Please don't forget that users who install joomla with their hosts control panel scripts never see the joomla installer and its related system checks.

Well, Plan B was a good idea while it lasted.

Regards,
Andrew Eddie

[Radek Suski]

Why we can't simply add something like:

class JoomlaInstallerScript

{

public function __construct()

{

if ( version_compare(PHP_VERSION, '5.4.0', '<') ) {  

JFactory::getApplication()->redirect('index.php', 'Sorry buddy, no chance on this old server');

}

}

 
....

into installer script.

@Brian: I understand but if a hosting provider provide old PHP version and then they are adding a software into their installer which requires higher version than they provide then how it is our problem?

Regards,

Radek

[brian teeman]

@radek I am just introducing awareness of that scenario and NOT commenting on the pros/cons

[Matias Griese]

I've taken a deep look into the code and to me the issue isn't really whether to raise minimum PHP requirement or to change the API. The issue is that you cannot implement both the old and new way with the current API, at least not without breaking backwards compatibility in all possible and very creative ways.

* The reason why the 'weak' passwords are broken is that the API doesn't work anymore in the way it used to work and the salt was removed from JUser class for the new users!
* The reason why the new passwords might stop (or at least have extra salt) working is because of the salt is added (using the old way) in JUser class for the existing users!

This also means that everyone who are bypassing JUser to store the new passwords or who use their own authentication mechanism are facing the same issue. New API is different to the old one and it currently throws all the responsibility to the 3rd party developers. Many of them have already fixed their code to support this backwards incompatible change in J!3.2.0. But because of the implementation is broken, they need to change it again -- no matter how Joomla will fix it.

Here's an example where J!3.2 is forcing TapaTalk to reimplement their password checks. See the public discussion in here:
https://support.tapatalk.com/threads/error-2222-on-joomla-3-2-kunena-3-0-3-tapatalk-1-1-3.21593/

I'm currently having a private email discussion with the TapaTalk team and they were totally lost how the passwords are supposed to be checked with all the special cases and version checks. I just told them to do nothing and wait for J!3.2.1 which hopefully solves the problem.

So we now have backwards incompatible API that is very hard for 3rd party to understand. In addition to that there are few pull requests proposing to break the remaining API compatibility between !2.5 and J!3.1 by moving the hashing from the client code to the JCrypt itself. After that move the API will not make any sense to me anymore as it was originally designed to be used in very different way. On the other hand the current version of the API pushes the responsibility to the 3rd party to make sure that their implementation works reliably with both Joomla! 2.5 and 3.2 and additionally makes them responsible on making sure whether to use hash or not.

In short:

1) JCrypt API changes between J!3.1 and J!3.2 are causing extensions to make 2 different implementations depending on Joomla version.
2) With the current API changes it's not clear how the API should be used -- it also makes 3rd party developer responsive of doing it right.
3) There's no way to make JCrypt backwards compatible without dropping the new and secure hashes.
- Right now 3rd party developer needs to know whether to add hash or not
- If hash is added inside the class, all the old code breaks even more than now
4) All of this already happened in Joomla core
- there are several bugs affecting both bcrypt and sha256 in here: https://github.com/joomla/joomla-cms/pull/2358/files
- to me it looks like hash is added for existing users but not for new users
- I'm 150% sure that everyone else will make the all the same mistakes if they are forced to use it

So we are now in the situation where JCrypt API was changed unintentionally because of hash already belongs to the new passwords. There's no way to remove that hash and use the old way, which is how the old implementation worked. The hash needs to be dealed either inside the class or in the user code. First solution breaks the API even worse and the second moves all the complexity to the user code, forcing them to implement all the logic to handle not only API change between versions but also all the different hashing methods which Joomla supports.

> The first, b/c of the API within a minor version is non-negotiable.

Sorry, but API already changed. We can either

1) keep it like it is and throw the responsibility of figuring out how to handle 3 different types of passwords to the 3rd party developers
2) break the API again and have database full of broken passwords because of some 3rd party dev didn't know how to deal with the API change (J! 2.5 vs J!3.2.0 vs J!3.2.1)
3) revert JCrypt back to what it was and implement a new API next to it, which is well documented and easy to use

- Matias

[Andrew Eddie]

Thanks for the analysis Matias. 

On Friday, 22 November 2013, Matias Griese wrote:

> The first, b/c of the API within a minor version is non-negotiable.

Sorry, but API already changed. We can either

1) keep it like it is and throw the responsibility of figuring out how to handle 3 different types of passwords to the 3rd party developers
2) break the API again and have database full of broken passwords because of some 3rd party dev didn't know how to deal with the API change (J! 2.5 vs J!3.2.0 vs J!3.2.1)
3) revert JCrypt back to what it was and implement a new API next to it, which is well documented and easy to use

Since we've broken b/c, we need to restore it and go back to the drawing board. My initial reaction is to go with a full revert #3. 

Regards

Andrew Eddie 

--

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - free tutorials and videos on Joomla development

[Bakual]

Aye. If it's true that BC was broken between 3.1.5 and 3.2.0 (which I believe from what I read so far), then reverting that and restoring BC is our prime goal now.

And from there we can implement a new way which is BC where we offer bcrypt support for PHP 5.3.10 and higher.

[Hannes Papenberg]

My proposal is still to revert to the before-3.2.0 state and improve the
whole situation by adding 2 new methods JUserhelper::hashPassword() and
JUserHelper::verifyPassword(), the first one taking the password to hash
and returning the string that should go into the DB, the second one
taking the current hash, the password and an optional user ID to check
the password against the hash and potentially update the hash to the new
algorithm used in that Joomla version. Up to Joomla 3.5, we use MD5 and
in 4.0, we can simply switch the code at this one point in our system
and not at a 10 other points.

Hannes

P.S.: I know that JUserHelper is most likely not the absolute correct
place to put it and that such a function should not update the hash, but
it would be a very convenient and easy interface.

[Beat]

On Friday, November 22, 2013 2:37:58 PM UTC+1, Bakual wrote:

Aye. If it's true that BC was broken between 3.1.5 and 3.2.0 (which I believe from what I read so far), then reverting that and restoring BC is our prime goal now.

And from there we can implement a new way which is BC where we offer bcrypt support for PHP 5.3.10 and higher.

Yes, that's true.

Sounds like a good plan for passwords in JUserHelper (or in a new class JPasswordsHasher like Anthony proposed. Then for the part using that, we can leave the old 3.1.5 code untouched as is, and add a new authorization plugin that implements the new methods. That way is the least risky one in terms of changing old-security-audited-proven not-very-nice-but-much-less-buggy code.

Then all we need to do is draft another plan for the remember-me fix (which can also be implemented much simpler than what has been done).

Both things could be done in parallel if we have 2 volunteers with a week of free time.

Advantages:
- simpler code
- less risks of bugs
- backwards compatible
- much easier to backport to Joomla 2.5
- possible to have it as a plugin that uses the jupgrader (similar to the Install from Web one, which successfully released a first follow-on release since 3.2.0), so that in case of future security upgrades needed, admins could upgrade it easy without having to upgrade whole Joomla or wait for next joomla release.
- 1 week of productive work instead of 1 week of frustrating work trying to fix an architecturaly broken code.

Disadvantages:
- it's not an evolution from 3.2.0, but one from 3.1.5.
- may take 2 weeks instead of a few days to just fix the main bugs (but with a better chance to fix them all than now).

Did someone try to revert the  PR1745 to check if it is reversible from master as other fixes have been made to it already ? sp we do not explore something irrealistic. it is not a small one...

[Thomas J]

@Herman   +1

In that context, over the last several years, certain programming practices have been identified as insecure. See:

http://cwe.mitre.org/top25/

and

http://www.sans.org/top25-software-errors/

Does Joomla have a security review team? Is there even a Joomla STIG that is available? (STIG = Security Technical Implementation Guide)

From a corporate point of view (which may not be relevant for some of you), Joomla has a reputation for not caring as much about security as Drupal. I don't believe that is correct, but that is certainly the perception out there. I know of a number of companies that have chosen not to use Joomla because of its perceived weakness in the area of security.

I realize that requiring PHP 5.3.10 or greater is inconvenient, but security is very often inconvenient. I have a really hard time believing that because a minimum PHP version was sent a long time ago for Joomla 3.x, that it can't be revisited. Times change, security threats change, and security of websites is even greater now than before, particularly as many websites are being hacked and password files are being obtained.

I believe it is not sufficient to say that well, for people choosing to use a PHP less than 5.3.10, they will just be more insecure. People need to be brought into a more secure approach, even if they're kicking and screaming. It is simply not fair to the users of their website to allow poor security implementations if the situation can be somewhat improved by requiring PHP 5.3.10 or greater. The stakeholders of Joomla include the users of websites built with Joomla.

And finally, let me reiterate what I said before. Drupal 8, which will be coming out next year around the same time as Joomla 3.5 (LTS), requires a minimum of PHP 5.4.0. Commercial host providers that support both Joomla and Drupal will need to upgrade their PHP in any event.

[Michael Babker]

So reading over the threads, have we reached a general consensus on a plan of action yet?  As I noted at https://github.com/joomla/joomla-cms/pull/2555#issuecomment-29121709 we have a narrowing window of opportunity to work with, so I'd like to see everyone who will be working together on fixing this issue get on the same page and help commit the time and resources necessary to get things sorted.

[Bakual]

Imho, there is not even a consensus what needs to be fixed effectively. To my knowledge there are only two issues which need to be fixed asap:

* The buggy bcrypt implementation in PHP < 5.3.10 which leaves users unable to log in into Joomla

* The backward compatibility break in the API between 3.1.5 and 3.2.0.

Anything other?

Am Samstag, 23. November 2013 02:14:10 UTC+1 schrieb Michael Babker:

[Hannes Papenberg]

Bcrypt is extensively used for the remember me feature. I don't have an
overview how that is implemented, because it is done in such a complex way.

I'd like to hear a "yea" or "nay" for my proposal to revert the commit
that introduced the whole bcrypt thing and then implement 2 methods in
JUserHelper, named hashPassword() and verifyPassword() that do the two
relevant things, where verifyPassword() would update the hash to
whatever we agree on in the end. The implementation of those two methods
can still be decided. getCryptedPassword() and getSalt() would be
deprecated. We might consider naming those 2 methods passwordHash() and
passwordVerify() in order to stay closer to the PHP implementation,
although I like the first proposal better.

If we had those 2 methods in place, we can still decide if we wanna drop
back to MD5, want bcrypt or SHA512 or whatever we find suitable. But in
that case we only need to change this in these 2 methods and not in 5-10
files all over the place.

So, yea or nay for that proposal?

Hannes

Am 23.11.2013 11:08, schrieb Bakual:
> Imho, there is not even a consensus what needs to be fixed
> effectively. To my knowledge there are only two issues which need to
> be fixed asap:
> * The buggy bcrypt implementation in PHP < 5.3.10 which leaves users
> unable to log in into Joomla
> * The backward compatibility break in the API between 3.1.5 and 3.2.0.
>
> Anything other?
>
> Am Samstag, 23. November 2013 02:14:10 UTC+1 schrieb Michael Babker:
>
> So reading over the threads, have we reached a general consensus
> on a plan of action yet? As I noted at
> https://github.com/joomla/joomla-cms/pull/2555#issuecomment-29121709

> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjoomla%2Fjoomla-cms%2Fpull%2F2555%23issuecomment-29121709&sa=D&sntz=1&usg=AFQjCNEPN3rO7LCH4oz5ZphHGlUBlh5R9w>

> we have a narrowing window of opportunity to work with, so I'd
> like to see everyone who will be working together on fixing this
> issue get on the same page and help commit the time and resources
> necessary to get things sorted.
>

[Matias Griese]

Using BCrypt in remember me shouldn't be an issue as it should never trigger the broken behavior of BCrypt, at least not with valid inputs. I've not seen the latest implementation of the remember me, but at some point the only reason to use BCrypt was to protect the items inside the DB. This might have changed, though.

My answer is Nay for the revert (for now) and Yea for the new methods, see the pull request for explanation. :)

PS. looks like Drupal had a similar discussion:

https://drupal.org/node/1800122

[Bakual]

That's not how it usually works. You will not get a yes or no before you provided the code and successful testing is done.

Since you want to refactor a sensible security area, it will probably even need excessive testing like the *strong password* feature originally did.

Personally I doubt that a full refactoring should be done in a patch release. At least if there are other ways to fix the issue at hand.

What I would like to see is the tracker openend, issue explained, testing instructions provided and then code delivered. The tracker which is linked in your current PR seems to be already solved from what I read there.

I'm really not sure at the moment how PLT should do any educated decisions. But maybe I'm wrong and am missed something important in all this posts.

[Hannes Papenberg]

I've tried to understand the remember me feature and I looked through
all of this for quite some time and I couldn't make any sense of it. It
seems as if some new table(s) were added for this feature and bcrypt is
used to somehow crypt some data and... Seriously, if I have serious
issues understanding how this feature works, what should some outside
developer say who wants to do a security review? The way it is done now,
it is definitely way to complicated.

Hannes

[Hannes Papenberg]

First of all: "excessive testing like the *strong password* feature
originall did"? Did you LOOK at the code? The original commits didn't
even implement this in the password reset feature, not to speak of the
whole host of other issues that are there.

Second of all: I DID provide code. Code that fixed more stuff than it
broke. However also code that was still broken. I tried fixing the
current implementation and worked on that quite some time and quite
frankly, I couldn't make sense of it, so I didn't even commit it to my
repo at all. We've been discussing this for a week now and we are hardly
any further towards a solution than at the beginning. I asked to get a
yes or no from the powers in charge in order to not do the work 2, 3 or
4 times over. In the end, someone has to decide which way to go.

Regarding the full refactoring: The original PR that introduced all
this, has 129 changed files and I simply can't wrap my head around all
of this. There are changes in there that seem totally unrelated to both
the remember me feature and the bcrypt passwords. (Which also brings up
the question why both those features had to be handled in one PR.)

Regarding the tracker item that was the basis of all of this: Yes, that
first PR that was mentioned in there fixes the one single issue that was
mentioned at the beginning. But it is only a bandaid on a much more
broken system. Not looking at the missing implementation in the password
reset feature. Not looking at the unnecessarily truncated passwords. Not
looking at the unnecessarily introduced coupling of a CMS plugin into
the Joomla framework. Not even looking at the broken bcrypt
implementation in <5.3.10, we still have a highly insecure "fallback" in
there with SHA256. If you want, I can open tracker items for each and
everyone of these issues. But that doesn't help us one bit and would in
the end only result in a work therapy for all of us.

So I'm going to do the following: I'm going to open a new branch in my
repo, revert the API changes that were made in that original bcrypt
commit, introduce those 2 new methods that we've been talking about and
implement them properly in our code. Then I'm going to open a new PR and
let you guys fight it out what to do.

Hannes

> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjoomla%2Fjoomla-cms%2Fpull%2F2555%23issuecomment-29121709&sa=D&sntz=1&usg=AFQjCNEPN3rO7LCH4oz5ZphHGlUBlh5R9w

> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjoomla%2Fjoomla-cms%2Fpull%2F2555%23issuecomment-29121709&sa=D&sntz=1&usg=AFQjCNEPN3rO7LCH4oz5ZphHGlUBlh5R9w>>
>
> > we have a narrowing window of opportunity to work with, so I'd
> > like to see everyone who will be working together on fixing
> this
> > issue get on the same page and help commit the time and
> resources
> > necessary to get things sorted.
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Joomla! CMS Development" group.
> > To unsubscribe from this group and stop receiving emails from
> it, send

> > an email to joomla-dev-cm...@googlegroups.com <javascript:>.

> > To post to this group, send an email to

> joomla-...@googlegroups.com <javascript:>.

> > Visit this group at
> http://groups.google.com/group/joomla-dev-cms

> <http://groups.google.com/group/joomla-dev-cms>.

> > For more options, visit https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.
>

[Hannes Papenberg]

Here is the new PR: https://github.com/joomla/joomla-cms/pull/2589

Hannes

[Webdongle]

Given that average Joe user was originally told that the 3 series was for experienced users only but now are told to use it if the extensions they need are available ... why introduce a feature that requires different minimum requirements ?

There will be many average Joe user that has followed the new advice about J3 series and chosen their Host on the basis of the minimum requirements. I am not knocking the efforts of the Joomla developers, far from it because they all put a lot of effort in.  It is just that sometimes for various reasons things appear to be confused.  imho extending the length of support for LTS versions and advising that only experienced users install STS versions would achieve 2 things

1. Prevent problems for the average Joe user
   
2. Give developers more time to iron out 'teething problems' that the excellent new features are having.
   

[Thomas J]

I honestly think we are all looking at this from the wrong perspective. All the discussion has been about what are hosts going to provide, what does the average Joe user expect now of Joomla 3.x, are we being fair to them, etc. From my perspective, we are focused on the wrong people.

Our greatest obligation is to the public who will be visiting and using websites built with Joomla. If security is so irrelevant to us, then why don't we just store the passwords in a plain text file without any protection. After all, that would be the easiest thing to do, and would be suitable for all types of hosts.

We OWE IT to users of Joomla websites to provide them with the strongest protection we can for their passwords. Anything would be a disservice to them and a failure of what Joomla should really be about. This isn't about about what the average Joe user developer now expects of Joomla 3.x, nor about how difficult it may be to get hosting companies to move up to PHP 5.3.10 or greater. This is about saying that Joomla 3.x is not only a great CMS, but also provides strong security (in this case, at least for your passwords).

Listen, I get that this is inconvenient. Security is always inconvenient. It is our obligation to the users of websites built with Joomla to do this, to simply require that the PHP version be 5.3.10 or greater.

And, I'll say if for the third time, Drupal 8 requires PHP 5.4 or greater. The hosts will be moving to PHP 5.4 over the course of next year anyway just to support Drupal 8.

[Mathew Lenning]

@Thomas,

I think you bring up a good point end-user security is very important, but tell me this. After we have alienated all of the average Joe user developers and they decide that Joomla! cannot be trusted, how many of your "Public" will have a chance to use a website built with Joomla? 

This isn't a matter of security, because the old method wasn't "insecure", It was just less secure (right?). The real debate is whether or not Joomla as a community can keep its promises to the people who have placed their trust in the project.

my 2 cents

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-cms/GRlyfBfbMpU/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

--
As always Thank you for everything

[Bakual]

Raising the PHP requirement will not magically add security for those users. In fact it would leave the buggy 3.2.0 installations in their current state without any possible fix.

We still HAVE to fix it for those sites, thus raising the minimum requirement doesn't solve anything.

Also we are already trying to provide best security for them. For installations on PHP > 5.3.7 that is. We can only do so much. The hoster has to do his part as well :)

[Amy Stephen]

On Sunday, November 24, 2013 3:45:15 PM UTC-6, Thomas J wrote:

Our greatest obligation is to the public who will be visiting and using websites built with Joomla.

+1 If you don't care about them, no one else will.

[MonkeyT]

After reading through the thread, I strongly agree with almost every point Bakual has made.

I am sole developer in a small, hosting company who writes extensions for Joomla solely and specifically for our use.  As such, I am not in Joomla code every day, though I spend a LOT of time there.  My point is that we, like most small business, researched platforms before we jumped aboard Joomla, and one of the main characteristics we relied upon for that decision was stability - not just that a clean installation of the software runs well, but that any code we wrote for it would remain usable for the life of the current major version release.   We need to be able to create software that will run without modification for several years at a time, and we need a User API that is documented and stable for the life of any specific version of the software.  

We not only need time to research, develop, test and deploy our components/plugins/modules, we need to market them, sell them, train our staff and customers to use them and rely upon them, and hopefully run them without incident for at least a year or two to recoup the money and man-hours we put into researching and writing them.  As such, we RELY upon a stable API.  This doesn't mean that new features can't be added, but it is CRUCIAL that NOTHING be removed from it (without a truly catastrophic justification - "slightly less secure" is NOT catastrophic).  We cannot afford to spend time patching and re-writing code because of changes to a development platform that was promoted as being stable. For users who do not have development resources available to them, longevity of installed code is an advantage, not a drawback.

If you let us know about a security issue due to hosting conditions, we'll adapt our hosting conditions.  If you need to make changes behind the scenes, make them invisible to people using the API.  Don't change the interfaces we chose (years ago, before the current version) to build upon.  DO NOT break backward compatibility in minor releases.  If there needs to be a new feature, a new process or procedure and you can't seamlessly re-use the same methods and calls that are already documented, ADD it to the API and remove the insecure process and classes from the next major release - then TELL US ABOUT IT.  DO NOT break the API, even if the old code is insecure.  Document the hell out of the change.  Publicize the hell out of change.  Add warning messages and alerts when an obsolete or dangerous process is used.  NAG existing hosts and admins incessantly through the Admin interface and tools.  Educate your users and provide your better solution - DO NOT break code we have been told would be available to us for the life of the release.

If users like me are forced to jump back into code out of routine, we lose every single advantage Joomla has provided to us, which makes it far less likely we would recommend staying with the software for another version. Provide us a better answer which we can implement in our existing schedule and we'll feel much better about it.

I read these lists so I can prepare for what's coming, and I'm happy to say that you all have generally been coming to conclusions I agree with.  I hope you'll do so here.

Tim Stiles

[Hannes Papenberg]

Hi Tim,
"slightly less secure" means in this context the difference between 4
seconds (salted MD5, which we have now) and years (bcrypt, what we tried
to get, but failed) to get the plaintext password from the hash that is
stored in the db.

I understand your intentions and I agree that broken b/c in the API is
mostly a no-go. On the other hand, you are writing about "years" and
that is a pretty long time. In terms of software, I'd say you can rely
on a "year", but not "years". But that is just me being a pedantic.
Anyway, these changes in the API also come up because of missing tests
and it would benefit us all, if we would all chip in and write some
unittests, etc. The development of Joomla is done by a remarkably small
number of people.

Hannes

Am 25.11.2013 17:49, schrieb MonkeyT:
> After reading through the thread, I strongly agree with almost every
> point Bakual has made.
>
> I am sole developer in a small, hosting company who writes extensions
> for Joomla solely and specifically for our use. As such, I am not in
> Joomla code every day, though I spend a LOT of time there. My point
> is that we, like most small business, researched platforms before we
> jumped aboard Joomla, and one of the main characteristics we relied
> upon for that decision was stability - not just that a clean
> installation of the software runs well, but that any code we wrote for
> it would remain usable for the life of the current major version
> release. We need to be able to create software that will run without
> modification for several years at a time, and we need a User API that
> is documented and stable for the life of any specific version of the
> software.
>

> *We not only need time to research, develop, test and deploy our

> components/plugins/modules, we need to market them, sell them, train
> our staff and customers to use them and rely upon them, and hopefully
> run them without incident for at least a year or two to recoup the

> money and man-hours we put into researching and writing them.* As

> such, we RELY upon a stable API. This doesn't mean that new features
> can't be added, but it is CRUCIAL that NOTHING be removed from it
> (without a truly catastrophic justification - "slightly less secure"
> is NOT catastrophic). We cannot afford to spend time patching and
> re-writing code because of changes to a development platform that was
> promoted as being stable. For users who do not have development
> resources available to them, longevity of installed code is an
> advantage, not a drawback.
>
> If you let us know about a security issue due to hosting conditions,
> we'll adapt our hosting conditions. If you need to make changes
> behind the scenes, make them invisible to people using the API. Don't
> change the interfaces we chose (years ago, before the current version)
> to build upon. DO NOT break backward compatibility in minor releases.
> If there needs to be a new feature, a new process or procedure and
> you can't seamlessly re-use the same methods and calls that are
> already documented, ADD it to the API and remove the insecure process
> and classes from the next major release - then TELL US ABOUT IT. DO
> NOT break the API, even if the old code is insecure. Document the
> hell out of the change. Publicize the hell out of change. Add
> warning messages and alerts when an obsolete or dangerous process is
> used. NAG existing hosts and admins incessantly through the Admin

> interface and tools. *Educate your users and provide your better

> solution - DO NOT break code we have been told would be available to

> us for the life of the release.*

> --
> You received this message because you are subscribed to the Google

> Groups "Joomla! CMS Development" group.

> To unsubscribe from this group and stop receiving emails from it, send

[MonkeyT]

Good Morning, Hannes

After all the careful editing I did to make sure I said precisely what I wanted to say, I posted into the wrong thread.  That message wasn't intended to be specifically about the security fix, it was meant to be in the discussion of "changing Joomla's development strategy".

I'm not so concerned with the security issue - we already have passed the PHP version in question, and almost none of our customers rely upon Joomla membership tools.  It also appears that the likely solution to the problem will be (as I hoped) to append a correct solution to the API rather than altering existing commands.

I hoped to add some perspective as to who "the average user" is, and how important important it is to non-developers that API alterations and b/c changes be restrained to major versions and emergencies only.  Software developers (like most on this list) consider software change to be a fact of life (good or bad), but many of the decision-makers involved in selecting Joomla are not developers and see instances of this sort of instability just as a characteristic of the platform - one to be taken seriously enough to avoid the platform completely.

And as for the realistic lifespan being a year: Change is expensive, and many many many business, particularly non-internet oriented businesses like our customers,  feel no need or pressure to change their web design, features or capabilities more often than they change their letterhead.  Years without a significant revamp is not uncommon, just convincing them that any change is worthwhile is often difficult and can take a year or more ( we've barely been able to convince most to commit to regularly updated content ).  They are busy running their own companies and believe that their website should magically tick away in the background, sending them customers and clients, without any real effort or additional investment on their part.  We would love to keep them in current software (it would be better for them and would certainly help pay our bills) but they do not accept that their web site should be treated as ongoing advertising: to them, it's a print job - paid for once and put behind them.  And the longer a site lasts without demanding their attention, the better - which is just one argument of many that support for Joomla versions should be longer than 12 months.  But that's a different issue.  For us, keeping up is a vulture, for them, not having to think about it is the virtue - and they think in yearly cycles at best.

(I agree with many of the points you have made in both threads as well, BTW)

Tim Stiles

[Hannes Papenberg]

Even though I find it excruciating how long this discussion is already
running and how little we got so far, this still has to be decided and
needs to be solved for 3.2.1. So please discuss this again and either

- raise requirements to 5.3.10 and move to bcrypt or
- stick with salted MD5

Thanks,
Hannes

> <https://github.com/joomla/joomla-cms/pull/1745> to check if it is

> reversible from master as other fixes have been made to it already ?
> sp we do not explore something irrealistic. it is not a small one...
>

[Bakual]

We're past the decision part for now as raising the requirements doesn't solve the issue for existing users.

What we need at the moment is proper testing of your PR. I think we have about two (more or less good) tests at the moment? For the issue at hand, I would love to see some more testers. Especially also from 3rd parties using the API and users on old PHP versions. Otherwise we quite sure run in another problem with 3.2.1.

[Hannes Papenberg]

In that case it is set that me move back to salted MD5 and NOT use bcrypt.

Hannes

> > an email to joomla-dev-cm...@googlegroups.com <javascript:>.

> > To post to this group, send an email to

> joomla-...@googlegroups.com <javascript:>.

> > Visit this group at
> http://groups.google.com/group/joomla-dev-cms

> <http://groups.google.com/group/joomla-dev-cms>.

> > For more options, visit https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.
>

[Michael Babker]

For at least 3.2, yes.

>     > sp we do not explore something irrealistic. it is not >     > an email to joomla-dev-cm...@googlegroups.com <javascript:>.

>     > To post to this group, send an email to
>     joomla-...@googlegroups.com <javascript:>.
>     > Visit this group at
>     http://groups.google.com/group/joomla-dev-cms
>     <http://groups.google.com/group/joomla-dev-cms>.
>     > For more options, visit https://groups.google.com/groups/opt_out
>     <https://groups.google.com/groups/opt_out>.
>

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/groups/opt_out.

--
- Michael

Please pardon any errors, this message was sent from my iPhone.

[Thomas J]

If we do not increase the minimum PHP to 5.3.10 for Joomla 3.5 (LTS), it can potentially be a disaster for us. For Joomla to knowingly allow an easily hackable password security architecture for a long-term support release in these times will drive a lot of companies (mine included) to other CMSes. The difference between salted MD5 and bcrypt is very substantial.

My vote was to increase the minimum PHP to 5.3.10 for Joomla 3.2.1, but as that is not going to happen, we should be announcing at the top of our lungs that it will be increased for Joomla 3.5.

Who makes this final decision?

[Bakual]

The PLT makes the final decision based on the community.

Currently we tend to raise the minimum in the next minor release (be it 3.3 or 3.5) with a proper warning ahead of time (using joomla.org and postinstall message). But it's not decided yet.
There is also some work going on toward an optional plugin which will gather anonymous enviroment data. This would allow us to make better decisions for this kind of things.

PLT will announce the decision as soon as it's made.

Currently we really need testers for the patch proposed by Hannes (https://github.com/joomla/joomla-cms/pull/2589) so we can release 3.2.1 soon. Or if there is a better way to solve the issue, propose it.

[Thomas J]

Now that Joomla 3.2.1 has been released, is there an opportunity to revisit the PHP version (and consequently a bcrypt implementation) for Joomla 3.5? The last post by Bakual indicated that the PLT would be considering this. Has any decision been made?

[Matt Thomas]

Hello Thomas, 

No official decision has been made yet, but we're getting close. This is one of, if not the, highest priorities for us right now.

Thanks for your patience.

Best,

Matt Thomas

@betweenbrain
http://matt-thomas.me/

http://betweenbrain.com/

https://github.com/betweenbrain

On Fri, Jan 10, 2014 at 1:56 PM, Thomas J <traveli...@gmail.com> wrote:

Now that Joomla 3.2.1 has been released, is there an opportunity to revisit the PHP version (and consequently a bcrypt implementation) for Joomla 3.5? The last post by Bakual indicated that the PLT would be considering this. Has any decision been made?

--

[Thomas J]

Hi Matt,

Thank you very much for your update. If it helps with your deliberations, I thought this post by Acquia about Red Hat and the PHP version for Drupal 8 might be useful:

https://www.acquia.com/blog/will-red-hat-7-be-ready-drupal-8

Best regards.

Thomas

[Matt Thomas]

Hi Thomas,

Thanks for the link, that is helpful. I'll actually be at DrupalCamp NJ later this month, so I'll see if I can gather some insight about how that change is being handled and the impact it may have on users.

As you can imagine, one of the big challenges we face is that we are in the middle of a major release cycle, versus Drupal 8 starting the new cycle with different requirements. We need to be very careful not to leave any users stranded, while considering the issues at hand.

Thanks again for your patience and consideration.

Best,

Matt Thomas
@betweenbrain
http://matt-thomas.me/
http://betweenbrain.com/
https://github.com/betweenbrain

Sent from mobile. Please pardon any typos or brevity.

--