As I was explaining in my first blog post at zorinaq.com, I would have liked to feel more comfortable about the security track record of the blog CMS I am using, PivotX. Today I started poking around and discovered the first security flaw. Like many web apps, PivotX hashes user passwords in an insecure way; it fails to implement password stretching. Its algorithm is just a basic salted MD5:
hash = MD5(password . salt)
where salt is 32-character string of random hexadecimal digits
Consequently, brute-forcing PivotX password hashes is very fast. For example ighashgpu can bruteforce this type of salted MD5 hash at a speed of about 3.3 billion passwords per second on a ATI HD 5870. PivotX hashes are stored in this file:
pivotx/db/ser_users.php:
...s:8:"username";s:5:"alice";
s:8:"password";s:32:"a8d96f2acf34505cc70fabf7acbd9be8";
s:4:"salt";s:32:"c9c132159c943876f6a1753102937d9a";...
The user/pw is alice/test and the hash can be verified with:
$ echo -n testc9c132159c943876f6a1753102937d9a | md5sum
a8d96f2acf34505cc70fabf7acbd9be8 -
Password stretching, or iterated hashing, is a technique to slow down brute force attacks. It consists of a primitive (a hash function) through which the password and the resulting hash is fed multiple times. Password stretching is standard in many areas: UNIX user accounts (MD5-based or Blowfish-based crypt), PGP-encrypted files (Iterated and Salted S2K), WPA PSK mode (iterated HMAC-SHA1), etc. PivotX has no reason to not implement it.
I believe the reason many web apps get password hashing wrong is because web developers are usually unfamiliar with this topic.
[Updated: I reported the issue to the PivotX developers, and it appears they were aware of the issue. A simple lack of prioritization explains why it was not fixed earlier. They seem knowledgeable about the topic and promised a fix in PivotX 2.1.0.]