WordPress.org

Make WordPress Core

Opened 16 years ago

Closed 4 years ago

#881 closed enhancement (fixed)

Lengthen password field for protected posts

Reported by: ScytheBlade1 Owned by: pento
Milestone: 4.7 Priority: normal
Severity: normal Version:
Component: Database Keywords:
Focuses: Cc:

Description

You know, if you lengthen the database column size to 32 and then just md5() it, users essentially would have unlimited password length for a post. However, since I take it that the ability to actually see the password that you input is enjoyed in wordpress, increasing the max length to 50 or so would be greatly appreciated.

It's just that 20 is so short...

Attachments (5)

patch (969 bytes) - added by ScytheBlade1 15 years ago.
881.patch (629 bytes) - added by skippy 15 years ago.
881b.diff (693 bytes) - added by Nazgul 14 years ago.
881.4.diff (2.0 KB) - added by iandunn 7 years ago.
881.diff (3.6 KB) - added by adamsilverstein 5 years ago.

Download all attachments as: .zip

Change History (36)

#1 @ScytheBlade1
16 years ago

  • Patch set to No

#2 @ScytheBlade1
16 years ago

Actually, a possible idea as to implimentation:

1) On the side of the password area, add a checkbox labeled "Encrypt Password". Make it a link to documentation explaining:
-That by checking this box, you have no way of obtaining your password again, less resetting it
-This also allows you to enter passwords much greater than 20 in length
When this box is checked, and you're editing the post, the password box should display "[Encrypted]". When the form is submitted, if that field has changed at all from that string, simply update the password.
2) Just the same, make it at least 50 for plaintext. I tend to use phrases instead of passwords, that go along with the post title.

I made the change locally in my database (to raise the limit to 50), it really is a "why not" thing. The encryption option is only an added bonus that's easily implimented alongside it.

#3 @ScytheBlade1
16 years ago

  • Keywords patch removed

@ScytheBlade1
15 years ago

@skippy
15 years ago

#4 @skippy
15 years ago

  • Component changed from General to Optimization
  • Keywords bg|has-patch bg|commit bg|squashed added
  • Owner changed from anonymous to skippy
  • Status changed from new to assigned

added 881.patch, svn diff against wp 1.6 snapshot. dbdelta should roll this out in upgrade.php

#5 @markjaquith
15 years ago

  • Milestone set to 2.1

@Nazgul
14 years ago

#6 @Nazgul
14 years ago

  • Keywords has-patch commit added; bg|has-patch bg|commit bg|squashed removed
  • Owner changed from skippy to Nazgul
  • Status changed from assigned to new

I refreshed the patch. It's now in par with the password length for users.
It doesn't seem logical to have different maximum password lengths for both.

As this ticket has been sleeping for some time I'd let the encryption part slide. If somebody wants that, they can open a new ticket and code it.

#7 @matt
14 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

#8 @Nazgul
13 years ago

  • Milestone 2.1 deleted

#9 @nacin
7 years ago

  • Milestone set to Awaiting Review
  • Resolution wontfix deleted
  • Status changed from closed to reopened

