Proposal to deprecate the old password format

Improving security has been a high priority for MySQL 5.7. To give you an idea of some of the changes to date, I recommend reading Todd Farmer’s blog: Redefining –ssl option, Password expiration policy, AES256 encryption.

In MySQL 5.7, we are also proposing to remove the ‘old’ format for saving passwords. To provide some historical context:

  • The old password format is a 16-byte hash and considered to be cryptographically weak. Code appears online (I won’t link to it) which allows the hash to be brute-forced in a small-enough amount of time.
  • Ten years ago (2004), MySQL 4.1 introduced a stronger password hash format based on SHA1. The old password hash continued to be supported, since client libraries connecting to MySQL needed time to upgrade to support the new authentication scheme. A configuration setting of secure-auth=1 allowed a DBA to enforce that users could only authenticate using new password hashes, but it was not enabled by default. Another configuration setting (old-passwords=1) allowed passwords to still be generated in the weak format.
  • MySQL 5.6 (2013) enabled secure-auth=1 by default, preventing users from connecting to the server using old password hashes. However, it still permits a DBA to configure secure-auth=0 + old-passwords=1 allowing weak hashes to be generated and used. As an aside, 5.6 also introduced a new SHA256 password hash option.

This brings us to today’s discussion. We would like to propose that:

  • Setting secure-auth=0 + old-passwords=1 is officially deprecated as of MySQL 5.6. The MySQL manual pages will be updated to discourage against these settings, and warnings will be written to the server error log on startup when they are in use.

  • In a future version, support for setting secure-auth=0 + old-passwords=1 will be removed. Since our policy is to support each GA release for 8 years this means that using old-password hashing will already be supported via MySQL 5.6 until 2021. Extending support beyond this leaves us in a less secure position.

    We are proposing for removal in MySQL 5.7, but are open to suggestions as to what is an acceptable timeframe.

We value your feedback regarding this proposal:

  • Are you currently using secure-auth=0 or old-passwords=1?
  • Do you use a legacy connector that will not support the new (4.1+) authentication?
  • If you do not agree with removal in MySQL 5.7, which version would you consider more suitable?

Please leave a comment, or get in touch!

Published by

morgo

I joined MySQL AB in 2006, left, and am now back at Oracle working on the MySQL team. I’ve also worked at Percona and InPowered.

  • Rolf

    I’ve heard rumor that the SHA1 based password mechanism has been exploited as well. I think 5.7 should focus more on SSL support being part of the default, that old passwords should be removed altogether and that SHA1 be deprecated already. The amount of SSL overhead per query is minimal (although the initial connection can be disastrous if you have bigger issues, like stampeding herds). I’ve worked in shops that needed old passwords and even those are past that. Anything that does is going to be so far last extended support cycles that the world is better off without it.

  • Valerie

    I haven’t seen old passwords used on any systems in a while. ++ for removing from 5.7.

  • Upgrading password hashes can be complex. This is why not everyone moved to the new(er) password format yet. And if I’m not mistaken RHEL5/OEL5 is still using old_passwords=1 by default.

    The reason why upgrading the password hash is hard is because it must be coordinated with the user and/or application.

    Getting the user to pick a new password can be costly in ISP setups. This means you need to call and/or email the user and give the correct instructions.

    If a account is used for multiple application servers then the change must be done on all application servers at once, which means (some) downtime. One solution could be to create a more specific user (i.e. full IP-address) or giving each application a server-specific user and then removing the old generic user.

    I believe it could be made much easier: automatic password hash upgrades.
    Then the client should authenticate as usual and then send the new(er) format password hash also. Then there should be a per-user setting for the desired password format. This means that there is support needed in both the client and server and that getting it right is critical for security, but I think this could work.

    And there are still a few bugs related to SHA256: Bug #70734, Bug #71359 and Bug #70742

    And I’m really in favor of depricating the old password format. For it to work you might need to discuss this with the debian and redhat folks to make sure everything is aligned.

  • Peter Zaitsev

    I agree it is time to go for old_passwords. Security is funny – many users will ignore the security implications ie copying old_password to the new configuration file as they upgrade MySQL to new versions. Making it to stop working is a way to force it