MySQL Bugs: #61222: pre-4.1 clients with old style passwords (short hashes) cannot authenticate

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

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.

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)

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

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.

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.

Bug #61282 was marked as a duplicate of this one.

See http://bugs.mysql.com/bug.php?id=61280.

Can we get an expected ETA on a fix for this issue?

Soon.

http://bugs.mysql.com/bug.php?id=61384 duplicate of this one.

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 :(

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.

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.

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?

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.

See comment: [4 Jun 1:46] Paul DuBois when it was closed.

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.

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

I'm also experiencing this problem on 5.5.19 for OSX Lion. I had to install 5.1.56 to fix it.

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.

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.