WordPress.org

Make WordPress Core

#21420 closed defect (bug) (invalid)

Login without salted MD5 Password

Reported by: shubhamoy Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.4.1
Component: General Keywords: close
Focuses: Cc:

Description

WordPress stores the password in MD5+Salt Format but never uses it for login. Suppose an attacker gets access to the database and updates the password in MD5 hash format and tries to login then he is able to do it successfully. So what's the use of storing the password in MD5+Salt when it doesn't comes into play.

Change History (10)

comment:1 dd3221 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Historically, WordPress stored passwords as an unsalted md5 (#2394), obviously this was insecure in the event that an attacker gained access to the md5'd password.

WordPress allows for those with the old style passwords (hashed md5's) to login using it, and the password is immediately rehashed with the new format and re-saved to the database. This allows for a rolling upgrade when users log in (as since they were stored as md5's, the password was not known, and therefor could not be rehashed until the user logged in).

As a result, if you have access to the database, you can create users, or edit users, and change their password to a unsalted md5 and trigger the upgrade path.

So: WordPress never stores passwords unsalted or in an insecure form anymore (Since 2.5), however, If you have a compromised database server, it's possible to alter users, and gain access to the site. Similarily, if an attacker gains file-level access, they can gain access to the site as well. WordPress is only as secure as the server it's hosted on.

comment:2 shubhamoy21 months ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

The database stores the password in the following way: $P$B.Vpi0aAjSqYg6AILPxrXemVw6Xysa1 and if we replace it with plain MD5 Hash then also it gets accepted and user is able to login whereas in Joomla the database entry must be a salted MD5 hash for a successful login.

comment:3 sirzooro21 months ago

  • Cc sirzooro added

WordPress 2.5 was released over 4 years ago, so most peoples already has this version or never (core devs can confirm if this is true). I think we could remove this functionality now. Just make sure that it is possible to write plugin for this if someone would need it.

comment:4 nacin21 months ago

  • Keywords close added; needs-patch needs-testing removed

While the original benefit of upgrading a straight md5 hash was the rolling upgrade, it still has benefits now.

When people get locked out of their sites, they are often encouraged to update their database manually with a query that could include MD5(password).

They have direct database access anyway, which means they could also calculate the proper portable $P$B hash and update the database row to this, but that also brings up the point that accepting a login against a plain md5 hash cannot possibly be a vulnerability. If you have direct access to the database, you can do anything you want. That we "update" straight hashes to salted hashes is the one absolute must. Beyond that, the only purpose of hashing is to ensure that a leaked DB does not expose insecurely hashed passwords. Changing WordPress to no longer accept and upgrade md5 hashes doesn't make us any more secure.

comment:5 follow-up: shubhamoy21 months ago

The point is that this feature is exploited and I've seen many of clients site have been attacked badly by simply changing the database records.

Sample Attack
=============

An attacker places a SymLink Attack on the server and reads the wp-config.php of a wordpress powered site. After that accesses the database, updates the wp_users table with a simple MD5 hashed password. Logs into admin panel and then takes over the website. Now the feature for the ease of user who forgets the password gets exploited.

So it's time that this hole gets patched else the sites will be attacked in the same fashion.

comment:6 ocean9021 months ago

An attacker places a SymLink Attack on the server and reads the wp-config.php of a wordpress powered site. After that accesses the database

Nothing about a WordPress related issue yet, so there is already something wrong before somebody changes the table.

comment:7 in reply to: ↑ 5 nacin21 months ago

Replying to shubhamoy:

Let me adjust that for you:

An attacker places a SymLink Attack on the server and reads the wp-config.php of a wordpress powered site. After that accesses the database, updates the wp_users table with "$P$B.Vpi0aAjSqYg6AILPxrXemVw6Xysa1". Logs into admin panel and then takes over the website. Now the feature for the ease of user who forgets the password gets exploited.

How is that any different? The server is still compromised either way.

comment:8 shubhamoy21 months ago

@Nacin
If only the salted MD5 hashes are utilized then the attacker wouldn't be able to enter the admin panel. So the attack wouldn't cause much damage.

And backup can be made compulsory on regular intervals to mitigate the situations where a user forgets his/her password.

comment:9 kawauso21 months ago

If you have access to the wp-config.php, then you can use the salts stored there (or in the database) to generate a salted password to store in the database. Am I missing something there?

comment:10 ocean9021 months ago

  • Resolution set to invalid
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.