Client/Server Communication in MySQL - The Credentials Packet (Page 4 of 4 ) The client responds with a credentials packet. The format differs between versions up to and including 4.0, and versions 4.1 and later. Table 4-3 shows the format for the pre-4.1 era. Table 4-4 shows the format for versions 4.1 and later, if the client understands and is willing to use the 4.1 protocol. Table 4-3. Fields of the client’s credentials packet, up to MySQL version 4.0 | Offset in the body | Length | Description |
|---|
| 0 | 2 | Protocol capabilities bit mask of the client, low byte first. | | 2 | 3 | Maximum packet length that the client is willing to send or receive. Zero values means the client imposes no restrictions of its own in addition to what is already there in the protocol. | | 5 | Varies; see description | Credentials string in following format: zero-terminated MySQL username, then if the password is not empty, scrambled password (8 bytes). This can be optionally followed by the initial database name, in which case a zero byte terminator is added immediately after the XOR encrypted password, followed by the database name string without a terminating zero byte. |
Table 4-4. Fields of the client’s credentials packet, MySQL version 4.1 and later | Offset in the body | Length | Description |
|---|
| 0 | 4 | Protocol capabilities bit mask of the client, low-byte first. | | 4 | 4 | Maximum packet length that the client is willing to send or receive. Zero values means the client imposes no restrictions of its own in addition to what is already there in the protocol. | | 8 | 1 | Default character set (or more precisely, collation) code of the client. | | 9 | 23 | Reserved space; currently zeroed out. | | 32 | Varies; see description | Credentials string in the following format: zero-terminated username, then the length of the SHA1 encrypted password (decimal 20), followed by its value (20 bytes), which is optionally followed by the zero-terminated initial database name. |
If the SSL capability option is enabled both on the client and on the server, the client will first send the initial part of the response packet without the credentials string. When the server receives it, it will see the SSL capability bit enabled in the capabilities mask, and know that it should expect the rest of the communication in SSL. The client switches to the SSL layer, and resends the entire response packet securely this time. It would be more efficient, of course, to not resend the initial part of the response, but, for historical reasons, this small overhead allowed the code on the server to stay fairly clean without thorough rework. Once the server receives the credentials packet, it verifies the information. From this point, it can respond in three different ways: If the check succeeds, the standard OK response packet is sent (for details, see the "Server Responses" section, later in the chapter). - If the credentials did not meet the expectations of the server, the standard error message response is sent.
- The third possibility comes from the need to support the transition from 4.0 to 4.1. In some cases, the DBA may have upgraded both the client and the server to 4.1, but forgot or chose not to upgrade the user table in the mysql database, which contains user names and their respective password hashes. If the entry for that user has the old-style password hash, it is impossible to authenticate with the new authentication protocol.
In that event, the server sends a special packet with the 1-byte-long body containing decimal 254, which means: “please send the authentication credentials in the old format.” The client responds with a packet whose body contains a zero-terminated encrypted password string. The server responds with either OK or a standard error message.
At this point the handshake is complete, and the client begins to issue commands. We'll go over these commands next week with the continuation of this series. We hope to see you then. | DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
|  This article is excerpted from chapter 4 of 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.
|
|
|
