New hashing algorithms for Joomla

[Jase Williams]

Hi all

So as the MD5 hashing algorithm Joomla! uses is getting old and weak. I've decided to create a patch which allows admins to set a new, more secure hashing algorithm.

There is still some debate over whether users should choose the algorithm they want or whether we should just change it anyway in the background.

The current choices are (MD5, SHA-1, SHA256, SHA-512, bcrypt)

Here is the patch i created:

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8549&tracker_item_id=27381

Would love some feedback on this.

Thanks

Jason

[Nicholas K. Dionysopoulos]

I can think of at least one major problem with having a hashing algorithm automatically selected. Let's say that a user select SHA512 for his site and wants to transfer it from Server A to Server B. Server B does not have any cryptographic library installed, so it is limited to using MD5. Result: all users are lost, because their passwords are unrecoverable. This is not very difficult to happen, especially if you move between low-cost shared hosts or from live to local (have you observed that hash and mcrypt are turned OFF by default on most major AMP packages?). I know that users should know better if we document this and I know that they can work around it (except when they move from one host to another) by following instructions but, honestly, do you seriously believe that any user ever read the fine manual? Not one.

I would make this an option, not an automatic action, with a big fat warning stating that this may cause user login issues if the server configuration changes or the site is transferred to a different server. Therefore, if it breaks, the user has assumed full responsibility for his actions and will refrain from affectionate remarks of the "Joomla! sucks because it lost my users" kind ;)

Nicholas K. Dionysopoulos
Web Development & IT Services
http://www.dionysopoulos.me

http://www.AkeebaBackup.com

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/-t8BMIoIsygJ.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[brian teeman]

This plugin is a great idea although I think it is trying to solve a problem that doesn't actually exist

Even with a big fat warning I would expect most users do not predict that they will be moving hosts or that their new host would not offer the same feature that their current one does. And I'm yet to see a host that advertises, before purchase, which libraries they have installed etc

If you flag something as "more secure" then the main usergroup that will select this will be those users on the least secure cheapest hosts. ie the usergroup that is more likely to have issues and more likely to be "moving" hosts at some time in the future

[Nicholas K. Dionysopoulos]

I actually tend to agree with Brian. Unsalted MD5 is broken, thanks to rainbow tables and known attacks to the algorithm itself. However, Joomla! is using salted MD5 passwords. The fastest MD5 brute force cracking machine is Whitepixel with a throughput of roughly 31 billion iterations per second. With an 8 character password, it would take about a year before the password was successfully brute-forced. I would assume that this is enough time for someone with a hacked site to take notice of the information leak and change his password. And I'd certainly bet that an attacker won't try to brute-force the password of all user accounts on the site, unless he has thousands of years or million of dollars to waste.

Note: Please do not play the "weak password would be easy to guess" card. In this case, the hashing method would be indifferent as the attacker would try a dictionary attack and a list of possible password before trying brute force. The difference between MD5 and SHA512 would be cracking the weak password in 2 minutes or 5 minutes, i.e. so frivolous that's not even worth mentioning it.

So, the real questions are: a. why do we consider MD5 to be broken as a password hashing scheme? Maybe because some cryptologists found a way to create "equivalent" strings which result in the same MD5 hash? That's true, but it does not apply to salted passwords, unless you're so damn lucky as to find an equivalent string whose later part matches the 32 character salt string (not a cat's chance in hell). b. which problem are we trying to solve with this patch? Did anyone report a successful hack because someone cracked his password from an MD5 string (I seriously doubt it)? Or are we trying to protect an imaginary user with imaginary precious data against an imaginary adversary with infinite technology and money launching a continuous imaginary attack against him? That would make a good book or a blockbuster movie (wait, I think it is a movie!) but, honestly, I would be more worried about other, easier to exploit, attack vectors than MD5 cracking. If I were a hacker and found an SQLi vulnerability, I'd create a Super Admin account for myself, block the legitimate SA, turn off known protection extensions and log in to the victim's site. I wouldn't give a dime about cracking MD5 salted hashes ;)

Nicholas K. Dionysopoulos
Web Development & IT Services
http://www.dionysopoulos.me

http://www.AkeebaBackup.com

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

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/1wy97FhXH8UJ.

[Hannes Papenberg]

Sorry Nicholas, but I disagree here.

Yes, unsalted MD5 is broken, but stating that salted MD5 is really
secure is a wrong assumption. If you say an 8 character password can
only be hacked by brute force in a year, you are assuming that the 8
password characters are in fact from the whole range of ASCII characters
available, maybe even from all UTF8 characters. However, a password does
not have to be a weak dictionary password to be susceptible to brute
force. Most people don't mix uppercase and lowercase characters and
quite a few also don't mix numbers in there. So in worst case, you have
to search a keyspace of about 30^8 combinations, which results in
actually just about a week of calculation time on a slow computer (one
million checks per second).

Yes, the issue is the same for almost every other hashing algorithm out
there, but the big difference is, that something like bcrypt does not
allow you a million or a billion iterations per second, but just maybe a
hundred thousand and it can be even made slower than that.

Regarding your questions:
about a): MD5 is a fast hashing algorithm and has some weaknesses that
make it easier to exploit in some cases, which is why MD5 (even if its
salted) is not considered to be the most secure way to store your
passwords. I wouldn't call myself a cryptologist, but I personally do
aim for the best and highest possible security in the area of cryptology.

about b): No, we are not trying to prevent someone from getting into a
site. The situation that we are trying to cover here is, when someone
already broke in and has a list of the users hashed passwords. We want
to prevent the unhashed passwords from getting into the hands of the
evil guy and that means that we are making it difficult for him to crack
them. That means that we are giving people a choice to use different
hashing algorithms on different websites in order to prevent
differential analysis and to make it possible to switch the algorithm in
case a serious weakness comes up that voids the currently used algorithm
without having to upgrade to a new major release. The proposed patch is
not so much about using a better algorithm from now on forward, but to
ease the pain of switching it when we have to. I wouldn't really care if
the option for the different methods is actually made available in the
GUI to the site admin. I just want to have the possibility for later.

Last but not least, Joomla already got bad press because we are not
taking every possible measure to secure our users passwords.

About moving hosts: AFAIK Joomla 2.5 already requires PHP 5.3 and 5.3
contains all the necessary code that we would need for this feature by
default.

Hannes

Am 14.12.2011 11:35, schrieb Nicholas K. Dionysopoulos:
> I actually tend to agree with Brian. Unsalted MD5 is broken, thanks to
> rainbow tables and known attacks to the algorithm itself. However,
> Joomla! is using salted MD5 passwords. The fastest MD5 brute force
> cracking machine is Whitepixel with a throughput of roughly 31 billion
> iterations per second. With an 8 character password, it would take
> about a year before the password was successfully brute-forced. I
> would assume that this is enough time for someone with a hacked site
> to take notice of the information leak and change his password. And
> I'd certainly bet that an attacker won't try to brute-force the
> password of all user accounts on the site, unless he has thousands of
> years or million of dollars to waste.
>
> Note: Please do not play the "weak password would be easy to guess"
> card. In this case, the hashing method would be indifferent as the
> attacker would try a dictionary attack and a list of possible password
> before trying brute force. The difference between MD5 and SHA512 would
> be cracking the weak password in 2 minutes or 5 minutes, i.e. so
> frivolous that's not even worth mentioning it.
>

> So, the real questions are: a. *why* do we consider MD5 to be broken

> as a password hashing scheme? Maybe because some cryptologists found a
> way to create "equivalent" strings which result in the same MD5 hash?
> That's true, but it does not apply to salted passwords, unless you're
> so damn lucky as to find an equivalent string whose later part matches

