locked
Fast authentication path should be supported RRS feed

  • Question

  • When a client connects to MySQL Server, the server sends an "initial handshake packet" that contains "auth-plugin-name", the server's preferred authentication method, and "auth-plugin-data", which is data specific to that authentication method. If the client supports that authentication method, it can attempt to use the "fast authentication path", as documented at http://web.archive.org/web/20170404124258/https://dev.mysql.com/doc/internals/en/auth-phase-fast-path.html.

    Azure Database for MySQL sets auth-plugin-name to "mysql_native_password", but it fills the auth-plugin-data field with repeated FE bytes, e.g., as shown below:

    0A 35 2E 36 2E 32 36 2E 30 00 ED FF 00 00 FE FE | .5.6.26.0.......
    FE FE FE FE FE FE 00 0F AB 21 02 00 3F 00 15 00 | .........!..?...
    00 00 00 00 00 00 00 00 00 FE FE FE FE FE FE FE | ................
    FE FE FE FE FE 00 6D 79 73 71 6C 5F 6E 61 74 69 | ......mysql_nati
    76 65 5F 70 61 73 73 77 6F 72 64 00             | ve_password.

    If the client (which supports mysql_native_password) replies with a handshake response packet that hashes the user's data with this "challenge", Azure Database for MySQL responds with an authentication method switch request packet, which contains the actual challenge that the client should hash the user's password with. The client has to then rehash the password and send that new hash before it can log in.

    Thus, the full set of connection steps is:

    C -- connect --> S
    <-- initial handshake --
    -- handshake response -->
    <-- auth method switch --
    -- hashed password -->
    <-- OK --

    If Azure Database for MySQL supported the fast authentication path (as MySQL Server 5.x and MariaDB 10.x do), then logging in could remove one network round-trip:

    C -- connect --> S
    <-- initial handshake --
    -- handshake response -->
    <-- OK --

    Thursday, May 11, 2017 5:01 AM

All replies

  • Hi Bradley,

    From what I’m aware this thread is related to your previous thread. I’d suspect this is a behavior change when you connect to a Azure Database for MySQL instance where you are not directly connect to the instance, but through a gateway. I’ll see what I can do to verify this behavior change, meanwhile, please consider submit an idea directly at this site.

    If you have any other questions, please let me know.

    Regards,
    Lin

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.


    Thursday, May 11, 2017 10:54 AM
  • I don't believe this is related to the COM_CHANGE_USER issue I reported in that other thread.

    This is about the sequence of packets that are sent when first connecting to a server.

    MySQL Server 5.7 supports a "fast path" authentication that only requires two round-trips to log in. I haven't been able to get that to work with Azure Database for MySQL (and it seems clear that the server isn't expecting this at all because it sends FE FE FE FE FE... as the auth-plugin-data in the initial handshake packet). I'm just suggesting that Azure Database for MySQL be enhanced to support "fast path" authentication, to remove an extra network roundtrip during sign in.

    (You should be able to reproduce this by performing a packet capture (with SSL off) of logging into MySQL Server 5.7 vs logging into Azure Database for MySQL with any MySQL client.)

    Thursday, May 11, 2017 3:04 PM
  • I think that I'm also hitting exactly this issue. This is pretty important to fix, it effectively means that nobody in node.js can use Azure MySQL, which is a real bummer
    Sunday, May 14, 2017 5:30 AM
  • As well as being a missed optimisation opportunity, this may possibly be a violation of the MySQL protocol if CLIENT_PLUGIN_AUTH isn't set; in that scenario, the server probably shouldn't be sending an authentication method switch request packet that contains an auth plugin name.

    Saturday, May 20, 2017 3:07 PM
  • From the answer at https://social.msdn.microsoft.com/Forums/en-US/795cb2be-dce7-4805-b324-a67e83697580/azure-database-for-mysql-reports-incorrect-version?forum=AzureDatabaseforMySQL it sounds like this is due to a MySQL proxy handling the initial connection, then routing it to the correct backend server when the user logs in.

    Could the proxy issue the original auth challenge (i.e., "plugin data"), allow the client to hash its password against it, then pass the hashed password *and* original auth challenge to the backend server, which could validate it? The challenge could be smuggled in the username field, e.g., by appending a colon and then the hex bytes.

    For example:

    The client connects to the proxy and it sends back an auth challenge of, say, 018A4B99C7.... The client hashes its password against this challenge and sends it back with a user name of "me@my-server". The proxy determines the backend server to use and passes "me:018A4B99C7..." (as the user ID) to the "my-server" backend. (Alternatively, the proxy could pass a 40-byte auth response, where 20 bytes are the challenge and 20 bytes are the user's hashed password being passed straight through.) The server then updates its auth challenge associated with the connection to the one passed by the proxy (rather than the one it originally created for the connection) and performs the real password hashing against it.


    Thursday, May 25, 2017 2:54 PM
  • Hello Bradley,

    We used to consider using proxy and another authentication plugin to handle the tricks and had a similar design as you proposed. Out of security reasons, we decided to respect MySQL protocols and let server natively handles all the challenges and hexes. :)

    Has the progress of merging your PR into mysqljs been good?  When can community users be expected to use it?

    Thank you!

    Xiangyu

    Monday, June 12, 2017 3:48 AM
  • Has the progress of merging your PR into mysqljs been good?  When can community users be expected to use it?

    It's still waiting for a response from the maintainer; I'm not really sure when it will get merged. If you have a GitHub account, you can subscribe to notifications here: https://github.com/mysqljs/mysql/pull/1730
    Tuesday, June 13, 2017 3:04 AM