WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 weeks ago

Last modified 3 weeks ago

#11813 closed defect (bug) (wontfix)

Post password stored as plaintext

Reported by: ericmann Owned by: ryan
Milestone: Priority: normal
Severity: normal Version: 2.9.1
Component: Security Keywords:
Focuses: Cc:

Description

When a user specifies a password for a protected post it's stored as plaintext in the database. Considering the rate at which people recycle personal passwords, does this open a user's site to potential security risks?

While not necessarily our responsibility, this would raise issues if they use the same password for a login and for their protected posts.

Change History (10)

comment:1 scribu4 years ago

  • Milestone changed from Unassigned to Future Release

I see no harm in doing at least a simple md5() on the password. (It shouldn't be the same hashing function used for user passwords)

comment:2 filosofo4 years ago

As suggested for private posts in #11695, it might be nice to move password stuff into a "canonical" plugin. Currently it's pretty hacky.

comment:3 filosofo4 years ago

Or better, I should link to #11697

comment:4 follow-up: nacin19 months ago

Perhaps we can block post passwords if when hashed it is the same as their user password...

comment:5 in reply to: ↑ 4 ericmann19 months ago

Replying to nacin:

Perhaps we can block post passwords if when hashed it is the same as their user password...

That would be an excellent short-term solution that would increase security (protect users from themselves, really). But I'm still somewhat uncomfortable storing anything that resembles a password in plaintext.

comment:6 follow-up: nacin19 months ago

It's something that is designed to be shared, so storing it hashed is pretty much a no-go. People will need to refer to it, change it, etc. There is a reason why we store it in a type=text field, rather than type=password. That alone should probably scare most people away from entering a full password.

Perhaps calling it something other than a "password" would also help, but that ship has sailed.

comment:7 in reply to: ↑ 6 ; follow-up: ericmann19 months ago

Replying to nacin:

It's something that is designed to be shared, so storing it hashed is pretty much a no-go.

Good point.

Perhaps calling it something other than a "password" would also help, but that ship has sailed.

Perhaps we could rename it in a future release? It won't be the first time we've renamed a feature. (Admin bar => toolbar)

comment:8 in reply to: ↑ 7 ; follow-up: ericlewis3 weeks ago

Replying to ericmann:

Perhaps we could rename it in a future release? It won't be the first time we've renamed a feature. (Admin bar => toolbar)

I don't see too much benefit here. At the end of the day, it is a password. Calling it by any other name wouldn't be as descriptive.

I suggest we wontfix this.

comment:9 in reply to: ↑ 8 ericmann3 weeks ago

  • Keywords post-password removed
  • Resolution set to wontfix
  • Status changed from new to closed

Replying to ericlewis:

Calling it by any other name wouldn't be as descriptive.

I suggest we wontfix this.

It's been a while since I considered this an issue, so I'm given to agreeing with you. Closing as wontfix unless someone else wants to make a compelling argument.

comment:10 helen3 weeks ago

  • Milestone Future Release deleted
Note: See TracTickets for help on using tickets.