PivotX Security Flaw: Insecure Password Hashing

[mrb]

I noticed that, like in many web apps, PivotX user passwords are hashed in an insecure way without using password stretching. The algorithm is a simple:

hash = MD5(password . salt)
where salt is 32-character string of random hexadecimal digits

This is not good as this is way too easy to brute force.
http://blog.zorinaq.com/?e=8

[hansfn]

I'll reply properly later today, but everyone - please relax - this isn't a big issue in normal circumstances. PivotX isn't insecure.

However, mrb, is right. PivotX should improve it's password handling. There is no reason PivotX should be any less secure than for example Drupal.

[Bob]

Hi,

I wouldn't go as far as calling this 'insecure'.

You're right that it might be feasible to find the password in a given time, but that doesn't mean that it's a security risk.

Look at it from the other way: You assume that the 'cracker' already has the hashed password and the salt. If somebody already has access to the ser_users.php file, he's basically already capable of doing anything in PivotX, rendering this entire point moot. If the cracker does not have access to this file, brute-forcing is not very feasible.

Don't mistake me: We take security very seriously, so if you have any advice on how we can implement key strengthening in a good way, please let us know. Preferably without invalidating the current passwords.

By the way: I haven't looked into this recently, but do you know if other systems like phpbb, wordpress or Joomla even do salting? Last time i did research on this, they all just MD5-ed the passwords, or used a reversible crypting.

[mrb]

If somebody already has access to the ser_users.php file, he's basically already capable of doing anything in PivotX, rendering this entire point moot

Not entirely true. As a security professional, when doing a pen test and when I find a way to get read-only access to the files of a web app (eg. ser_users.php), or its database, or whatever (eg. by an arbitrary file inclusion vuln, or a limited SQL injection flaw that doesn't for some reason allow me to change hashes), then I focus my efforts on breaking hashes, which then give me more access (eg. the full privileges to a certain account). Password stretching would prevent me, or significantly slow down my attempt at brute forcing hashes. A good example of this is the recent PHPBB hack (back in Feb 2009 IIRC) where an attacker got access to its list of 400 thousand MD5 hashes and basically broke many user passwords.

Also, many users tend to re-use passwords on other systems, other websites, etc. So being able to compromise their PivotX password hashes gives me access to these other systems sharing the same password.

Basically, by itself this vulnerability is not "major", but as always you should think of the whole picture, and the concept of "defense in-deth" suggests that you should implement password stretching.

Now as far as recommendations goes, I recommend not re-inventing the wheel, but reusing an existing secure password hashing algorithm. For example PHP's builtin crypt() function implements some of the best hashing algos out there (see http://php.net/manual/en/function.crypt.php):
* CRYPT_SHA512 (most secure)
* CRYPT_SHA256
* CRYPT_BLOWFISH
* CRYPT_MD5 (less secure, but still very good and perfectly acceptable)

Update the user's password hash from the old format to the new format at the first login. I believe that's how Drupal handled the hash algo change: http://drupal.org/node/29706

[hansfn]

Argh, you posted just before me, mrb. I'll post my reply anyway.

@mrb: We do take security seriously and I'll resolve this before the PivotX 2.1.0 release - the next release. It's not that we are unfamiliar with password hashing or security in general - I have had a copy of the Portable PHP password hashing framework (phpass) inside my PivotX development directory since October 2008 - I have just been lazy/busy. (I even looked at phpass back in 2007 - proof.) I know it's a lame excuse. Personally, I don't think PivotX is doing that bad security wise, but thanks a lot for pushing us to become even better.

@bob: I'm sorry, but we have been too lazy. Both Drupal and Wordpress uses code based on the Portable PHP password hashing framework - ref http://www.openwall.com/phpass/ The efficiency of brute force attacks have improved drastically after they started to use GPUs for the calculations, and we have just not kept up with the development.

Some background information for normal PivotX users:

As Bob already mentioned this insecurity is only relevant if someone gets their hands on the file db/ser_users.php. It means that the attacker has access to your web server, maybe because your FTP password is stolen, and IMHO that is much, much worse than the attacker getting your PivotX password. However, if you run a PivotX install with many users, this issue is more important since these users' password might be exposed too.

A user database (either a file like in PivotX or a SQL database like most other CMS) can handle password in (at least) four different ways:

1. Storing the password in clear text. If an attacker gets access to the user database, he has all passwords immediately. This is of course unacceptable, and some programs still do this. (Pivot/PivotX has never done this.)
2. Storing the hash of the password. If an attacker gets access to the user database, he has to brute force (guess) the password. This became quite easy after the invention of rainbow tables. (Pivot 1.4, not PivotX, only hashes the passwords and is vulnerable to this attack - unfortunately.)
3. Storing the hash of the password and a random salt. If an attacker gets access to the user database, he has to brute force (guess) the password but because of the salt this is much harder.However, using the processing unit in modern graphic cards (GPU) this has also become doable. PivotX 2.0 is using the hash of the password and a random salt, and is vulnerable to this attack - unfortunately.
4. Storing the hash of the hash of the hash ... or stretching the password/key as it is also called. This makes it much, much slower to brute force the password. This is what we will add to PivotX 2.1.

A final point: PivotX is blocking IP addresses after a low number of failed attempts. So even with a distributed attack trying to brute force guess the password, by trying to log in through the web interface, will fail - unless your password is very weak, but then you are "doomed" anyway.

@mrb: Something you want to add to make it even clearer for normal users?

[mrb]

hansfn, I too think PivotX is not doing that bad, hence why I chose it for my blog You obviously seem knowledgeable about the matter, and a top-notch developer. I apologize if my comment about "web developers unfamiliar with this topic" hurt you. Keep up the good work!

I think you summarized the issue perfectly. I have nothing to add.

[hansfn]

FYI: PivotX 2.1.0 will use the Portable PHP password hashing framework. It was added in revision 2774. (It is not included in the latest beta, 2.1.0 beta 7.) This means that PivotX is as secure as Drupal, Wordpress, phpBB3, and more, when it comes to password hashing. It should also be noted that PivotX uses the Portable PHP password hashing framework unaltered.

[_Allen]

And don't forget to mention it on the about page (Used libraries/tools)

[hansfn]

No, worries, _Allen - it was my intention all the time, but phpass isn't used in a released version yet.

[Bob]

I was pleased to see PivotX is already listed on the PHPass site: http://www.openwall.com/phpass/