Skip to content
Naked Security Naked Security

Pass the salt! Popular CMSs aren’t securing passwords properly

A group of researchers has discovered that many of the web's most popular content management systems are using obsolete algorithms to protect their users' passwords.

A group of researchers has discovered that many of the web’s most popular content management systems are using insecure algorithms to protect their users’ passwords.

Three researchers from the Department of Digital Systems at the University of Piraeus in Greece tested several CMS products [article behind paywall] to see how well they hashed user passwords.

Hashing is a mathematical function that encodes a secret. It takes an alphanumeric string such as a password and uses it to produce another string, called a digest.

A hashing function is a one-way street. You can calculate the digest easily using the password, but you can’t calculate the password using the digest.

That makes it great for storing passwords securely. When a user logs in using their password, the web application can quickly hash it. If the digest matches the one on file, the user gains access. Yet if anyone steals the password database, they can’t read it. (Although hashing is fundamental to good password security, there’s more to it than that – for a detailed primer see how to store your users’ passwords safely.)

Unfortunately, CMS software often doesn’t use hashing properly, the researchers warned. stating:

We have discovered that many CMS use outdated hash functions.

What does this mean?

Not all hashing functions are equal. MD5 (invented by Ron Rivest, who is the ‘R’ in RSA), has been compromised. A hashing function should produce a unique digest for every different input. No two passwords should produce the same digest (a situation referred to as a collision). The first successful collision attack against MD5 was conducted in 1996 and generating MD5 collisions is now considered easy.

Another popular hashing function, SHA-1, was widely used as a replacement when MD5 fell out of favour. That too is now considered obsolete.

The University of Piraeus researchers looked at 49 content management systems and 47 web application frameworks. It reported that 26.5% of them used MD5. These included osCommerce, SuiteCRM, WordPress, X3cms, SugarCRM, CMS Made simple, MantisBT, Simple Machines, miniBB, Phorum, MyBB, Observium, and Composr.

A further 12.2% of them use SHA-1. The culprits there are GetSimple CMS, Redmine, Collabtive, PunBB, Pligg, and Omeka.

The danger here isn’t just that these hashing functions are vulnerable to collision attacks. They’re also highly susceptible to the use of graphical processing units (GPUs), which can divide up the processing necessary to target them among their many processor cores.

Some of these sites had even worse problems. The researchers cited…

an arbitrary number of hash iterations, while there is a lack of password policies and salt

Hashing alone won’t defeat an attacker. In modern password hashing algorithms passwords are combined with a salt (a random string of data) so that identical passwords produce different hashes. Typically, the output of the hashing function is itself then mixed with the salt and hashed again, and again and again, perhaps thousands of times, to make the operation computationally expensive.

Each pass through the salt and hash routine is called an iteration. The higher the number of iterations, the harder it is for password cracking computers to generate password matches quickly.

Some of these systems using MD5 or SHA-1 endangered users further by not using salt or iterations. X3cms 0.5.3, GetSimple, MiniBB 3.2.2, and Phorum were on that naughty list.

The most secure CMS systems from a hashing perspective used bcrypt, a password hashing function which is resistant to GPU-based parallel computing cracks. On the nice list are Joomla, Zurmo, OrangeHRM, SilverStripe, Elgg, XOOPS, e107, NodeBB, Concrete5, phpBB, Vanilla Forums, Ushahidi, Lime Survey, Mahara, Mibew, vBulletin, OpenCart, PrestaShop, and Moodle.

It should be noted that the weakness affects how quickly an attacker can guess the contents of password database they have stolen from a breached website. It doesn’t affect their ability to breach the website in the first place or to guess passwords at the login prompt.


I have a question about where the salts used come from. I always hear about random salts but how is a salt usually generated and where is it stored? Thanks.


Salts can be generated by any cryptographically secure pseudo-random number generator. It’s not a secret like the password, it’s just there to ensure that two identical secret passwords don’t result in the same hash, so it can be stored in plain text in the database alongside the username and password hash.


Thanks Mark x 2 – a clear explanation of why a) a salt need not be encrypted and b) why they’re used. Quite a clever solution to ensuring that two ‘base’ passwords don’t result in the same hash. I’m presuming this then negates the use of rainbow tables to find passwords: is that true?


Yes – you need one rainbow table *per salt*, so the rainbow table is a complete waste of time and space given that you can’t use it again.


What would be the final ideal solution to prevent problems like these (some old server/applications on the internet not keep up with security standards ?) . Could browsers (through some means) play any role in ensuring the application/server the user is trying to speak to uses a secure hash function (ofcourse, with salt) to store passwords .


There is no mechanism for browsers to do that, and even if they could they would still be left trusting some kind of response generated by the server that amounts to “yeah, sure, we’re hashing properly”. If you want to know how that would turn out, take a look at the Do Not Track debacle.

The fundamental problem is that with passwords you have to share a secret with a server and trust it to look after that secret for you. You cannot force the admins to do it well, can’t see if they’re doing it well, and can’t see if they’re keeping up. Even if a site is doing it ‘right’ by using bcrypt, for example, it needs to keep doing it right by ratcheting up the iterations, year-on-year, to match improvements in computing power per dollar.

The ultimate solution is WebAuthn/FIDO2, which uses public key cryptography for authentication and does not require the web server to store a password or any other secrets. If a site is breached the crook gets your public key, which is of no value at all.

For more, see The passwordless web explained:


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!