介紹

從 MySQL 8.0.4 開始，MySQL 默認身份驗證插件從 mysql_native_password?  改為 caching_sha2_password? 。相應地，libmysqlclient? 也使用 caching_sha2_password 作為默認的身份驗證機制。

起因

在這之前 MySQL 5.6/5.7 使用的默認密碼插件是 mysql_native_password。mysql_native_password? 的特點是不需要加密的連接。該插件驗證速度特別快，但是不夠安全，因為，mysql_native_password 使用的是于 SHA1 算法，NIST（美國國家標準與技術研究院）在很早之前就已建議停止使用 SHA1 算法，因為 SHA1 和其他哈希算法（例如 MD5）容易被破解。

其實從 MySQL 5.6 開始就引入了更安全的認證機制：ha256_password 認證插件。它使用一個加鹽密碼（salted password）進行多輪 SHA256 哈希（數千輪哈希，暴力破解更難），以確保哈希值轉換更安全。但是，建立安全連接和多輪 hash 加密很耗費時間。雖然安全性更高，但是驗證速度不夠快。

改進

MySQL 試圖結合二者的優點。于是在 MySQL-8.0.3  引入了一個新的身份驗證插件 caching_sha2_password? ，作為sha256_password?的代替方案，在sha256_password? 的基礎上進行了改進補上了短板，既解決安全性問題又解決性能問題。與此同時 sha256_password?將退出時代的浪潮。MySQL 預計在未來版本中將其刪除。使用 sha256_password? 進行身份驗證的 MySQL 賬戶建議轉為 caching_sha2_password。

結果

因為默認身份驗證機制的更改，大家在使用 MySQL 8.0? 時候出現了很多相關的問題。網上的大部分教程都是教人改回mysql_native_password?驗證方式  mysql_native_password?。但是筆者認為，MySQL 更改默認插件是為了更好的安全性考慮。如果有 MySQL 服務要公網上使用，建議還是盡量使用 caching_sha2_password作為認證插件。

示例：使用舊版本客戶端連接時報錯：

shell> mysql -uroot -p
ERROR 2059 (HY000): Authentication plugin 'caching_sha2_password' cannot be loaded

具體機制分析

mysql_native_password

mysql_native_password? 作為 MySQL 5.6/5.7 的默認密碼插件 。其優點是它支持 challenge-response （挑戰應答方式），這是非常快的驗證機制，無需在網絡中發送實際密碼，并且不需要加密的連接。

客戶端連接MySQL實例時，首先需要從服務器端獲得一個20字節的隨機數。

此外，mysql_native_password? 使用了新的哈希算法進行認證校驗。對于用戶的原始密碼，通過SHA1(SHA1(password))兩次哈希計算結果保存在 mysql.user? 表的 authentication_string 列中。其中用戶密碼通過哈希計算后保存，沒有加鹽（salt）。

通過上述這樣的處理，MySQL數據庫本身已然非常安全。然而，隨著時間的推移，目前存在以下兩種潛在風險：

• SHA1哈希算法也已經變得比較容易破解。
• 相同的密碼擁有相同的哈希值。

SHA1、MD5等之前的哈希算法都已然不再安全，更為安全的SHA256、SHA512哈希算法也已推出。作為數據存儲最終承載者，應該使用更新的加密機制機制。

caching_sha2_password

在cache_sha2_password密碼認證機制下，其改進如下所示：

• 保存在authentication_string 中的哈希值為加鹽后的值，即使兩個不同用戶的密碼相同，保存在計算機中的哈希值也不同。
• 哈希算法升級為了更為安全SHA256算法。
• 哈希算法的round? 次數從原來的兩次，提升為了5000次，round次數越多，每次計算哈希值的代價越大，破解難度也就越大。
• 用TLS的加密或RSA密鑰傳輸方式從客戶端將密碼傳送到服務端。

caching_sha2_password 通訊過程解析

對于大多數連接嘗試，當密碼的哈希值有緩存在內存中時，它的驗證是基于 SHA256 的challenge-response?機制（與 mysql_native_password? 中基于 SHA1 的challenge-response機制相比更快），下圖演示了在有哈希緩存時的驗證流程。

 challenge-response 的認證模式

從圖中我們看到，客戶端對密碼進行多重哈希加密生成 Scramble 發送給服務端， 服務端檢查內存的緩存（memory cache）中是否存在該條目。當值在緩存中存在證明本次連接合法，服務器會告訴客戶端快速認證成功：發送 fast_auth_success 包到客戶端，并且發送確認報文。然后服務器就可以和客戶端正常通信了。

當沒有這種緩存時，caching_sha2_password? 需要使用安全連接（SSL/STL）進行密碼交換。考慮到用戶更改和 FLUSH PRIVILEGES? 操作頻率比較低，所以在大多數情況下，使用的都是基于challenge-response的身份驗證，不用建立安全連接。這省去了建立安全連接需要耗費的資源。下圖總結了完整的驗證流程。

從圖中我們看到，服務器在收到 Scramble 后,發現緩存中沒有對應的值，服務器會告訴客戶端，要建立安全連接使用完整的身份驗證流程：發送 perform_full_authentication 包到客戶端，之后客戶端接收服務器的公鑰（公鑰文件如果已存在就省去這個步驟）。如果安全連接（SSL/STL）已經建立基于 ，則可以直接發送明文密碼到服務端。如果沒有安全連接，客戶端就會 向服務端發起獲取公鑰的請求（或者指定服務端公鑰文件），使用公鑰加密密碼，發送到服務端。服務器通過 SHA256 算法計算得到哈希值，判斷是否用戶認證通過，通過則發送 OK 包到客戶端。然后服務器就可以和客戶端正常通信了。

