WordPress 4.7 to Allow 255-Character Passwords for Protected Posts

photo credit: Padlock - (license)
photo credit: Padlock(license)

WordPress users who protect posts with passwords will soon have the option to make their passwords more secure. The upcoming 4.7 release brings resolution to a 12-year old ticket requesting an increase in the number of characters allowed for passwords on password-protected posts. Users will now be able to protect their posts with 255-character passwords, an increase from the previous 20 characters.

Security experts are still divided on whether complexity or length is more essential for password strength. Most of us have been told that more complex passwords are always more difficult to crack. However, a thought-provoking article on the Microsoft TechNet blog suggests that a required password complexity only prevents users from creating easy-to-guess passwords but has the negative affect of reducing the total number of possible passwords in a key-space.

The article explores a formula for calculating bits of entropy (the mathematical measurement, in bits, of how difficult it is to crack a password): log(C) / log(2) * L where C is the size of the character set and L is the length of the password. Using this formula, the article makes two conclusions:

  • Mathematically, the LENGTH of the password is exponentially more important than the complexity of the character-set used.
  • ANY complexity rule, to include defining a required number of numbers, letters, specials, etc., actually increases a password’s ability to be cracked.

With this formula in mind, WordPress contributors’ decision to increase the size of wp_posts.post_password to 255 characters gives users the opportunity to create longer, more secure passwords.

“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,” Gary Pendergast said in the commit message. Since post authors expect to be able to view the passwords they assign to posts (and often don’t write them down), it will continue to be stored in plaintext.

This update only affects password-protected posts. WordPress user passwords don’t share the same length restrictions and can be upwards of 1,000 characters long if so desired.

14

14 responses to “WordPress 4.7 to Allow 255-Character Passwords for Protected Posts”

  1. Since post authors expect to be able to view the passwords they assign to posts (and often don’t write them down), it will continue to be stored in plaintext.

    What’s wrong with encrypting the password before storing in the database, and decrypting upon retrieval?

    • Encrypted passwords (as opposed to hashed passwords, which can’t be decrypted, and which WordPress uses for user passwords, for example) have very little security value in this instance. The decryption key would need to be stored with WordPress (probably in the wp-config.php file), so in the event of a server breach allowing MySQL access, it’s reasonably likely they’d have access to the key, too. At the very least, they’d have access to the post content.

      There are also downsides to encrypting the password:
      – If the decryption key is ever changed, every password on every post would need to be changed.
      – The passwords aren’t readable if you’re browsing the database – that’s a significant change from being able to see them from phpMyAdmin.

  2. The sad part of this is that it took them 12 YEARS to decide to do this.

    12 YEARS!!!!!

    I’m rarely surprised by the ridiculous things that core does. This one comes close.

    • You get it wrong, the sad thing is that this information is still cluttering the post table while very few people even know about this feature (do themes outside of the repository actually support it at all?). 12 years of “decisions, not options” and no one thought about making this feature a plugin and getting it out of core.

      result: rest api will take more time because there needs to be a feature parity between what it can do and what you can do in the admin, so the developers have to spend more time implementing it :(

  3. As always the devil is in the details:

    All of the aforementioned assertions assume the passwords are generated by a cryptographically secure algorithm and not stored in a reversible-encrypted or clear-text format.

    If we are talking human generated passwords or passphrases of any length then they tend to be predictable and that formula for calculating entropy does not apply to them. To quote one cryptographer:

    People who haven’t worked on password cracking have this quaint notion of running a little dictionary file through a program… and this would have been accurate in 1990 for someone cracking at your unix-crypt uni shell account. Today the tools are significantly better and have been refined through the disclosure of hundreds of millions of unencrypted passwords and the same kind of statistical tools that power speech recognition and automatic human language transaction.

    G. Maxwell

  4. As always the devil is in the details:

    All of the aforementioned assertions assume the passwords are generated by a cryptographically secure algorithm and not stored in a reversible-encrypted or clear-text format.

    If we are talking human generated passwords or passphrases of any length then they tend to be predictable and that formula for calculating entropy does not apply to them. To quote one cryptographer:

    People who haven’t worked on password cracking have this quaint notion of running a little dictionary file through a program… and this would have been accurate in 1990 for someone cracking at your unix-crypt uni shell account. Today the tools are significantly better and have been refined through the disclosure of hundreds of millions of unencrypted passwords and the same kind of statistical tools that power speech recognition and automatic human language transaction.

    G. Maxwell

  5. Since post authors expect to be able to view the passwords they assign to posts (and often don’t write them down), it will continue to be stored in plaintext.

    Wait. What?

    Slacking so blatantly on security only because of convenience is scary when it’s part of a platform powering 25% of the web.

    I’d never use post passwords myself as the idea seems counter-intuitive.
    The author would have to share the password to everyone he’d want to give access to the post, and he’d most likely do it over an insecure channel. If the password hasn’t been eavesdropped by then, it only takes 1 naive or malicious user to create a breach.

  6. I’m guessing this is more for questionable sites maybe? Even then, those sites would be password protected period. Not just per post. I’m struggling to figure out who in the world password protects a post? I can’t think of any good reason. There are better options for that like not posting whatever it is on an unprotected site or even creating a Member’s Only section for that kind of thing.

    • Eschcole

      I’m guessing this is more for questionable sites maybe?

      Not exactly. This is a feature where the loop will not display the post and will only show a password entry field. It’s not really for “questionable sites” as all of the other content is still viewable. It’s just an option for users to make a post semi-private.

      The reason I say semi-private is that a) the password is mean to be shared which is why the password is stored in clear text and the author can view/modify the password.

      Despite the password it’s not really a security feature and never was meant to be. As you’ve said there are better ways to make a site or portions of a site private using plugins.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: