MySQL8.0：新的身份验证插件（caching_sha2_password）

见贤思齐

MySQL 8.0：新的身份验证插件（caching_sha2_password）从 MySQL 8.0.4 开始，默认身份验证插件从 mysql_native_password 更改为 caching_sha2_password。相应地，现在的 libmysqlclient 将使用 caching_sha2_password 作为默认的验证机制。为什么这样做呢MySQL 5.6/5.7 的默认密码插件一直以来都是 mysql_native_password。其优点是它支持 challenge-response 机制，这是非常快的验证机制，无需在网络中发送实际密码，并且不需要加密的连接。然而，mysql_native_password 依赖于 SHA1 算法，但 NIST（美国国家标准与技术研究院）已建议停止使用 SHA1 算法，因为 SHA1 和其他哈希算法（例如 MD5）已被证明非常容易破解。此外，由于 mysql_native_password 在 mysql.user 表中 authentication_string 字段存储的是两次哈希 SHA1(SHA1(password))?计算的值?，也就是说如果两个用户帐户使用相同的密码，那么经过 mysql_native_password 转换后在 mysql.user 表得到的哈希值相同。尽管有 hash 值也无法得到实际密码信息，但它仍然告诉这两个用户使用了相同的密码。为了避免这种情况，应该给密码加盐（salt），salt 基本上是被用作输入，用于转换用户密码的加密散列函数。由于 salt 是随机的，即使两个用户使用相同的密码，转换后的最终结果将发生较大的变化。从 MySQL 5.6 开始支持 sha256_password 认证插件。它使用一个加盐密码（salted password）进行多轮 SHA256 哈希（数千轮哈希，暴力破解更难），以确保哈希值转换更安全。然而，它需要要么在安全连接或密码使用 RSA 秘钥对加密。所以，虽然密码的安全性更强，但安全连接和多轮 hash 转换需要在认证过程中的时间更长。为了克服这些限制，从 MySQL 8.0.3 开始，引入了一个新的身份验证插件 caching_sha2_password。从 MySQL 8.0.4 开始，此插件成为 MySQL 服务器的新默认身份验证插件。caching_sha2_password 尝试一个两全其美的结合，既解决安全性问题又解决性能问题。首先，是 caching_sha2_password 对用户密码的处理，其实主要是 sha256_password 的机制：使用 SHA2 算法来转换密码。具体来说，它使用 SHA256 算法。保存在 authentication_string 列中的哈希值为加盐后的值，由于盐是一个 20-byte 的随机数，即使两个用户使用相同的密码，转换后的最终结果也将完全不同。为了使使用暴力破解机制更难以猜测密码，在将最终转换存储在 mysql.user 表中之前，对密码和盐进行了 5000 轮 SHA2 散列。为了实现加盐机制，列 authentication_string 需保存保存盐值，因此 authentication_string 值的长度变为了 70 个字节：mysql> select user, host, authentication_string, length(authentication_string), plugin from mysql.user limit 1;+------+------+------------------------------------------------------------------------+-------------------------------+-----------------------+| user | host | authentication_string ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| length(authentication_string) | plugin ? ? ? ? ? ? ? ?|+------+------+------------------------------------------------------------------------+-------------------------------+-----------------------+| root | % ? ?| $A$005$1%h5f1OdZ0'46}M[uz5Di5wW2WWg8eeLWynsg2h3xnzHwQLmm39bEqLBxB0 ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ?70 | caching_sha2_password |+------+------+------------------------------------------------------------------------+-------------------------------+-----------------------+1 row in set (0.00 sec)新 caching_sha2_password 认证机制下，authentication_string 中的字节，例如上面的字符串$A$005$1%h5f1OdZ0'46}M[uz5Di5wW2WWg8eeLWynsg2h3xnzHwQLmm39bEqLBxB0，其中分别保存如下内容：内容字节数说明哈希算法2字节目前仅为 $A，表示 SHA256 算法哈希轮转次数4字节目前仅为 $005，表示 5*1000=5000 次盐（salt）21字节用于解决相同密码相同哈希值问题哈希值43字节_从 MySQL 8.0.24 开始，提供了 caching_sha2_password_digest_rounds 系统变量，默认值和最小值是 5000，最大值 4095000；用于 caching_sha2_password 认证插件密码存储的哈希轮转次数。其次，caching_sha2_password 是在服务器端通过缓存解决性能问题。caching_sha2_password 插件使用内存缓存来为曾经连接过的客户端进行快速验证。内存缓存条目由username/SHA256(SHA256(user_password))对组成。缓存的工作原理是这样的：当客户端连接，caching_sha2_password 检查 username/SHA256(SHA256(user_password)) 是否匹配了缓存条目。如果匹配，验证成功。如果没有匹配的缓存条目，插件会继续与客户端交换数据包，尝试使用 mysql.user 系统表的凭证验证客户端。如果成功，caching_sha2_password 增加对客户端的散列条目。否则，认证失败，连接被拒绝。这样，当客户端第一次连接，使用 mysql.user 系统表的凭据进行认证。当客户端连接之后，使用缓存进行快速认证。对于大多数的连接尝试，当内存缓存中存在于的密码哈希的副本时，它采用了基于 SHA256 的 challenge-response 机制认证客户端（mysql_native_password 是基于 SHA1 的 challenge-response 机制）。这样会更快，并且允许通过未加密的通道进行安全认证。下面总结基于 challenge-response 的认证模式（也称之为 Fast authentication 模式）：客户端连接服务端服务端给客户端发送 Nonce（20 字节长的随机数据）客户端使用 XOR(SHA256(password), SHA256(SHA256(SHA256(password)), nonce)) 生成 Scramble 发送给服务端服务端检查 username/SHA256(SHA256(user_password)) 是否在内存缓存条目中存在，存在则证明合法；发送 fast_auth_success 包到客户端服务端发送 OK 包到客户端进入命令阶段Note在信息安全中，Nonce 是一个在加密通信只能使用一次的数字。在认证协议中，它往往是一个随机或伪随机数（salt），以避免暴力攻击。由于 caching_sha2_password 插件在使用缓存的情况下可以快速认证，但在以下情况下是无效的，对于某些或所有用户：当用户的密码被更改时，用户缓存的密码哈希值都被从内存中删除。密码可以通过 ALTER USER/SET PASSWORD/GRANT 改变。当用户被删除时，或证书、或认证插件改变；用户缓存的密码哈希值都被从内存中删除。当用户使用 RENAME USER 重命名时，用户缓存的密码哈希值都被从内存中删除。当执行 FLUSH PRIVILEGES 时，所有缓存的密码哈希值都被从内存中删除，影响所有用户。服务器关闭时会清空缓存。在缓存失效的情况下会影响后续的客户端连接验证要求。caching_sha2_password 需要用户第一客户端连接必须使用安全连接（TCP 连接使用 TLS、Unix 套接字文件、或共享内存）或使用 RSA 加密密码进行交换。考虑到用户的密码变化和 FLUSH PRIVILEGES 是不经常执行的操作，所以在大多数情况下，基于 challenge-response 认证就足够了。下面总结了基于完整认证模式（perform_full_authentication）的机制（也称之为 Complete authentication 模式）：客户端连接服务端服务端给客户端发送 Nonce（20 字节长的随机数据）客户端使用 XOR(SHA256(password), SHA256(SHA256(SHA256(password)), nonce)) 生成 Scramble 发送给服务端服务端检查 username/SHA256(SHA256(user_password))?是否在内存缓存条目中存在，不存在则发送 perform_full_authentication 包到客户端继续认证客户端收到 perform_full_authentication 包，可以进行如下处理如果连接已经建立基于 SSL 的安全通道，则可以直接发送明文密码到服务端向服务端发起获取公钥的请求（或者指定服务端公钥文件），使用公钥+Nonce加密密码，发送加密后的密码到服务端服务器通过 SHA256 算法计算得到哈希值，判断是否用户认证通过，通过则发送 OK 包到客户端进入命令阶段总结来说 caching_sha2_password 插件工作机制分为两个阶段，Complete authentication 和 Fast authentication。各自认证机制上面已经阐述了。更加详细的过程，以及服务端和客户端状态的转换，官方在源码文档里面提供有一张图和说明可以参考，地址在文末。改变了什么呢？在 MySQL 8.0.4 之后创建的所有新用户将默认使用 caching_sha2_password 作为他们的身份验证插件。mysql> CREATE USER 'sha2user'@'localhost' IDENTIFIED BY '42';Query OK, 0 rows affected (0.02 sec)mysql> SHOW CREATE USER 'arthurdent'@'localhost'\GCREATE USER for sha2user@localhost: CREATE USER 'sha2user'@'localhost' IDENTIFIED WITH 'caching_sha2_password' AS '$Afnka//BGe\d3h\n SHOW STATUS LIKE 'Caching_sha2_password_rsa_public_key'\GVariable_name: Caching_sha2_password_rsa_public_keyValue: -----BEGIN PUBLIC KEY-----MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDO9nRUDd+KvSZgY7cNBZMNpwX6MvE1PbJFXO7u18nJ9lwc99Du/E7lw6CVXw7VKrXPeHbVQUzGyUNkf45Nz/ckaaJaaLgJOBCIDmNVnyU54OT/1lcs2xiyfaDMe8fCJ64ZwTnKbY2gkt1IMjUAB5Ogd5kJg8aV7EtKwyhHb0c30QIDAQAB-----END PUBLIC KEY-----如果该值为空，检查错误日志中的诊断信息。服务器已经配置了 RSA 密钥文件之后，用户在使用 caching_sha2_password 插件进行身份验证，这些密钥文件连接到服务器的选项。如前面提到的，这时候用户可以使用安全连接（在这种情况下不使用 RSA）或者在未加密的连接下使用 RSA 执行密码交换。假设使用未加密的连接时，例如：shell> mysql --ssl-mode=DISABLED -u sha2user -pEnter password: password尝试通过 sha2user 用户连接，服务器确认 caching_sha2_password 认证插件对 sha2user 是合适的并调用它。插件查找到该连接未被加密，因此需要使用 RSA 加密被发送的密码。但是，服务端不会发送公钥给客户端，由于客户端没有提供公钥，所以它不能加密密码，连接失败：ERROR 2061 (HY000): Authentication plugin 'caching_sha2_password'reported error: Authentication requires secure connection.为了从服务器请求的 RSA 公共密钥，指定--get-server-public-key选项：shell> mysql --ssl-mode=DISABLED -u sha2user -p --get-server-public-keyEnter password: password在这种情况下，服务器发送的 RSA 公钥给客户端，客户端使用它来加密密码，并将结果返回到服务器。该插件使用服务器端的 RSA 私钥来解密密码，并根据密码是否正确来决定接受或拒绝连接。另外，如果客户端具有服务器所需的 RSA 公钥文件，可以使用--server-public-key-path选项指定文件：shell> mysql --ssl-mode=DISABLED -u sha2user -p --server-public-key-path=file_nameEnter password: password在这种情况下，客户端使用公钥来加密密码并将结果返回到服务器。该插件使用服务器端的 RSA 私钥来解密密码，并根据密码是否正确来决定接受或拒绝连接。由--server-public-key-path选项指定的文件中的公钥值应该与caching_sha2_password_public_key_path系统变量命名的服务器端文件的键值相同。如果密钥文件包含一个有效的公钥值，但该值不正确，会出现拒绝访问错误。但如果密钥文件不包含一个有效的公钥值，客户端程序不能使用它（这是因为客户端做过公钥正确性校验）。客户端用户可以得到 RSA 公钥的两种方式：数据库管理员可以提供公钥文件的副本。可以连接到服务器的客户端用户，可以使用SHOW STATUS LIKE "Caching_sha2_password_rsa_public_key"语句返回公钥值，并保存在一个文件中。对复制的影响？复制本身是支持加密的连接。在 MySQL 8.0.4，复制也进行了 RSA 密钥对的支持。CHANGE MASTER 现在支持了两个参数来启用基于 caching_sha2_password RSA 密钥来交换密码MASTER_PUBLIC_KEY_PATH ="key_file_path"，指定 RSA 公钥路径GET_MASTER_PUBLIC_KEY = {0 | 1}，从服务端获取 RSA 公钥Group Replication 现在支持了两个参数来启用基于 caching_sha2_password RSA 密钥来交换密码––group-replication-recovery-public-key-path，指定 RSA 公钥路径––group-replication-recovery-get-public-key，从服务端获取 RSA 公钥Note如果复制通道是安全的，那么自然也就不需要使用 RSA 公钥来交换密码。参考https://mp.weixin.qq.com/s/HetYIbLI8VvzyewXuoBLoAhttps://mp.weixin.qq.com/s/jfoH6D8NfoaNN7eexbzKGAhttps://dev.mysql.com/doc/refman/8.0/en/caching-sha2-pluggable-authentication.htmlhttps://dev.mysql.com/doc/dev/mysql-server/latest/page_caching_sha2_authentication_exchanges.htmlhttps://mysqlserverteam.com/mysql-8-0-4-new-default-authentication-plugin-caching_sha2_password关注得物技术，做最潮技术人！文｜东青