這里詳細解釋一下 RSA 非對稱加密的通信過程：

首先先明確一個概念：非對稱加密算法中，有兩個密鑰：公鑰和私鑰。如果用公鑰進行加密，只有對應的私鑰才能解密；反之亦然。

RSA 密鑰交換過程：

1.服務器生成一對密鑰并將公鑰向其他方公開（以明文發送給客戶端）。

2.客戶端使用服務器的公鑰對密碼進行加密后發送給服務器。

3.服務器用對應的私鑰對加密信息進行解密。

因為客戶端用公鑰加密的信息只能用服務器的私鑰解密，所以這個連接過程可以視為加密通信。

需要注意的地方

默認身份驗證插件的更改意味著：

在 MySQL 8.0.4 之后創建的所有新用戶將默認使用 caching_sha2_password 作為身份驗證插件。

mysql> SELECT USER,PLUGIN FROM mysql.`user` ;
+------------------+-----------------------+
| USER             | PLUGIN                |
+------------------+-----------------------+
| root             | caching_sha2_password |
| mysql.infoschema | caching_sha2_password |
| mysql.session    | caching_sha2_password |
| mysql.sys        | caching_sha2_password |
+------------------+-----------------------+
6 rows in set (0.06 sec)

libmysqlclient? 默認使用 caching_sha2_password，可以通過手動修改切換到其他的身份驗證插件。

• 使用 caching_sha2_password 插件的客戶端，連接到服務器時，不會使用名為密碼。密碼傳輸是如何進行的取決于是否使用安全連接或 RSA 對密碼加密：
• 如果連接是安全的，可以不使用 RSA 密鑰。適用于使用 TLS 加密的 TCP 連接，以及 Unix 套接字文件和共享內存連接。密碼以明文格式發送，但不能被竊聽，因為連接是安全的。

如果連接不是安全的，可以使用 RSA 密鑰對。適用于未使用 TLS 加密的 TCP 連接和 named-pipe 連接。RSA 僅用于客戶端和服務器之間的密碼交換，防止密碼被截取。當服務器接收到使用公鑰加密的密碼后，它使用私鑰解密。一個隨機字符串用在加密中，防止重放攻擊（repeat attacks）。

在 MySQL 8.0.3 以上版本中。默認自動完成  RSA 密鑰對進行密碼交換。

關于主從復制

如果用于復制的用戶使用了 caching_sha2_password身份驗證插件，并且沒有啟用安全連接（ 在group_replication_recovery 啟用SSL支持），MySQL 將使用 RSA 密鑰對進行密碼的交換，可以把主節點的公鑰手動拷貝到從節點的服務器中，也可以設置成：自動為請求加入組的節點提供公鑰。

復制本身是支持加密的連接。在 MySQL 8.0.4中，添加了復制對 RSA 加密的支持。

CHANGE MASTER? 可以通過以下個參數來啟用基于 caching_sha2_password RSA 密鑰來交換密碼：

 指定 RSA 公鑰路徑
- MASTER_PUBLIC_KEY_PATH ="key_file_path"  
 
 #從服務端獲取 RSA 公鑰
- GET_MASTER_PUBLIC_KEY = {0 | 1}

Group Replication 可以通過以下個參數來啟用基于caching_sha2_password RSA 密鑰來交換密碼：

#指定 RSA 公鑰路徑
––group-replication-recovery-public-key-path
#從服務端獲取 RSA 公鑰
––group-replication-recovery-get-public-key

數據庫升級

數據庫升級到 MySQL 8.0.4 會怎樣？

在升級之前創建的用戶，身份認證插件不會更改。在升級之后創建的用戶默認使用 aching_sha2_password?身份驗證插件。除非使用 --default-authentication-plugin 手動指定認證插件插件。因為不會更改升級前已有用戶。因此，使用升級后依然可以用舊版本的客戶端連接這些用戶。

相應地，libmysqlclient? 支持 mysql_options() C API?函數的 MYSQL_DEFAULT_AUTH? 選項。（對于 MySQL 包中可用的基于 libmysqlclient 的客戶端工具，可以用 ––default-auth 命令行選項達到相同的目的。）

建議使用 cache_sha2_password? 因為它更安全。并且升級 libmysqlclient 到 MySQL 8.0.4 或更高版本，以便支持新的身份驗證插件。

參考資料

[MySQL 8.0.4 : New Default Authentication Plugin]

 caching_sha2_password]https://dev.mysql.com/blog-archive/mysql-8-0-4-new-default-authentication-plugin-caching_sha2_password

[得物技術淺談MySQL 8.0：新的身份驗證插件]

https://segmentfault.com/a/1190000040733952

[MySQL 8.0密碼認證機制升級，不知道可能導致業務不可用！！]

https://mp.weixin.qq.com/s/jfoH6D8NfoaNN7eexbzKGA

[組復制安裝部署 | 全方位認識 MySQL 8.0 Group Replication]

https://mp.weixin.qq.com/s/sydu0alXDECcHm5GNMvtdA