Bug #61222 pre-4.1 clients with old style passwords (short hashes) cannot authenticate
Submitted: 19 May 2011 1:35 Modified: 3 Jun 2011 23:46
Reporter: Victor Benincasa Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: General Severity:S2 (Serious)
Version:5.1.57 OS:Linux (CentOS 5.6 32-bits)
Assigned to: CPU Architecture:Any
Tags: bad handshake, old password, regression

[19 May 2011 1:35] Victor Benincasa
Description:
With the 5.1.57 version the pre-4.1 clients cannot authenticate. The db users still using the old style password with short hashes (generated with OLD_PASSWORD() function), but the pre-4.1 clients shows an "Bad handshake" error:

$mysql -h unihostbrasil.com.br -u unihost_test -p
Enter password: *********
ERROR 1043: Bad handshake

When I downgraded to 5.1.56 the authentication with short hashes started working again.

How to repeat:
Try to connect an pre-4.1 client to the 5.1.57 server even with the user using the old style password with short hashes.
[19 May 2011 7:51] Peter Laursen
You can set 'old_passwords' variable in configuration, I believe.
But maybe default for this was changed with 5.1.57?

SELECT VERSION(); -- returns "5.1.57-community"
SHOW VARIABLES LIKE 'old_passwords' -- returns "OFF" (and I did not change default for this).

Peter
(Not a MySQL person)
[19 May 2011 16:26] Victor Benincasa
Hi Peter, thanks for your response.

As said in documentation[1], the "old_passwords" option does not affect authentication, but it does prevent creation of a long password hash in the user table as the result of a password-changing operation.

[1] http://dev.mysql.com/doc/refman/5.1/en/password-hashing.html

My password is already stored in old style (short hash), so the "old_passwords" option set to off isn't the problem.

Additionally, this option is also off by default in previous version (in which the authentication works fine):
SELECT VERSION(); -- returns "5.1.56-log"
SHOW VARIABLES LIKE 'old_passwords' -- returns "OFF"

Seems like a bug in 5.1.57. There are other reports of this problem too: http://google.com/search?q=5.1.57+bad+handshake
[19 May 2011 16:48] Davi Arnaut
There was a recent change to the client authentication packet handling code to make it more strict that revealed a bug in pre-4.1 clients. Old clients failed to properly send a NUL terminating character in some cases. We are working on a fix for old clients.
[23 May 2011 2:18] Paul Oehler
This bug is also present as of the 5.5.11 -> 5.5.12 upgrade.  The only current workaround we've found is to revert to 5.5.11 or 5.1.56.
[25 May 2011 12:27] Valeriy Kravchuk
Bug #61282 was marked as a duplicate of this one.
[25 May 2011 12:54] MySQL Verification Team
See http://bugs.mysql.com/bug.php?id=61280.
[31 May 2011 18:24] Paul Oehler
Can we get an expected ETA on a fix for this issue?
[31 May 2011 20:02] Davi Arnaut
Soon.
[2 Jun 2011 12:02] MySQL Verification Team
http://bugs.mysql.com/bug.php?id=61384 duplicate of this one.
[3 Jun 2011 9:17] Steven Hartland
We just updated to 5.5.12 from 5.5.10 and are experiencing the same thing, any update on this as all our legacy clients, are offline :(
[3 Jun 2011 23:46] Paul DuBois
Noted in 5.1.58, 5.5.14, 5.6.3 changelogs. 

A problem introduced in 5.1.57/5.5.11 caused very old (MySQL 4.0) clients to 
be unable to connect to the server.
[4 Jun 2011 0:31] Steven Hartland
Would be good to see the change log for 5.5.12:
http://dev.mysql.com/doc/refman/5.5/en/news-5-5-12.html
updated to reflect this issue like 5.5.13 has:
http://dev.mysql.com/doc/refman/5.5/en/news-5-5-13.html

If this had been done would have prevented us a lot of pain over the past few days, and I expect the same for others.
[13 Jun 2011 3:58] Lars Oberg
We are experiencing the same issue "ERROR 1043: Bad handshake" when using Perl DBD (perl-DBD-MySQL 2.1021-4.EL3) on a legacy Red Hat EL3 server (that we cannot upgrade for legacy reasons).  

Any ETA on a fix?
[4 Jul 2011 21:57] Paul Oehler
Why is this bug now marked as Closed?  I see no confirmation that the bug has been fixed, and there still exists no workaround we've found but to downgrade MySQL.  Last ETA for a fix was reported on May 31 as "Soon".  Can we please get confirmation of the version(s) that will fix this bug, and if possible, when that version will be released?

Thanks.
[4 Jul 2011 22:11] MySQL Verification Team
See comment: [4 Jun 1:46] Paul DuBois when it was closed.
[4 Jan 2012 23:14] Michael Moody
This is not resolved as of 5.1.59, and should not be closed, a downgrade to 5.1.56 was necessary. RPMs came direct from mysql.
[10 Jan 2012 10:39] Andre Koethur
I just updated to 5.1.57 and ran into the same problem. I'm using the following client:

mysql  Ver 11.18 Distrib 3.23.55, for suse-linux (i686)

I also tried it with a user without a password:

mysql --host=appx35 --user=termtest
ERROR 1043: Bad handshake
[4 Feb 2012 14:16] Carl Youngblood
I'm also experiencing this problem on 5.5.19 for OSX Lion. I had to install 5.1.56 to fix it.
[6 Feb 2012 8:38] Andre Koethur
I ended up downgrading to 5.1.46 on one of our replication slave clients. Luckily, I only need read access with the old client.
[9 Jan 2014 12:24] Alexander Petrossian
Colleagues, we've came across "Bad handshake" when migrated from 5.0.86 to 5.6.13

In our case in client capabilities we passed this bit:
".... .... .... 1... = Connect With Database: Set"

But in schema field we passed empty value:
"Schema: "

This combination worked fine in 5.0.86, but gives "Bad handshake" on 5.6.13

Such behavior may be argued as "OK" and I will not spend energy on claiming that this is a bug.

In summary line in Wireshark you'll see ...
69	2014-01-09 16:02:50.965133	192.168.64.141	192.168.64.140	MySQL	Login Request user=teligent db=

...which should raise suspicions.