> the 32 character salt string (not a cat's chance in hell). b. *which
> problem* are we trying to solve with this patch? Did anyone report a

> successful hack because someone cracked his password from an MD5
> string (I seriously doubt it)? Or are we trying to protect an
> imaginary user with imaginary precious data against an imaginary
> adversary with infinite technology and money launching a continuous
> imaginary attack against him? That would make a good book or a

> blockbuster movie (wait, I think it /is/ a movie!) but, honestly, I

> would be more worried about other, easier to exploit, attack vectors
> than MD5 cracking. If I were a hacker and found an SQLi vulnerability,
> I'd create a Super Admin account for myself, block the legitimate SA,
> turn off known protection extensions and log in to the victim's site.
> I wouldn't give a dime about cracking MD5 salted hashes ;)
>

> *Nicholas K. Dionysopoulos*

> Web Development & IT Services
> http://www.dionysopoulos.me
> http://www.AkeebaBackup.com
>
>
>
> On Wed, Dec 14, 2011 at 12:07 PM, brian teeman
> <joom...@googlemail.com <mailto:joom...@googlemail.com>> wrote:
>
> This plugin is a great idea although I think it is trying to solve
> a problem that doesn't actually exist
>
> Even with a big fat warning I would expect most users do not
> predict that they will be moving hosts or that their new host
> would not offer the same feature that their current one does. And
> I'm yet to see a host that advertises, before purchase, which
> libraries they have installed etc
>
> If you flag something as "more secure" then the main usergroup
> that will select this will be those users on the least secure
> cheapest hosts. ie the usergroup that is more likely to have
> issues and more likely to be "moving" hosts at some time in the future
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/1wy97FhXH8UJ.
>
> To post to this group, send an email to
> joomla-...@googlegroups.com

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

> To unsubscribe from this group, send email to
> joomla-dev-cm...@googlegroups.com

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

> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
>

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

[brian teeman]

1. Joomla 2.5 does not require php 5.3

2. Offering an option to changing the password algorithm is opening a minefield of issues as already outlined. Are you ready to support all the users who can no longer access their sites just because they moved host?

[Nicholas K. Dionysopoulos]

Hannes,

Think of what happened when Pandora opened the box given to her by Zeus, simply out of curiosity. Substitute Pandora for Joomla! users, Zeus for Joomla! developers and the box with the password hashing option. You get the idea now? THIS is what's going to happen. Once Pandora's box is open, there is no turning back.

I would also like to state, for the record, that as the author of a component which can be used to move sites across hosts, if a user comes to me and complains or blames me for my software breaking his site by not allowing his users to log in any more, I will simply point them to this thread. I hate being so blunt, but I can't see how I can support my clients if the consensus is for Joomla! to give them an option to deliberately break their sites on transfer to a different host without the possibility for a fix. For me, this behaviour would be a bug. People moving from one host to another is not uncommon and must be properly supported. Otherwise we might just as well publish a list of endorsed hosts and tell our users that we can not support them for use of Joomla! with any other host, including all Windows-based local hosts.

And, for the record, no, not all PHP 5.2 hosts (and I think not all PHP 5.3 hosts) support all hashing methods. Only md5 and sha1 are implemented across all Operating Systems and all circumstances. The other hashing methods you are discussing require the presence of the hash extension which is optional on PHP 5.2. On PHP 5.3, the availability of certain features depends on the target platform. It is, therefore, perfectly conceivable that a user enables bcrypt on his Linux host and transfers his site to his local Windows 7 machine (or another Linux host which does not support bcrypt due to the complex legislation surrounding cryptographic software in various countries around the workd) only to find out that he can no longer log in.

Nicholas K. Dionysopoulos

Web Development & IT Services
http://www.dionysopoulos.me

http://www.AkeebaBackup.com

On Wed, Dec 14, 2011 at 4:10 PM, brian teeman <joom...@googlemail.com> wrote:

1. Joomla 2.5 does not require php 5.3

2. Offering an option to changing the password algorithm is opening a minefield of issues as already outlined. Are you ready to support all the users who can no longer access their sites just because they moved host?

--

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

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/5prPzVIuvNQJ.

[brian teeman]

If there is a proven way to convert the hashed password from one algorithm to another en masse then I will shut up about this. Until then this is perhaps .......

[Rouven Weßling]

On 14.12.2011, at 15:32, brian teeman wrote:

> If there is a proven way to convert the hashed password from one algorithm to another en masse then I will shut up about this. Until then this is perhaps .......

This is by definition only possible when the user logs-in or changes his password.

In general I wanna add I'm fine with changing the hashing algorithm we use, maybe for 2.5 only for new installations. This can circumvent the moving between hosts part since we'd just raise the minimum system dependencies accordingly.

However I don't see the need to give users a choice of a hashing algorithm. I think the is a perfectly fine decision to be made by the system.

Rouven

[Hannes Papenberg]

There is no way to convert the passwords. The only way is for the user
to log in and if his password is not stored in the current hashing
algorithm, to update the hash with the current clear text password.

According to this page http://php.net/manual/en/function.crypt.php PHP
5.3 provides its own implementation of all the necessary hashing algorithms.

Hannes

Am 14.12.2011 15:32, schrieb brian teeman:
> If there is a proven way to convert the hashed password from one
> algorithm to another en masse then I will shut up about this. Until

> then this is perhaps ....... --

> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/zSXDGOCLf_EJ.

[Nicholas K. Dionysopoulos]

NO NO NO! My goodness! Don't you understand what the problem is? The problem is not whether the user will see a drop-down or not, but what happens when he moves the site to a host which doesn't support this encryption scheme. Do NOT transparently change the hashing algorithm, that's a catastrophic scenario! Typical case: user is on a host which supports the new hashing method, e.g. SHA-512. After a few months, he decides to move his site to another host, only that hosts does not support this. End result: broken site. DO NOT do that transparently. You have two persons who've seen the limitations of shared hosts across the world warn you not to do that. If, despite your better judgement, decide to do that, at the very least select a hashing method which works in out-of-the-box installations of XAMPP, WAMPServer, MAMP, Zend Server CE, Uniform Server and Apache Triad version of the last 2 years. Otherwise expect to create a lot of trouble and expect me to be sending a lot of angry people your way for breaking their sites.

You do not realise how BROKEN and OUTDATED things are on shared and local hosts, do you? Do you at least realise that the majority of Joomla! users do not have technical skills and can rarely even figure out which version of PHP (or even Joomla!) they are using? Have you posted > 10,000 support posts dealing with people like that? These are your clients. These are the people you are creating software for. They don't read, they are clueless and will blame YOU, the developers, not themselves when something's not working. Don't make them think and, for God's sake, don't make them have to learn how to find out the PHP version and installed extensions before buying hosting. This will put Joomla! in a serious disadvantage against other CMS and cause people to consider it "unstable".

Anyway, do what you like. I can see the sh*tstorm coming and I'm busy taking cover ;)

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

--

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

[brian teeman]

As I have already said Hannes php 5,3 is not the minimum level for joomla 2.5 so your comment is mute

[Nicholas K. Dionysopoulos]

Hannes,

The amount of hosts who have upgraded to PHP 5.3 is tiny. I can tell you what I see on a daily basis (thanks to the log files people send me when asking for support). The vast majority (~90%) is still on PHP 5.2. More specifically, PHP 5.2.17 and some (Debian-based, apparently) hosts are stuck with PHP 5.2.6. There are quite a few hosts still stuck on PHP 5.1.6, but these can't even run Joomla! 2.5, so I don't care.

Therefore, by making this kind of change, you are screwing a large percentage of this 90% of Joomla! installations still on PHP 5.2. Which is EXACTLY my point.

Given the upgrade pace of live hosts, I'd say that this situation won't change dramatically before the end of 2012, so such a change should better be done for Joomla! 3.5, not 2.5. At that point in time (mid-2013) there will be no excuse for hosts still stuck with PHP 5.2. In fact, I expect PHP 5.3 to be obsolete, 5.4 to be current and 6 to be in beta.

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[JCR - Lab]

Le 14/12/2011 18:14, Nicholas K. Dionysopoulos a écrit :

Hannes,

The amount of hosts who have upgraded to PHP 5.3 is tiny. I can tell you what I see on a daily basis (thanks to the log files people send me when asking for support). The vast majority (~90%) is still on PHP 5.2. More specifically, PHP 5.2.17 and some (Debian-based, apparently) hosts are stuck with PHP 5.2.6. There are quite a few hosts still stuck on PHP 5.1.6, but these can't even run Joomla! 2.5, so I don't care.

Therefore, by making this kind of change, you are screwing a large percentage of this 90% of Joomla! installations still on PHP 5.2. Which is EXACTLY my point.

Given the upgrade pace of live hosts, I'd say that this situation won't change dramatically before the end of 2012, so such a change should better be done for Joomla! 3.5, not 2.5. At that point in time (mid-2013) there will be no excuse for hosts still stuck with PHP 5.2. In fact, I expect PHP 5.3 to be obsolete, 5.4 to be current and 6 to be in beta.

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

Same statistics here in France. Only some hosters provide PHP 5.3 (maybe 6-8%), most rely on PHP 5.2.17, a significant handful (Debian hosting) are stuck in 5.2.6. And a major free hoster here still only providing 5.1 !

So, before upgrading crypto in Joomla!, we must be careful.

About 5.3 crypto resources, most of them are not built by default PHP hostings, mostly due to patents or legal problems with crytptography.
This makes relevant a "wait and see" attitude regarding this point.

Jean-Claude Richard
lab-project

[brian teeman]

PHP 5.2   74.8%

PHP 5.3   19.0%

Source http://w3techs.com/technologies/details/pl-php/5/all

Lies dam lies and statistics etc but even with margins for errors thats pretty conclusive. In fact I expect it to be even more skewed thatn that as these stats are for the top million sites so presumably is more dedicated than shared hosting where the sites do have the option to upgrade and didnt

[Hannes Papenberg]

Could someone state what the PHP requirement for Joomla 3.0 is? I'm not
seeing us to be forced to introduce this in 2.5, but maybe in a version
that already requires PHP 5.3

@Nicholas
I'm well aware of how awfully outdated hosts are most of the time. I
just recently had to upgrade a host from PHP 4 to PHP 5 and we exactly
had the situation that you are describing, that the software was PHP 5
and the host PHP 4. However I tend to take the same stance towards PHP
versions like I do for IE versions. If you are still on IE6/7/8, you
deserve to suffer. There are more than enough cheap and good
alternatives out there and with the Joomla market share, we could force
hosts to think about updating/configuring properly, if they get to many
support requests.

It would actually be a good thing to create a plugin and add it to the
default Joomla install which gives you a loud warning that your host is
crap and that the following x things are broken and/or misconfigured.

Hannes

Am 14.12.2011 18:14, schrieb Nicholas K. Dionysopoulos:
> Hannes,
>
> The amount of hosts who have upgraded to PHP 5.3 is tiny. I can tell
> you what I see on a daily basis (thanks to the log files people send
> me when asking for support). The vast majority (~90%) is still on PHP
> 5.2. More specifically, PHP 5.2.17 and some (Debian-based, apparently)
> hosts are stuck with PHP 5.2.6. There are quite a few hosts still
> stuck on PHP 5.1.6, but these can't even run Joomla! 2.5, so I don't care.
>
> Therefore, by making this kind of change, you are screwing a large
> percentage of this 90% of Joomla! installations still on PHP 5.2.
> Which is EXACTLY my point.
>
> Given the upgrade pace of live hosts, I'd say that this situation
> won't change dramatically before the end of 2012, so such a change
> should better be done for Joomla! 3.5, not 2.5. At that point in time
> (mid-2013) there will be no excuse for hosts still stuck with PHP 5.2.
> In fact, I expect PHP 5.3 to be obsolete, 5.4 to be current and 6 to
> be in beta.
>
> --

> *Nicholas K. Dionysopoulos*

> Lead Developer, AkeebaBackup.com
>
> On Wednesday, 14 December 2011 at 19:09, Hannes Papenberg wrote:
>
>> There is no way to convert the passwords. The only way is for the user
>> to log in and if his password is not stored in the current hashing
>> algorithm, to update the hash with the current clear text password.
>>
>> According to this page http://php.net/manual/en/function.crypt.php PHP
>> 5.3 provides its own implementation of all the necessary hashing
>> algorithms.
>>
>> Hannes
>>
>> Am 14.12.2011 15:32, schrieb brian teeman:
>>> If there is a proven way to convert the hashed password from one
>>> algorithm to another en masse then I will shut up about this. Until
>>> then this is perhaps ....... --
>>> You received this message because you are subscribed to the Google
>>> Groups "Joomla! CMS Development" group.
>>> To view this discussion on the web, visit
>>> https://groups.google.com/d/msg/joomla-dev-cms/-/zSXDGOCLf_EJ.
>>> To post to this group, send an email to
>>> joomla-...@googlegroups.com

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

>>> To unsubscribe from this group, send email to
>>> joomla-dev-cm...@googlegroups.com

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

>>> For more options, visit this group at
>>> http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Joomla! CMS Development" group.
>> To post to this group, send an email to

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

>> To unsubscribe from this group, send email to
>> joomla-dev-cm...@googlegroups.com

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

[Rouven Weßling]

I understand what you mean Nicholas.

First of all, It has been all but decided that that Joomla 3.0 will require PHP 5.3. Platform 12.1 certainly will and I'm sure the CMS will follow suit.

Second, we already require some pretty common but optional extensions to core PHP (mysql(i), zlib, JSON, XML) - but I've even heard of hosts not supporting JSON. I think it's fine to require one, reasonable common, hashing algorithm besides md5() with Joomla 3.0.

What I do agree with after reading you, sorry, rant is that we probably shouldn't do anything for 2.5.

Rouven

[brian teeman]

It's your right and privilege to take that stance but Joomla is a mass market product which despite what we think doesnt have the power to dictate to every hosting provider in the world to upgrade. Heck if Microsoft are unable to force every user to upgrade from ie6 then joomla has no chace. (Speaking as someone who this summer completed a major govt web site where the requirement had to be ie6 compatibility due to the age of the computers and operating system version)

[Mark Dexter]

I believe that the decision at this point is that 2.5 will continue to
support PHP 5.2 and 3.0 will require PHP 5.3. It is important to keep
in mind that 2.5 is a long-term-support release, so no user will be
required to upgrade from 2.5 to 3.x until 2013. Version 3.0 will be a
STS release and will have (we hope) some new cutting-edge features
that will be targeted toward users who need these features for new
websites. So it is not a terrible problem if hosts move to PHP 5.3
more slowly than we would like. For those users, version 2.5 is the
answer.

If someone needs a cutting-edge website using 3.0, they will need an
up-to-date host that supports 5.3. That's my take on this. Thanks.
Mark

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/efhBr2hVjjwJ.

[G. D. Speer]

Admittedly, this is not my area of expertise but let me toss in an idea to see if it's technically feasible and solves the issue raised by the "critical reviews."

 

a)  Add a security hash selector to the installer that sniffs the available encryptions and offers then to the installing admin.  (For discussion, assume they chose SHA-512.)

