Tech

A quarter of major CMSs use outdated MD5 as the default password hashing scheme

Offenders include WordPress, osCommerce, SuiteCRM, miniBB, SugarCRM, and others.

Written by Catalin Cimpanu, Contributor June 17, 2019 at 10:48 a.m. PT

Over a quarter of all the major content management systems (CMSs) use the old and outdated MD5 hashing scheme as the default for securing and storing user passwords.

techrepublic cheat sheet

How to become a developer: Salaries, skills, and the best languages to learn

Some of the projects that use MD5 as the default method for storing user passwords include WordPress, osCommerce, SuiteCRM, miniBB, SugarCRM, CMS Made Simple, MantisBT, Phorum, Observium, and X3cms.

This means that unless website owners changed these default settings by modifying the CMS source code, most websites built on top of these CMSs puts user passwords at risk in the case a hacker steals the site's database.

Study on default password hashing schemes

This revelation is just one of the many observations that came out of an extensive academic research project at the University of Piraeus, in Greece.

Academics examined 49 commonly used CMSs and 47 popular web application frameworks and looked at their default password storage mechanism, namely their password hashing schemes.

Password hashing is the operation of taking a plaintext user-provided password and converting it into a jumble of seemingly-random characters that are stored inside a database, without exposing the user's real password.

Password hashing schemes usually involve three things: a password hashing function, iterations, and a salt string.

The core parameter of a hashing scheme is the employed hash function. This is where terms like MD5, SHA1, SHA256, SHA512, PBKDF2, BCRYPT, SCRYPT, or Argon2 all fall in.

Second is the number of iterations a hashing function is applied to a cleartext password. The larger the iterations, the harder it gets for an attacker to reverse the algorithm by requiring a large amount of computational power.

Third, the salt string is an optional parameter in hashing schemes that are used together with the hashing function to produce even more random results. When a salt string is used, an attacker must know both the password and the salt string before attempting to reverse a hashed password. This protects site databases against blind password-guessing attacks, but not against situations where attackers also steal users' salt strings.

It's because of this carefully balanved system that websites, web, mobile, and any other application must use a strong password pashing system to safeguard user data.

Currently, weak are considered hashing functions that have been already broken, like MD5 and SHA1, while strong are highly-complex and newer systems like BCRYPT, SCRYPT, and Argon2.

CMS analysis

But the reality is that most CMS projects and coding frameworks aren't always designed with security in mind.

The University of Piraeus research team found that nearly 60% of the tested CMS used a weak hashing function (like MD5 or SHA1), or hashing functions like SHA256, SHA512, PBKDF2, which "can be highly parallelized with GPU hardware, making password guessing attacks easier."

Of the CMS projects that used an MHF (memory hard function), all used BCRYPT. This accounted for 40.82%, including big names like Joomla, phpBB, Vanilla Forums, vBulletin, and SilverStripe.

No CMS project used SCRYPT or Argon2. The research team argued that the reason nobody used SCRYPT was because there was no native PHP library available, meaning that most CMS projects -- which are coded mostly in PHP -- couldn't support it in their code.

Second, Argon2 was only recently added in the PHP 7.2 release, and it might take a while before it gains widespread adoption, as more servers move from the older PHP 5.x branch to the newer 7.x.

Default password hashing schemes for CMSs — Image: Ntantogian et al.

In addition, the usage of salt wasn't 100% widespread as one might expect. Per the research team, 14,29% of the tested CMSs did not salt their hashing scheme, leaving users vulnerable to rainbow table attacks.

Even worse, a larger chunk, 36.73% of the tested CMSs did not employ iterations for the hashing function, meaning the cost of breaking (cracking) users passwords would likely be a small one.

Furthermore, 38.78% of the tested CMSs did not enforce a minimum password length policy, which would result in users selecting weak passwords.

Allowing users to select weak passwords negates the effect of using strong password hashing schemes, as attackers can utilize basic dictionary attacks against a site's login form to guess the password without ever needing to get hold of a hashed password to crack it.

Notably, in this category we have some pretty big names, such as WordPress and Drupal, both of which currently allow for one-character-long passwords.

Framework analysis

But CMS projects, which provide a visual interface for building websites, weren't the only ones tested for this research.

So were web application frameworks, which provide source code libraries on which more customized websites can be built, but without the aid of a GUI and backend panel.

"23.40% of the web application frameworks opt for weak (i.e., parallelizable) hash functions, while 12.77% of them do not use iterations," the research team said.

"What is more, only 27.66% use the BCRYPT hash function by default. Similar to CMS and observation 2, SCRYPT and Argon2 are absent from the default settings."

Furthermore, unlike CMS projects, where a default password hashing scheme is selected for the website owner by default -- otherwise the CMS won't run properly -- some coding frameworks don't have a default password hashing scheme selected, and leave this to the developer.

"48.94% of the investigated web application frameworks do not offer a default password hashing scheme, which might lead to the selection of a weak password hashing scheme in web applications," researchers said.

Passwords frameworks — Image: Ntantogian et al.

The conclusions of this research project are quite easy to see just by looking at the numbers. Most CMSs and web application frameworks do not provide defaults that are secure enough.

Security

Since not all CMS users are programmers, this will result in websites that store user passwords using outdated password hashing schemes, putting user data at risk.

Normally, one might think that web application frameworks would have better numbers, and a better security posture since programmers are the only ones capable of using these tools.

However, leaving the selection of a secure password hashing scheme to programmers is also a bad decision -- according to a different study, performed by the University of Bonn in Germany, and published in March this year.

The study showed that programmers will often take the easy way out and not implement proper password security, choosing weak password hashing schemes, and skipping on implementing password salting.

All in all, the Greek researchers argue that CMS projects and web application frameworks should come with strong defaults for the password hashing scheme, and let developers downgrade in case of technical problems.

More details about the University of Piraeus research are available in a white paper named "Evaluation of password hashing schemes in open source web platforms."

Updated on June 18: After the publication of this article, the developer teams from Simple Machines Forum, MyBB, and Composr told ZDNet that their CMSs have moved on to more advanced hashing schemes as opposed to the ones analyzed by the research team. All three now use bcrypt.