Lengthen password field for protected posts

[ScytheBlade1]

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...

[ScytheBlade1]

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.

[skippy]

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

[Nazgul]

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.

[nacin]

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

[iandunn]

+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.

[pento]

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.

[wonderboymusic]

for whenever

[chriscct7]

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.

[pento]

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.

[adamsilverstein]

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!

[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.

[DrewAPicture]

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.

[adamsilverstein]

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.

[pento]

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.

[adamsilverstein]

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!

[adamsilverstein]

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!

[pento]

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.