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:
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
Triage: Needs Triage: D2 (Serious)

[19 May 2011 1:35] Victor Benincasa
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).

(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] Miguel Solorzano
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
[2 Jun 2011 12:02] Miguel Solorzano
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:
updated to reflect this issue like 5.5.13 has:

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?

[4 Jul 2011 22:11] Miguel Solorzano
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	MySQL	Login Request user=teligent db=

...which should raise suspicions.