b)  Add a second pasword field to the user table.  The first field's hash remains salted MD5.  The second field's hash is the selected SHA-512 encryption.

c)  As any user password is recorded, it is written in both MD5 and SHA-512 to the two fields.

d)  In normal operation, the user is challenged against the selected SHA-512.

 

e)  Provide an advanced option in global to disable/delete the MD5 field data with suitable warnings about inability to migrate the site.

 

In the event the site is migrated to a lesser-configured server and the advanced option e) was not selected.

 

f)  Add an "Force MD5 access" flag to configure.php or similar fallback if the selected encryption is not available on that server to set global operations to challenge against the MD5 hash instead of the SHA-512 or at least allow super admin access via MD5 in order to reconfigure / temporarily set the site to use MD5.

 

If the migration is to a staging server, allow the admin to leave the SHA-512 passwords intact.  If it's a permanent relocation to a server with a different encryption offering or a change of encryption, allow the admin to set the second password field to null.

 

On login, test if the higher encryption hash field is null.  If not null, test against the higher encryption.  If null, test against MD5 and record entered password to the higher encryption.

[Rouven Weßling]

The advantage of using a different algorithm over MD5 is lost this way.

If your user records are leaked everyone would attack the "less" protected field since they hash the same password.

Rouven

[Hannes Papenberg]

It would even make it less secure, since you could do theoretical differential analysis, since you have two hashes that are based on the same password.

[piotr_cz]

Joomla Platform 11.3 (which is going to be bundled in Joomla 2.5) states requirement of PHP 5.3, I suppose that's faulty?

[G. D. Speer]

The point of e) is to include the ability to delete the compromisable passwords after enough accounts have converted for those seeking a higher protection level with associated risks.  (And by default not delete/do nothing for everyone else on shared servers.)

[G. D. Speer]

OK thanks

[Rouven Weßling]

On 14.12.2011, at 21:47, piotr_cz wrote:

Joomla Platform 11.3 (which is going to be bundled in Joomla 2.5) states requirement of PHP 5.3, I suppose that's faulty?

Some parts of the platform do require PHP 5.3 (JApplicationCliDaemon AFAIK) but none of the parts that are used by the CMS do.

