Authentication Protocol Security
(Page 1 of 7 )
This article is the second in a series that we hope will leave you better informed on topics ranging from writing a MySQL proxy server to auditing your MySQL traffic. It is excerpted from the book
Understanding MySQL Internals, written by Sasha Pachev (O'Reilly, 2007; ISBN: 0596009577) Copyright © 2007 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.
Neither the old nor the new protocol ever sends the user password across the connection in plain text. However, there are a number of weaknesses in the old protocol. First, knowing the value of the password hash allows the attacker to perform authentication without actually knowing the password. This is possible due to a flaw in the way the expected response to the challenge is computed—it is uniquely determined by the value of the password hash and the value of the challenge (for details, see scramble_323() and check_scramble_323() in sql/password.c). Therefore, if the attacker can get read access to the user table in the mysql database, or obtain the value of the stored password hash some other way, she will be able to authenticate with a specially modified version of the MySQL client library.
Second, even without having access to the hash, the correct password can be guessed in a small number of attempts if the attacker can intercept the authentication traffic between the client and the server on a few occasions. This is possible due to the weakness in the encryption method of the old protocol. The encryption is done using a home-cooked XOR procedure (see the scramble_323() function mentioned earlier), which lacks true cryptographic strength.
These weaknesses have been addressed in version 4.1. The authentication method now uses SHA1 hashes for encryption, which are much more resistant to cracking. Also, the changed challenge-verification algorithm removed the ability to authenticate by knowing just the value of the password hash rather than the actual password.
Despite the added improvements, do not feel complacent about the security of the new protocol. It is still recommended to block access to the MySQL port on the firewall, and if this is not possible, require the clients to use SSL.
Protocol Capabilities Bit Mask During the authentication handshake, the client and the server exchange information on what the other is able or willing to do. This enables them to adjust their expectations of their peer and not send the data in some unsupported format. The exchange of information is accomplished through fields containing the bit mask of protocol capabilities.
The bit mask can be either 4 or 2 bytes long, depending on the context. The newer (4.1 and later) clients and servers understand 4-byte masks as well as 2-byte ones. The older (4.0 and earlier) ones can handle only 2-byte masks.
The server, regardless of the version, always announces its capabilities with a 2-byte bit mask. Although both newer clients and servers understand the 4-byte mask, the first packet in the dialog must be understood by any client regardless of the version. For this reason, even the newer clients expect the greeting packet to contain a 2-byte mask.
Once the client knows that it is talking to a newer server, it can announce its capabilities with a 4-byte mask. However, if the newer client detects that it is talking to an older server, it will announce the capabilities with only a 2-byte mask. Naturally, the older clients can only send a 2-byte mask; they are not aware of 4-byte ones.
Table 4-5 explains the meaning of the bits used in the capabilities’ bit mask. The values are defined in include/mysql_com.h.
Table 4-5. Protocol capability bits
| Bit macro symbol | Hex value | Description |
|---|
| CLIENT_LONG_PASSWORD | 0x0001 | Apparently was used in the early development of 4.1 to indicate that the server is able to use the new password format. |
| CLIENT_FOUND_ROWS | 0x0002 | Normally, in reporting the results of an UPDATE query, the server returns the number of records that were actually modified. If this flag is set, the server is being asked to report the number of records that were matched by the WHERE clause. Not all of those will necessarily be updated, as some may already contain the desired values. |
Next: Authenticating Handshake >>
More Database Articles Articles
More By O'Reilly Media
|
 This article is excerpted from the book Understanding MySQL Internals, written by Sasha Pachev (O'Reilly, 2007; ISBN: 0596009577). Check it out today at your favorite bookstore. Buy this book now.
|
|