I am here from the future. (#24792.) Re-opening to consider lengthening the field.

#10 @iandunn
7 years ago

  • Cc ian.dunn@… added

#11 @iandunn
7 years ago

+1 for lengthening the field. 20 characters isn't long enough to use passphrases, and this is a use case where passphrases are better than passwords because they're easier for the post author to share with the intended readers.

I can see both sides of the argument for encrypting them. On the one hand, we know that the user wants the keep the post a secret, and sending the password plain-text over the network when creating and viewing makes it vulnerable.

On the other hand, encrypting it is probably overkill for the majority of use cases, and would lead to confusion since it's always been displayed to the author in the past. Authors aren't likely to write it down, so they'd have to reset it if they forgot it.

I'm leaning towards leaving it unencrypted, and letting someone write a plugin to encrypt them for people who want that.

Attaching a refreshed patch.

@iandunn
7 years ago

#12 @nacin
7 years ago

  • Component changed from Optimization to Database
  • Milestone changed from Awaiting Review to Future Release

#13 @pento
7 years ago

This won't be a fun thing to roll out. On MySQL 5.5 with a 1 million row table, the ALTER took 21 seconds with MyISAM and 55 seconds with InnoDB.

#14 @iandunn
7 years ago

  • Focuses performance added
  • Keywords commit removed

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


6 years ago

This ticket was mentioned in IRC in #wordpress-dev by simonwheatley. View the logs.


6 years ago

#17 @chriscct7
5 years ago

  • Focuses performance removed
  • Keywords dev-feedback added

#18 @wonderboymusic
5 years ago

  • Owner changed from Nazgul to pento
  • Status changed from reopened to assigned

for whenever

#19 @chriscct7
5 years ago

If WordPress's upgrade routine used a pagination system like EDD and many other popular plugins used, the 60 seconds wouldn't be so bad.

#20 @pento
5 years ago

Yup. That's going to take a bunch of work on the upgrade routines, which aren't all that high on my list right now.

If anyone wants to tackle that, I'm always happy to review code and make suggestions, though.

This ticket was mentioned in Slack in #core by chriscct7. View the logs.


5 years ago

@adamsilverstein
5 years ago

#22 @adamsilverstein
5 years ago

881.diff is an alternate approach, no database update required:

  • when storing the password, create an md5 of the password, truncating it to 20 characters. This should still provide significant entropy for a simple password (see this gist) and has to be more secure than storing plaintext passwords
  • on the login side, add a new hashed password cookie, retaining backwards compatibility with plaintext passwords already stored in the database
  • remove the maxlength limit from the password entry field (note: the quick edit edition of this field _never_ had this limit, and entering a long password there currently fails)
  • no longer display password in the post publish meta box. it was a bad idea to begin with and since we are hashing the password, we can't display it, thats why its secure.

Verified this all works locally with old and new passwords, some unit tests would be great to help validate the approach.

Feedback welcome!

Last edited 5 years ago by adamsilverstein (previous) (diff)

#23 follow-up: @chriscct7
5 years ago

  • Component changed from Database to Security

While this might involved a database change (possibly, depending on what approach is taken), I think this issue would be best served in the security component (as it deals explicitly with password storage), at least until the issue is for-sure going to require a database change.

Last edited 5 years ago by chriscct7 (previous) (diff)

This ticket was mentioned in Slack in #core by adamsilverstein. View the logs.


5 years ago

#25 in reply to: ↑ 23 ; follow-up: @DrewAPicture
5 years ago

  • Component changed from Security to Database
  • Keywords needs-patch added; has-patch dev-feedback removed

Replying to chriscct7:

While this might involved a database change (possibly, depending on what approach is taken), I think this issue would be best served in the security component (as it deals explicitly with password storage), at least until the issue is for-sure going to require a database change.

I'm gonna have to go ahead and sort of disagree with you there. I think this is a database issue and we should realistically lengthen the field and inputs to 191 characters and walk away.

Plus, the field is already filterable via the field filters in sanitize_post_field().

Per the hashing suggestion, I don't think we need to go there – specifically because I think people are going set passwords and will expect to be able to retrieve them later, which hashing would nix.

#26 in reply to: ↑ 25 ; follow-up: @adamsilverstein
5 years ago

Replying to DrewAPicture:

Plus, the field is already filterable via the field filters in sanitize_post_field().

Good point - it should be possible to achieve the same more secure passwords using filters, I will try to work on some sample code. Although I disagree with the decision to show plaintext passwords anywhere, I can see this isn't going to change any time soon.

I like the suggestion of just lengthening the database field. I know these types of database schema changes are rare, however we do make them. @pento you said "This won't be a fun thing to roll out." - can we still roll it out some day soon? Would you really like to see a paginated update routine to have this fly? What have we done with other db schema changes in the past?

One current bug to note is the quick edit field which has no restriction on length: entering a long password there fails silently.

#27 in reply to: ↑ 26 ; follow-up: @pento
5 years ago

Replying to adamsilverstein:

I like the suggestion of just lengthening the database field. I know these types of database schema changes are rare, however we do make them. @pento you said "This won't be a fun thing to roll out." - can we still roll it out some day soon? Would you really like to see a paginated update routine to have this fly? What have we done with other db schema changes in the past?

In the past, we've just done the schema change during upgrade. The utf8mb4 upgrade, for example, turned into a bit of a shambles - sites regularly having upgrade problems because their connection timed out while the schema changes were still occurring.

Given that experience, I'm inclined to call my figures a severe underestimation - they were done on a server with no load, any extra load will cause more downtime while MySQL tries to gain the necessary locks.

Now, it's not possible to avoid that downtime (unless you're using MySQL 5.6, which would allow this ALTER TABLE as an online DDL), but I think it's necessary for us to provide a much better UI for these long running schema changes (and better feedback in the event of something going wrong) before we can look at making another change.

#28 in reply to: ↑ 27 @adamsilverstein
5 years ago

Now, it's not possible to avoid that downtime (unless you're using MySQL 5.6, which would allow this ALTER TABLE as an online DDL), but I think it's necessary for us to provide a much better UI for these long running schema changes (and better feedback in the event of something going wrong) before we can look at making another change.

Thanks for the explanation; here seems like as good a place as any to work out the details of an incremental schema change UI. Lets keep working on it!

#29 @adamsilverstein
5 years ago

Related #33904, where we increased the password field length for users. Thinking the DB change makes the most sense, lets work on the UI for long running schema changes to make this happen!

#30 @pento
4 years ago

  • Keywords needs-patch removed
  • Milestone changed from Future Release to 4.7

#31 @pento
4 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 38590:

Database: Increase the size of wp_posts.post_password to 255 characters.

Longer passwords and passphrases are much more common than when post passwords were introduced all those eons ago, so let's increase the length of the post_password field from 20 to 255 characters.

The password will continue to be stored in plaintext, as the ability for the post author to view the password is a commonly used feature.

Trivia: this was the last 3 digit Trac ticket to be closed.

Props skippy, nazgul, iandunn, adamsilverstein, pento.
Fixes #881.

Note: See TracTickets for help on using tickets.