Rouven

[Nick Savov]

Is there a consensus after the discussion? :)

Is this consensus to go with the patch for 3.0 or is that also
unsatisfactory to those who have objected so far?

Would love for everyone to come to a consensus before making a decision
rather than have it split 50-50.

Kind regards,
Nick

[Nicholas K. Dionysopoulos]

I'd say let's go with 3.0. This means that, at least, the next LTS (2.5) won't a have a hard dependency on software (PHP 5.3) which only a minority (<20%) of hosts has installed.

-- 
Nicholas K. Dionysopoulos
Lead Developer, AkeebaBackup.com

[Niels Braczek]

Am 14.12.2011 22:07, schrieb G. D. Speer:

> The point of e) is to include the ability to delete the compromisable passwords after enough accounts have converted for those seeking a higher protection level with associated risks. (And by default not delete/do nothing for everyone else on shared servers.)

Your idea would prefectly make sense, if the attack was made during the
login process - but that's not the case. During login, the password is
is transferred in plain text, if not SSL is used.

The hashing of the password is done to protect it in case of (free)
access to the database. And in this case, the two different hashes from
the same password (at least mathematically) decrease security.

Regards,
Niels

--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Jase Williams]

I also vote this for 3.0

The minimum requirements should solve the server migration issue by then.

[Herman Peeren]

There was more discussion about this on the tracker. My main argument: for the purpose of storing the passwords MD5 is not old and weak. One could get the impression that there would be an algorithm to reverse engineer MD5; that is not the case

This mailing-list is a better place for this discussion, I think, not on the tracker. Here are some postings (there was more on the tracker):

Ingezonden door: Herman Peeren Toevoegen datum: 2012-01-08 22:33:32 The weakness of MD5 doesn't have any implications for the usefullness of MD5 to store a (salted) password. The weakness of MD5 (and SHA-1) is that it is possible, given the original string (!) to find another string with the same hash in less time than a brute force attack would cost. If you use a MD5-hash to authenticate a file (for instance to avoid that an infected computerprogram would be downloaded), then MD5 is not secure: it is possible to make another file, possibly malicious, with the same MD5. Still it will not be easy (no ready-made algorithms AFAIK) to make that fake file exactly as long as the first one and have all false information you want on board, so even with this we are not talking about a big risk in everyday practice. And the weakness is of no use for the reconstruction of passwords. For reconstruction of a password from the Joomla-db you only have 2 possibilities: compare the password with a list of possible passwords (dictionary attack) or else: brute force. A rainbow-table is just a precomputed dictionary attack, but that is only usefull if the same password for different users would be hashed in exactly the same way; the salt however prevents that, so it is not useful to produce a rainbow-table. But a "normal" dictionary attack is still possible. The same holds for all hashing algorithms. If a password is in the used dictionary, then a dictionary attack will succeed in a reasonable time, always, with any (!) hashing algorithm. So we are only dealing with brute force. The longer it takes to encrypt a string, the more a brute-force attack would be slowed down. This is very much a moving horizon: with ever faster computers (and the possibility to spread computations over several computers), any hash wil once be reverse-engineered using brute force. There are also limitations on the expensiveness of an algorithm: we want Joomla not only be used on the fastest servers and still be able to login within a reasonable amount of time. Now let's look at what we are securing with the hashed passwords. We want to avoid that, once someone has hacked your system (or has a copy of your db) can easily retrieve the passwords. The first (and real) problem is: that someone has intruded into your system! If they can read your db, then they might possibly also install extensions or other programs on your server... and read the plain text password that is server-side provided by users at every login. I think that discussions like this should be on the mailinglist and not on the tracker, but because the discussion is here now and because I want to react timely when someone proposes features that I think are not useful (as we learned from anotehr case lately), I have put it here too.

Ingezonden door: Jason Williams Toevoegen datum: 2012-01-09 01:18:14 @hermen there is a diiscussion on the mailing list about this patch, you can find it here. https://groups.google.com/forum/#!topic/joomla-dev-cms/mzb0utUj0wg/discussion Secondly you haven't really told us anything we don't already know. You've just explained how hashing/cracking works then told us why the feature isnt useful. Maybe explain reasons why you don't think its useful or why moving off MD5 would be a bad idea in your view. I don't see how using a more secure algorithm is 'not useful' when its protecting thousands if not millions of user passwords. As for the expensive/slow argument, bcrypt can be tuned, and login times are no different than they were before.

Ingezonden door: Herman Peeren Toevoegen datum: 2012-01-09 07:05:10 No, I just explained why other hashing algorithms are NOT more secure than MD5 when it concerns the hashing of the passwords in the db: the weakness of MD5 is only important when using an MD5 to authenticate a file (for you can make another file with the same MD5). Taking another hashing algorithm for the hashing of Joomla passwords won't give you more security: dictionary attacks will still be possible and there is only a small gain in slowing down a brute force (and tuning bcrypt down to the same login times as they were before speeds up the brute force so the gain is minimal). In the mailinglist, of which I'm well aware, are arguments why the change of this algorithm will give you a lot of trouble. So: the gain is nothing (or not worth it) and there are considerable costs. That is why I think this patch must not be applied. Moreover: we are securing the retrieval of passwords once someone has broken into your system. But at the same time anyone who logs in hands over her/his password to the system; that only takes a few lines of authentication-plugin to intercept. You are working on a better safe in a house (where you keep a copy of the keys of the house) for in case a burgler comes in and steals the safe. But at the same time, anyone entering the house, puts the key on the table. If I was the burglar I wouldn't take the trouble to break the safe, but grab the keys that are laying around. Security is better improved by not putting the keys on the table and in the first place: by keeping the burglar outside. Improving the code of the safe is just marginal (and gives more troubles than it solves).

[Jase Williams]

Hi Duke3D

a) My patch already does this kind of... When you install Joomla my patch (by default) puts you on MD5, you don't choose what hash you want upon installation but you can change it after. 

When it comes to changing hashes in the user manager my patch actually checks server configs before using that algorithm (well so far it does for bcrypt). If that algorithm doesn't exist it just sticks with MD5. This is more to prevent hashing errors rather than server flexibility.

c) One of the main points of this is to move away from MD5 hashes being in the database. So although I see the logic behind your idea, it sort of defeats the whole point of this upgrade. Its a bit like Sony storing plaintext passwords in their db 'just in case' the hash doesn't work. stupid analogy I know but it gets across the point Im making. 

As I understand If this is implemented in Joomla 3.0, all hashing schemes will be covered by then (minimum requirements). So the 'Server Migration' argument will be put to bed.

[Jase Williams]

@herman 

Taking another hashing algorithm for the hashing of Joomla passwords won't give you more security. 

 

Considering myself and many other references will disagree with that I would like some proof to support that claim.

Here is a quote from wikipedia and http://www.akkadia.org

Unix and Linux vendors are moving to using 256- and 512-bit SHA-2 for secure password hashing.^[8] NIST's directive that U.S. government agencies must stop uses of SHA-1 after 2010,^[9] and the completion of SHA-3, may accelerate migration away from SHA-1. 

 

If what you said is true then surely there would be no need for this ^

Not that I need more evidence but Drupal 7 have moved their hashing algorithm to SHA-512 and wordpress also don't use MD5. Once again Joomla will be left behind with an unsecure hashing method if we choose to ignore this. 

In the mailinglist, of which I'm well aware, are arguments why the change of

this algorithm will give you a lot of trouble.

The only 'trouble' I've seen in here is backwards compatibility which won't be a problem on 3 because of raised minimum requirements. Users won't be using version 3 on PHP 4.

As for your last paragraph analogy it doesnt make much sense and isnt even worth replying to.  You're basically saying why bother securing the database of sensitive information if they can't get in anyway. Well maybe thats a level of security you're happy with but not one that I would advocate at all.  

[Marius van Rijnsoever]

I have actually changed my mind on this patch and now think it should
be implemented for Joomla 3.0.

Since SHA-512 will now always be included in the PHP minimum
requirement of Joomla 3.0, there is no issues when people would
migrate their sites.

SHA-512 does provide a bit more defence against brute force attacks,
as GPU's currently don't handle larger bit hashing at the moment. And
many corporations require this these days. For people that require
this for 2.5 use the following extension:
http://extensions.joomla.org/extensions/access-a-security/site-access/authentication-management/18225

