You have old_passwords=1 in your my.cnf. I’m guessing this is because you used one of the my-small.cnf, my-large.cnf etc. templates provided with your MySQL distribution.
These files can easily win the “most outdated sample configuration file contest”.
Usually it’s no big deal: if some parameter isn’t right, you just go and change it. Some variables, though, have a long-lasting effect, and are not easily reversed.
What’s the deal with old_passwords?
No one should be using these anymore. This variable makes the password hashing algorithm compatible with that of MySQL 4.0. I’m pretty sure 4.0 was released 9 years ago. I don’t know of anyone still using it (or 4.0 client libraries).
The deal is this: with old_passwords you get a 16 hexadecimal digits (64 bit) hashing of your passwords. With so called “new passwords” you get 40 hexadecimal digits (plus extra “*“). So this is about better encryption of your password. Read more on the manual.
How do I upgrade to new password format?
You can’t just put a comment on the “old_passwords=1” entry in the configuration file. If you do so, the next client to connect will attempt to match a 41 characters hashed password to your existing 16 characters entry in the mysql.users table. So you need to make a simultaneous change: both remove the old_passwords entry and set a new password. You must know all accounts’ passwords before you begin.
Interestingly, old_passwords is both a global and a session variable. To work out an example, let’s assume the account ‘webuser’@’localhost’ enters with ‘123456’. Take a look at the following:
root@mysql-5.1.51> SET SESSION old_passwords=0; Query OK, 0 rows affected (0.00 sec) root@mysql-5.1.51> SELECT PASSWORD('123456'); +-------------------------------------------+ | PASSWORD('123456') | +-------------------------------------------+ | *6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9 | +-------------------------------------------+ 1 row in set (0.00 sec) root@mysql-5.1.51> SET SESSION old_passwords=1; Query OK, 0 rows affected (0.00 sec) root@mysql-5.1.51> SELECT PASSWORD('123456'); +--------------------+ | PASSWORD('123456') | +--------------------+ | 565491d704013245 | +--------------------+ 1 row in set (0.00 sec
So, the PASSWORD() function consults the old_passwords session variable.
To upgrade ‘webuser’@’localhost’‘s password we do:
root@mysql-5.1.51> SET SESSION old_passwords=0; Query OK, 0 rows affected (0.00 sec) root@mysql-5.1.51> SET PASSWORD FOR 'webuser'@'localhost' = PASSWORD('123456')
Go ahead and see the password entry on the mysql.users table.
What we’ve just done is to set a 41 characters password hash for that account. Now, the next time the client wishes to connect, it must know in advance it is to expect a new password, otherwise it will encode a 16 characters hash, and try to match it with our new 41 characters hash. It is now time to perform:
root@mysql-5.1.51> SET GLOBAL old_passwords=0; Query OK, 0 rows affected (0.00 sec
This will apply to all new connections made from that moment on (not affecting any existing connections). So, make sure you have updated passwords for all accounts.
To wrap it up, don’t forget to set old_passwords=0 in the my.cnf file, or, better yet, completely remove the entry.
Looking at the documentation for 4.0 – 5.6, old_passwords can’t be set from the configuration file The only way I can find to set old_passwords is via SET.
It may be specific to Percona Server though?
@Alfie,I’m afraid you’re wrong on this. I’ve just set “old_passwords = 1” in my 5.5 server’s /etc/my.cnf and it applies.
@shlomi I would like to be wrong, but I’m just not seeing the value change! I just tried doing the same thing on 5.0 and it was stuck on OFF.
So what I found is that in Percona Server 5.1 I’ve got old_passwords = 1 by default. Are you able to change your 5.5 to 0 and verify that “SELECT @@old_passwords” is 0?
Got it!
So it looks like @@old_passwords changes depending on how you logged in!
If the account you logged in as has the old password format, @@oldpasswords = 1. If you’re using the new password format, @@oldpasswords = 0.
I only figured this out after migrating all passwords to the new format.