I would suggest making 2 changes to the current patch
1: Make SHA-512 the default
2: Code needs to be cleaned up a bit (less code is required if the
hasing type is the last in the stored string and not the first)

Thanks, Marius

[Jase Williams]

Hi Marius

1: What are your thoughts on giving the user a choice (512 default with other options)?
    Do you think we should do this or do you think we should just silently switch to SHA-512?

2: Could you explain what you mean here? I can look at the patch tonight and fix it up a little but Im still new to Joomla development.

Thanks,

Jason

[Jase Williams]

If Joomla 3.0 is going to require 5.3 then I think all the hashing methods I mentioned above will be included in the minimum requirements.

[Herman Peeren]

Dear Jase,

Sorry it took so long to react: at the moment unfortunately I'm only
occasionally on this list. I appreciate your perseverance.

There are 2 different ways to look at this issue: from a technical
point of view and from a sales/marketing point of view. Technically
seen, (I repeat) there is no gain in security when taking another
hashing algorithm for the hashing of Joomla passwords. But there is a
huge gain from a sales/marketing perspective: because most people,
including decision-makers at large companies, believe it would improve
security, any corporate use of MD5 is negative to sales. Give them
their SHA-512 and they will be more willing to use your product. So,
although technically there is no real gain in security, there is more
confidence in the product and more belief in the myth of security.
That sells better (even better than real security improvements).
Therefore it should probably be included in Joomla.

*** Technical POV ***
I've tried to explain, but I don't have the illusion you will
understand me. See the earlier postings. To summarize:

* the "weakness" of MD5 is of no use for the reconstruction of
passwords. There is no algorithm to "decrypt" a hash! Please look at
what the "flaw" in MD5 is all about and you'll understand that it has
nothing to do with the "decryption" of hashed salted passwords.

* the only difference in security for this kind of password storage
between the different hashing algorithms is the time it takes to use
brute force (and even that is not a real difference: you could as well
hash x-times with MD5 to slow down the brute force).

* the time it will take to produce the hash is the most important
factor determining the time it will take to use brute force. For
security, to avoid brute force you want to make that time as long as
possible. But there is an upper limit to the time it will take to
produce that hash: otherwise authorization would take too long; from a
usability point of view you want to have that time very limited. Given
the hardware, the security-requirements and the usability-requirements
you could calculate an optimum. Main point: there is always a limit to
the time you can spend on hashing.

* if the attacker's hardware is faster than the hardware used by the
Joomla-system, then slowing down the brute force is compensated by a
faster computer. A brute force can always be divided over several
computers (say, for instance, a few thousand in a botnet...). You
cannot always have a better system than the attacker, so brute force
can, in priciple, always be used successfully. It is a race you'll
allways lose.


*** sales/marketing POV ***
This is all about beliefs and myths. Most decision-makers are not
technically skilled enough; they wouldn't know the difference between
the different hashing algorithms. But they have heared other people
say that MD5 is not secure. They don't know anything about the details
or context, but all parrots just retweet it. Most people take it for
granted, because other people also repeat the same message. Then you
don't get reasonable, technically based arguments, but arguments like:
"many large companies require SHA-512, not MD5", "It is also being
used by X, Y and Z" (next year someone will probably use Joomla in
that argument), "There are many quotes on internet, even on respected
sites, who say it, so it is probably true". Truth is not necessarily
what the majority thinks. Just as the Emperor was really naked while
everybody said they liked his new clothes. You mentioned an
interesting quote in your reaction, from Wikipedia, but originally
from http://www.akkadia.org/drepper/sha-crypt.html . In the second
paragraph ("the problem") he describes how "The security departments
of some customers look at recommendations they get and evaluate the
deployed systems based on this". Although not all recommendations are
correct, they "want to be safe rather than sorry" and so the customers
are asking for a "solution".

*** optimizing happiness ***
Replacing MD5 in Joomla will satify a lot of people:

* the ones who believe the general myth that it will make the storage
of passwords more secure.

* the ones who have to sell there Joomla-products to believers of the
myth (like corporate users).

* the people who understand the technical details (it might give them
a compassionate smile about those retweeted "truths").
http://en.wikipedia.org/wiki/Eppur_si_muove

* the people with malicious intentions AND understanding of the
technical details (to see that energy is wasted to such a triviality
instead of working on real security threats).

And so it is probably a good idea to go with the mainstream and change
MD5 for another hashing algorithm for storing the salted passwords in
a future Joomla-version.


*** interpretation ***
In my last paragraph analogy I was NOT basically saying "why bother

securing the database of sensitive information if they can't get in

anyway".That is your interpretation of it, but not the point I want to
make. Sorry for not being more clear. What I wanted to say with that
analogy is, that the gain of this effort is minimal/nihil and we'd
better spend the time to fixing some bigger security threats. But that
argument is only from a technical perspective. If however you take the
sales/marketing/mythical aspect into account too, then it is probably
a good idea to get rid of the "old and weak MD5" (you can quote me
with that now too). ;-)

All the best,
Herman


On 24 jan, 23:31, Jase Williams <jase.willi...@gmail.com> wrote:
> @herman
>
> *Taking another hashing algorithm for the hashing of Joomla passwords won't
>
> > give you more security. *

>
> Considering myself and many other references will disagree with that I
> would like some proof to support that claim.
> Here is a quote from wikipedia andhttp://www.akkadia.org
>

> *Unix and Linux vendors are moving to using 256- and 512-bit SHA-2 for
>
> > secure password hashing.[8]<http://en.wikipedia.org/wiki/Sha_512#cite_note-7> NIST's

> > directive that U.S. government agencies must stop uses of SHA-1 after 2010,

> > [9] <http://en.wikipedia.org/wiki/Sha_512#cite_note-8> and the completion
> > of SHA-3, may accelerate migration away from SHA-1. *

>
> If what you said is true then surely there would be no need for this ^
>
> Not that I need more evidence but Drupal 7 have moved their hashing
> algorithm to SHA-512 and wordpress also don't use MD5. Once again Joomla
> will be left behind with an unsecure hashing method if we choose to ignore
> this.

> *
> *
>
> > *In the mailinglist, of which I'm well aware, are arguments why the
> >> change of*
>
> > *this algorithm will give you a lot of trouble.*

[Jase Williams]

I think we should all re-look into this now that Joomla 3.0 is on the horizon.

i've found this article to be quite interesting.

http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage

The patch on the tracker could easily be updated.

[garyamort]

I'd like to see this be more extendable then simply hard-coded choices.

For example, I was recently trying to avoid creating "yet another userid/password" for a separate server by linking it to the Joomla userid table.  The server application supports both PAM and SASL for authentication.  

PAM and SASL both have a MySQL plugin - but they were somewhat limited in what queries they could maintain.  One of the plugins will do individually salted MD5 passwords, however it has a hardcoded format that must be

$1$<salt><hash> - so it would not work with the Joomla format of <password>:<salt>

As far as I can tell, the Joomla format is based on allowing an easy function call to support both salted passwords and unsalted passwords, ie explode the password on the : charector, the array item 1 is the hashed password, array item 2 is the salt[which can be blank].  Pass the salt and submitted password to MD5 and compare to the hashed password.

If the salt is blank, it is equivalent to not using a salt so the compare works.  If the salt exists, same deal.

By allowing for a plugin system for hashing, it would have be easier to write a plugin for Joomla! which can support whatever functions external systems use - rather than trying to force those system to match Joomla!.

On Wednesday, December 14, 2011 4:11:00 AM UTC-5, Jase Williams wrote:

Hi all

So as the MD5 hashing algorithm Joomla! uses is getting old and weak. I've decided to create a patch which allows admins to set a new, more secure hashing algorithm.

There is still some debate over whether users should choose the algorithm they want or whether we should just change it anyway in the background.

The current choices are (MD5, SHA-1, SHA256, SHA-512, bcrypt)

Here is the patch i created:

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8549&tracker_item_id=27381

Would love some feedback on this.

Thanks

Jason

[M. Burnett]

@herman, some comments:

Technically seen, (I repeat) there is no gain in security when taking another
hashing algorithm for the hashing of Joomla passwords.

* the "weakness" of MD5 is of no use for the reconstruction of

passwords. There is no algorithm to "decrypt" a hash! Please look at
what the "flaw" in MD5 is all about and you'll understand that it has
nothing to do with the "decryption" of hashed salted passwords.  

 
This is not accurate. Yes, you do not decrypt a hash, but you do brute force them. Collisions, preimage attacks, and susceptibility to birthday attacks are a bigger weakness than you realize. Also the MD5 function is relatively lightweight which allows for massive offline brute-force attacks, so there very much is a gain by moving to a stronger algorithm. Anyone who says there is no gain moving from MD5 has never actually hacked a Joomla site and cracked all the passwords before.

When most experts say that MD5 is no longer suitable for hashes, you should assume that their opinions are based on widely validated and based on accepted research.

* the only difference in security for this kind of password storage
between the different hashing algorithms is the time it takes to use
brute force (and even that is not a real difference: you could as well
hash x-times with MD5 to slow down the brute force).

The time it takes is only one factor, as mentioned above. The size of the hash is also another big factor, for example, making it susceptible to birthday attacks. The size of the hash also makes a big difference for time-memory tradeoff attacks, making rainbow tables even with salts still feasible for MD5

Yes you can slow down MD5 through multiple iterations and this is a reasonable short-term solution if you implement it correctly.

* the time it will take to produce the hash is the most important
factor determining the time it will take to use brute force. For
security, to avoid brute force you want to make that time as long as
possible. But there is an  upper limit to the time it will take to
produce that hash: otherwise authorization would take too long; from a
usability point of view you want to have that time very limited. Given
the hardware, the security-requirements and the usability-requirements
you could calculate an optimum. Main point: there is always a limit to
the time you can spend on hashing.

Yes there is an upper limit on the time spent hashing, but if you consider that requiring a customer to wait just one more second to authenticate can add hundreds of cpu years to an offline attack, this is a huge difference.

 

* if the attacker's hardware is faster than the hardware used by the
Joomla-system, then slowing down the brute force is compensated by a
faster computer. A brute force can always be divided over several
computers (say, for instance, a few thousand in a botnet...). You
cannot always have a better system than the attacker, so brute force
can, in priciple, always be used successfully. It is a race you'll
allways lose.

Again, it is not a matter of being faster than the cracker, it is about making an offline attack less feasible. When the user logs in the hash is computed just once, whereas the hacker may have to compute quadrillions of hashes to find the correct password. In that sense, it is a race you will always win.

So yes it is important to spend time addressing other security issues, but you have to remember that almost any targeted attack will ultimately lead to someone grabbing the hashes for offline brute-forcing so it makes sense to at least use minimal acceptable standards. There really is no reason to place this as a fairly high priority.
 

Also, you mentioned the advantages of the sales aspect of this, but it is important to remember that there are a huge number of organizations that are required to comply with certain standards. It's not just a matter of a flashy sales point, many organizations just cannot use it if it doesn't comply with their imposed regulations. If they must use at least 160-bit hashing algorithms (say for FIPS180-3 compliance), then MD5 is just out of the question and they cannot use the product.


Mark

[garyamort]

On Wednesday, March 21, 2012 3:57:53 PM UTC-4, garyamort wrote:

I'd like to see this be more extendable then simply hard-coded choices.

I feel a bit moronic...after dwelling on this a bit I realized that Joomla! already supports using different hashing mechanisms for the password.

All you need to do is write a  an authentication plugin, for example: Joomla-SHA1: then enable that password and disable to the Joomla authentication password.

Design your own password format convention[for example: hashed password:salt:sha1

So if the password is in the Joomla format you will know it by exploding the password field and only having 2 array entrees, in which case you can authenticate using the old salted MD5 system, and then since you have the cleartext password, go ahead and create a new hash in the new format.

As an added plus, since the purpose of the salted hash is to avoid rainbow tables being used to lookup an password which generate the same hash - and your assuming that at some point someone is going to get your list of passwords, you might as well re-salt and update the password hash at every logon.  That way if anyone ever does find an 'equivalent' password as soon as they login, the old user password will no longer function - giving the user a heads up that there may be a problem, and when they reset their password it will blow away.

[Jase Williams]

HI Garyamort

 

Have you tried my patch?

It already takes advantage of Joomla's different hashing mechanisms (and adds some new ones).

In order to enable different algorithms this can be done in the user manager -> options (assuming you have the patch installed).

Once enabled they will do pretty much what you mentioned. They will let the user log in using the old hash, re-hash the password (with a new salt & new algorithm), then store it back in the Db.

The algorithm choice is in the password string so its very easy to know which algorithm is being on which user. (ALGO:HASH:SALT)

So the patch already does all of those things, im not sure why you want it as a plugin? This should remain a core process of Joomla

[garyamort]

Mainly, I feel that based on others feedback here, this patch makes it too easy for a site owner to make changes to their website without really understanding what their doing and what the effect is.  

By instead making different plugins for the different mechanisms,  for example: today if you go the plugin management and go to authentication you have the option of:

Joomla

Gmail

<some others>

....  authentication is a first success process, so the order of the plugins allows for multiple formats[ie put the gmail plugin first and the joomla plugin second and if they have a gmail configuration, they will logon and if not, the Joomla process will still allow them to logon.  Disable the Joomla plugin and then they can only use the Gmail plugin]

Joomla MD5

Joomla SHA1

Joomla SHA-256

Joomla SHA-512

Joomla Bcrypt

When it is installed, set the MD5 plugin as enabled by default and everything works as it does today.  

If a site owner wants to change it, they can go ahead and enable one of the other plugins.  For backwords compatibility they can leave MD5 enabled for a while or not.

Add a little smart code to your plugin configuration screen for each plugin and the plugins can even display how many users are currently configured for that plugin.

It can still be a core Joomla process, just don't embed it in the user manager since there is already an existing process to support it.

The only ugly part of this method is that the hashing mechanisms are embedded in each plugin.  However, the current process of embedding it in the JUser helper is also ugly.

I'd recommend instead pulling all that code out and creating a new set of classes and interfaces similiar to the crypt libraries in the next Joomla Platform, so you can have classes JHash and JHashSalt, interface JHashCipher,

and implementations of  JHashCipher such as JHashMD5, JHashSHA1, JHashSHA256, etc

With all the hashing functions pulled into their own class structure, then a lot of duplicated code from JSession, JCookie, JToken, and JUserHelper can be moved to JHashCipher implementations.

[Herman Peeren]

Hi Mark,

Thank you for taking the trouble of answering my post. But I think your comment mainly illustrates what I wrote: the mentioned weaknesses of MD5 (collisions, preimage attacks, and susceptibility to birthday attacks) are only in play when the hash is used to authenticate a document . Could you please explain how those methods could be used to speed up a brute force attack to retrieve passwords? I am very interested in it.

You also mention FIPS180-3 compliance. Same story: not about password storage. From the abstract of that standard: "This standard specifies five hash algorithms that can be used to generate digests of messages. The digests are used to detect whether messages have been changed since the digests were generated."

As you know, when two different inputs generate the same hash, it's called a collision. Collisions happen in every hash, by definition. The weakness of MD5 (and SHA-1) is, that a collision can be constructed and that the source can be constructed in such a way that it is something meaningful (but not the original text). So, although the original text has been changed (to for instance malicious software of a false contract), it still has the same hash. But that is not relevant for password storage.

I agree that time is running out for MD5 for password storage as it will be surpassed by Moore's law (hardware will be faster and faster). That is exactly the same for the other hashes for they all can be generated too fast. Except BCrypt, which is the only one specially developed to be slow enough and can be adjustable slowed down in time. The bitlength of the hash (128 for MD5, 160 for SHA-1, 184 for BCrypt) only influences the chance to hit a collision earlier than the original password, but not the chance to retrieve the original password (which could possibly be used to break into another system, as is a much heard argument).

Except BCrypt all allgorithms need about the same time to find the original password with brute force. The main factor making a difference is: the length of the password or passphrase, for the brute force time increases (almost) exponential with the length of the password/passphrase. So, the best advice to give to users now, is to make password/passphrase as long as possible. At the moment mod_login's input-field for the password has a maximum length of 15 characters, which is allright. We could enhance it (IMHO without introducing new safety risks, for that length is not validated anywhere beyond the html of that input-field afaik, so a longer string can now allready be sent to the server). We could put a big alert on the login-screen for passwords under 10 characters; and strongly discourage new passwords shorter than 8 (or some adjustable figure). Easy measures with a lot of effect for better security. And years to use MD5 without any problem...

BCrypt is a good candidate for password hashing for it's adjustable slowness. But it could generate some problems when just put into core Joomla: mainly because the cost-factor cannot be lowered without losing the stored passwords, thus giving some portability-problems earlier referred to. For turning the cost-factor higher, maybe we could write some adapter. I would personally prefer to send a hash (with the salt and a nonce) instead of a cleartext password from the client as referred to earlier (stop sending passwords!), but at the moment there is no Javascript-implementation of BCrypt and the differences in speed of client-side hardware make it almost impossible to find an acceptable cost-factor. For client-side hashing, MD5 is a better option.

There were two arguments you gave, I disagree with:  "When most experts say... etc.". Authority is no valid argument. Hence my citation of Galileo earlier. The other one: "Anyone who says...etc.". One counterexample is enough and I know him personally (γνῶθι σεαυτόν).

I'm learning a lot from this discussion and hope to learn more. Together we can enhance Joomla's security. Thank you all for your contributions.

Ciao,
Herman

[Herman Peeren]

+1 for only providing basic encryption (and hashing) functions in the Platform and providing authentication-implementations for the CMS on the JED. Then maybe, when it has all matured a bit, something can be moved to CMS-core.

I further plea for removing (or at least: officially deprecating) the GMail-authentication in the CMS. It was made as an example and should not be used in practice.

The only point mentioned earlier with an encryption-library in the Platform is the legal limitations in some countries. Maybe we should also think of providing separate libraries as additions to the Platform, just as we have extensions separate from the CMS.

[Jase Williams]

BCrypt is a good candidate for password hashing for it's adjustable slowness. But it could generate some problems when just put into core Joomla: mainly because the cost-factor cannot be lowered without losing the stored passwords, thus giving some portability-problems earlier referred to.

I don't think this is true.

The cost factor is stored within the BCrypt hash, so even though you adjust the cost the user can still log in as the function knows what rounds the old hash was created in, it won't take me long to write some code to have it re-hash their password with the new BCrypt cost.

Don't quote me but im pretty sure that's possible. I'm sure someone will tell me if it isn't.

Another reason why Bcrypt is good, its flexible, you can alter the slowness and not stop the old hashes from working.

Jase

[garyamort]

On Friday, March 23, 2012 5:03:51 PM UTC-4, Herman Peeren wrote:

Hi Mark,

Thank you for taking the trouble of answering my post. But I think your comment mainly illustrates what I wrote: the mentioned weaknesses of MD5 (collisions, preimage attacks, and susceptibility to birthday attacks) are only in play when the hash is used to authenticate a document . Could you please explain how those methods could be used to speed up a brute force attack to retrieve passwords? I am very interested in it.

Note: with password storage, it's not a matter of brute force attacks from the front end, but rather you assume that the bad guy has at his disposal your user table consisting of usernames and hashed passwords.  For example, by using an sql inection attack which did not allow him to update data, but did allow him to inject a 'SELECT * FROM jos_users'

The bad guy's goal is given those hashes, to determine a password which will allow him to logon as one or more of your users - giving him access to their accounts.

As such, he doesn't care if he get's the "right" password or not, just that he gets A password which will work.  Since most people use the same passwords, straight MD5 hashing which was ok decades ago became depreciated when processing time and disk space became cheap enough for the wide generation of rainbow tables.  Given all password hashes, the bad guy could generally find a number of matches to pre-generated text to hash tables.  

The next choice up was salted passwords, by adding a random string to the password before hashing it, and including it with the password data, existing rainbow tables became useless.  Since the bad guy is reduced to generating a rainbow table for each salt, it's no faster then brute force.... of course this assumes that no one goes out and builds rainbow tables  for each different salt possibility.  Considering GPU's can perform these hashes very quickly, I would no be suprised  if someone has spent a couple hundred dollars for a few days of cluster gpu time and generated a bunch of them.

Beyond that though, there are still many mods to MD5 that can be used.  For one thing, you could store a second salt value in the configuration.php file and use both salts in generating the passwords.  Then a bad guy who manages to get just your user table is out of luck, without the other salt they can't calculate a collision.  

Another option is to apply the same password rules to passwords submitted for authentication as are used for changing passwords. [ie if your rules say 10 charectors, mixed case mandatory and numbers in order to save the password - apply the same rule when someone enters a password for verification.  Therefore if there is a collision which does not match your rules, it can't be used.  For example, given the password thisIsAReallyReally!!LongPassword - presume that by chance 1234 hashes to the same string.  The current mechanism would allow this invalid password to be used to logon as the only check is on the hash, not on the password quality.]

Yet another option is a configurable setting to allow for multiple calls to MD5 during hashing.  This would allow sight owners to decide on their trade off between site performance and security.  Default the setting during installation to a random number between 5 and 10, so not every Joomla site is identical - but allow the site owner to choose a higher number, such as 50, if he wants more security. With this information stored in a config setting somewhere, again rainbow tables are less useful because of the large number of them that must be created.

MD5 is still perfectly fine to use, it's unsalted, single calls to md5 which are to be avoided.

[M. Burnett]

Herman,

 

Thank you for taking the trouble of answering my post. But I think your comment mainly illustrates what I wrote: the mentioned weaknesses of MD5 (collisions, preimage attacks, and susceptibility to birthday attacks) are only in play when the hash is used to authenticate a document . Could you please explain how those methods could be used to speed up a brute force attack to retrieve passwords? I am very interested in it.

As you know, when two different inputs generate the same hash, it's called a collision. Collisions happen in every hash, by definition. The weakness of MD5 (and SHA-1) is, that a collision can be constructed and that the source can be constructed in such a way that it is something meaningful (but not the original text). So, although the original text has been changed (to for instance malicious software of a false contract), it still has the same hash. But that is not relevant for password storage.

Those weaknesses are not only in play when authenticating a document. The issue here is producing a plaintext that matches a given hash. These weaknesses reduce the cracking time by increasing the number of plaintext values that will match or reducing the amount of time spent in a brute force attack. For example, a collision means that more than one password will produce the same hash. Now the collisions in MD5 that we know of are still quite limited but as an extreme example, suppose that you have a 20-character password and find that "1234" also produces that exact same hash. The authentication system doesn't care if you got the actual password, it just cares if the hash matches.


 

I agree that time is running out for MD5 for password storage as it will be surpassed by Moore's law (hardware will be faster and faster). That is exactly the same for the other hashes for they all can be generated too fast. Except BCrypt, which is the only one specially developed to be slow enough and can be adjustable slowed down in time. The bitlength of the hash (128 for MD5, 160 for SHA-1, 184 for BCrypt) only influences the chance to hit a collision earlier than the original password, but not the chance to retrieve the original password (which could possibly be used to break into another system, as is a much heard argument).

While BCrypt can produce exponential growth in effort, there is still linear growth in effort from using SHA256 or higher. There is also the increased memory overhead of working with the higher number of bits. Another cool thing is that if you have a large hash, trying to create a rainbow table for that would require a massive amount of storage.  And again, the attacker does not need the original password, anything that produces the same hash is fine.

 

Except BCrypt all allgorithms need about the same time to find the original password with brute force.

Not really, there can be some significant differences. Here's one example I was looking at recently: http://thepasswordproject.com/_media/performance-differences-pc2-plus007-plus008b40-lite009-lite010b11.png
 

The main factor making a difference is: the length of the password or passphrase, for the brute force time increases (almost) exponential with the length of the password/passphrase. So, the best advice to give to users now, is to make password/passphrase as long as possible.

Yes this sounds great and all the time I write about how password length is the single most important factor of strong passwords. But realistically, there's only so far you can push a user on minimum password length before you get a big backlash. A better solution would be to allow SSO solutions like OpenID and SAML (via Google, Yahoo, Facebook, etc.) so you aren't even storing hashes at all.
 

BCrypt is a good candidate for password hashing for it's adjustable slowness. But it could generate some problems when just put into core Joomla: mainly because the cost-factor cannot be lowered without losing the stored passwords, thus giving some portability-problems earlier referred to. For turning the cost-factor higher, maybe we could write some adapter.

An alternative to BCrypt is to use PHPass which stronger than plain MD5. There is also PBKDF2.

 

I would personally prefer to send a hash (with the salt and a nonce) instead of a cleartext password from the client as referred to earlier (stop sending passwords!), but at the moment there is no Javascript-implementation of BCrypt and the differences in speed of client-side hardware make it almost impossible to find an acceptable cost-factor. For client-side hashing, MD5 is a better option.

I'd actually recommend CHAP. I currently use a CHAP plugin (in addition to SSL) on all my WordPress logins with this plugin: https://wordpress.org/extend/plugins/chap-secure-login/
 

 

There were two arguments you gave, I disagree with:  "When most experts say... etc.". Authority is no valid argument. Hence my citation of Galileo earlier.

Normally I would agree with this, but when it comes to cryptography the rules change :)


Mark

 

[Herman Peeren]

In your patch I see a fixed cost-factor of 12 for bcrypt ($2a$12$ in front of a 22-character salt); so 2^12 iterations. I assume this has to be worked out to an adjustable factor (that might be determined automatically on the hardware the algorithm runs on). Or am I overlooking something?

About the possibility to write some code to adjust the stored hash to a higher bcrypt cost: I'm sure it is possible and I'm convinced you can do that. But it just has to be done, tested, used in practice, finetuned, reworked, attacked, hardened and improved, like the whole thing. That is what I call: it has to mature.

I'm sure it will be great software... in the end.

[Jase Williams]

@Herman

The cost factor is currently fixed at 12 (you can change this in the
source and it (should) still work. Its an 'adaptive' hashing
algorithm, its designed to cope with cost changes.

Yes you're right each hash created will have the $2a$12$ at the start
so the function knows that hash was made with a cost factor of 12. You
simply change the cost factor and new hashes will have a different
number. When someone tries to log in with an old cost factor it will
still work because the 12 was in the hash so the function what cost to
use how many to use.
The factor itself isn't worked out automatically, its just picked by
me. There could be some research done into this to find a 'suits all'
factor to begin with.

In terms of maturity. BCrypt itself is already quite mature, its been
around, tried & tested for the past 10 years (bcrypt was the password
file format for OpenBSD); also integrated into FreeBSD, Solaris and
NetBSD. To this day its not been hacked. So I would say its quite safe
to use.

In terms of a patch. Yes I can add a cast factor change and have it
tested by various members not a problem.
The patch already works quite well, the only thing you can't do is
change the cost factor from the admin end. But you could even change
that in the code and it (should) still work.

My question now is, do we want our users controlling the cost? Or do
we want the cost hard-coded in Joomla?

Let me know if that's confusing, im just trying to answer all your questions.

[Herman Peeren]

On Saturday, 24 March 2012 13:27:05 UTC+1, Jase Williams wrote:

My question now is, do we want our users controlling the cost? Or do
we want the cost hard-coded in Joomla?

 

Because the needed cost-factor is hardware-dependend, it should be calculated on the server where the site is deployed.

Therefore, I think you should not let the users control the cost-factor directly, but it would be nice to keep open the possibility of choosing between medium (recommended), fast and slow password hashing. Could be implemented in different ways; with a slider to make it completely flexible. With an upper and under (estimated) time. For instance: the default setting on 0.5 seconds. The fast one (= faster login, but less secure - which could be quantified) on 0.001 seconds and the slow one on 5 seconds. In this way the user can still choose, but can not choose a factor that makes the site inaccessible (by choosing a factor that would give a login that takes much too long).

From time to time the server would need to recalculate it's performance and redefine it's (rounded) base cost-factor.

These things can also be added later. In a first iteration of this piece of art we could keep the factor to 12. I would just not hardcode it in the getCryptedPassword-function, but retrieve that 12 from another method, that can be worked out later (well, to be honest: I'rather recode the whole helper-class to real OOP, but that's beyond scope now... ).

What I like about your patch is, that it is backward compatible; when a choosen algorithm (or the cost-factor) changes, people can always login the earlier way and after that the hash is recalculated. That is not possible with the client-side MD5-hash we proposed earlier.

[Herman Peeren]

On Saturday, 24 March 2012 06:57:24 UTC+1, M. Burnett wrote:

Here's one example I was looking at recently: http://thepasswordproject.com/​_media/performance-​differences-pc2-plus007-​plus008b40-lite009-lite010b11.​png

Thanks for the link. I didn't know that site http://thepasswordproject.com . I'll quantify some things that have been said in this thread, using performance figures like that. So: how long does a MD5 brute force take nowadays for different password lengths and different algorithms, how many collisions do you have in a hash (using different algorithms). Then we can talk on more precise grounds.

[Jase Williams]

I think the fact that LinkedIn got hacked last week using SHA-1 encrypted passwords with no salt (?) is another good example / reason why Joomla 3.0 should move on to a more robust / secure hashing algorithm.

I will try and update the patch to work with Joomla 3.0 then update the tracker page.

Very good article here:

http://throwingfire.com/storing-passwords-securely/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+throwingfire+%28Throwing+Fire%29#notpasswordhashes

[Rouven Weßling]

Kind of a straw man argument since Joomla does salt its passwords...

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/8MFNrttZDs8J.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[brian teeman]

On Friday, 8 June 2012 10:02:14 UTC+1, Jase Williams wrote:

I think the fact that LinkedIn got hacked last week using SHA-1 encrypted passwords with no salt (?) is another good example / reason why Joomla 3.0 should move on to a more robust / secure hashing algorithm.

Joomla already uses a SALT so what is your point?

[Jase Williams]

I never said Joomla didn't use a SALT.

I was more referring to moving on from the ancient MD5 system when I wrote that.

[Rouven Weßling]

On 08.06.2012, at 11:46, Jase Williams <jase.w...@gmail.com> wrote:

> I never said Joomla didn't use a SALT.
> I was more referring to moving on from the ancient MD5 system when I wrote that.

I understood that but how's LinkedIn a good example to make your case when apparently they didn't salt their passwords?

Best regards
Rouven

[Jase Williams]

Rouven I tell you what.

Just read this:

http://www.zdnet.com/blog/security/md5-password-scrambler-no-longer-safe/12317

Easier than me giving any explanation

[Daniele Rosario]

I think that refers to md5 without salt.

MD5 with salting is still considered safe i believe

Daniele Rosario

--

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

[Rouven Weßling]

If you’ve read my earlier comments on the topic you'd know I'm not against
finding a strategy to move to a different hashing algorithm. I'm just very
much against people using misleading arguments to make their case. The
Linkedin story has nothing at all to do with how Joomla works. SHA1 is
arguably a better hashing algorithm than MD5 however they seemed to have
missed security 101 and didn't salt their passwords - something Joomla has
done at least since version 1.5. This probably the poorest example one can
find to argue Joomla is unsafe.

As for the article you linked, that one's misleading too. The article sounds
like Poul-Henning Kamp developed the MD5 algorithm. That's incorrect, he
just developed a popular software using it. MD5 was developed by Ron Rivest.

Best regards
Rouven

________________________________________
Von: joomla-...@googlegroups.com
[mailto:joomla-...@googlegroups.com] Im Auftrag von Jase Williams
Gesendet: Freitag, 8. Juni 2012 11:55
An: joomla-...@googlegroups.com
Betreff: Re: [jcms] Re: New hashing algorithms for Joomla

[Jase Williams]

"This probably the poorest example one can
find to argue Joomla is unsafe."

I am not arguing that Joomla is unsafe, I know that salted MD5 is 'safe-enough'. Im just reminding that there are better functions out there we can be using.

[Marius van Rijnsoever]

LinkedIn did not use salts and allows for rainbow tables. However this
scenario still applies to Joomla.

Cracking password hashes' is all to do with speed to "guess" the
password. Salt-less obviously allow for direct lookup after creating a
rainbow tables. However with the GPU's being able to brute-force hack
MD5/SHA1 passwords extremely fast, it is not considered very secure
anymore (a cheap graphics card can 600.000.000 MD5 passwords -> per
second <-). Implementing a better algortythm will make hacking
password more time/resources costly and therefore harder or more
secure.

But really the finer details of the argument do not matter. As clients
will ask "how are password stored", if the developer says "Joomla uses
MD5", the client will say -> "I do not want to use Joomla in that
case". Its community perception that matters are well, part due to
incomplete articles.

MD5 is perceived as vulnerable and 99% of people do not understand the
fine print. With PHP now standardly supporting better algorythms,
there is no reason for Joomla not to implement a better system.

Therefore the LinkedIn story does apply to Joomla due to community
perception. Thanks, Marius