MySQL新密碼機制介紹caching_sha2_password
MySQL添加了對身份驗證外掛的支援，該外掛現在稱為mysql_native_password。該mysql_native_password外掛使用SHA1雜湊
將密碼（SHA1（SHA1（password）））儲存在mysql.user表中
驗證使用者，該外掛的一個優點是，它允許使用質詢-響應機制進行身份驗證，從而可以在未加密的通道上驗證客戶端的身份，而無需傳送實際密碼。
隨著時間的流逝，我們從身份驗證方案的角度確定了需要改進的幾個方面。
- 在將值儲存在資料庫中時，密碼的轉換必須使用鹽（增加的因素）。沒有它，兩個具有相同密碼的帳戶將具有相同的雜湊值。儘管這並不能顯示實際的密碼，但確實提供了有關使用者使用密碼的線索，並限制了暴力攻擊和獲取密碼所需的工作。
- 使用蠻力攻擊更難破解儲存的密碼。最好在儲存密碼時使用許多（數千）輪雜湊。
- 使用更強大的雜湊機制。隨著技術的發展，SHA1和其他雜湊演演算法的前身（例如MD5）已被證明非常容易破解。注意：NIST 在2011年已棄用。因此，如果您可以從mysql.user表中獲取雜湊，或者通過嗅探未加密的通道，則可以對這些密碼進行快速反向工程和破解，尤其是當密碼較短（少於8個字元）時。另請參閱FIPS 180-4。
- 對身份驗證階段和密碼使用不同的雜湊方案。在這兩種情況下，mysql_native_password外掛都使用類似的轉換（SHA1（SHA1（password）））。
為了克服這些限制，從MySQL-8.0.3開始， 引入了一個新的身份驗證外掛 caching_sha2_password。從 MySQL-8.0.4開始，此外掛成為MySQL伺服器的新預設身份驗證外掛。通過caching_sha2_password身份驗證，我們可以解決上述問題，同時確保不影響效能。許多使用MySQL的應用程式以很高的頻率連線和斷開連線。
MySQL caching_sha2_password的設計重點是：
- 使用SHA-2雜湊機制來轉換密碼。具體來說，它使用SHA256。
- 生成雜湊時，每個密碼使用20位元組長的鹽。由於鹽是一個隨機數，即使兩個使用者使用相同的密碼，轉換過程的最終結果也將完全不同。
- 為了使使用蠻力機制更難以嘗試和猜測密碼，在將最終轉換儲存在mysql.user表中之前，對密碼和鹽進行了5000輪SHA2雜湊。
兩種操作方式：
- COMPLETE：要求客戶端安全地傳送實際密碼（通過TLS連線或使用RSA金鑰對）。伺服器生成5000輪雜湊，並與mysql.user中儲存的值進行比較。
- FAST：允許使用SHA2雜湊的基於質詢-響應的身份驗證。高效能和安全性在同一時間。
DBA可以強制資料庫客戶端定期使用COMPLETE模式來確定實際密碼的認知。通過使用不同輪迴數的雜湊將密碼儲存和身份驗證脫鉤。即使有人可以訪問這兩個密碼，也無法在實際可行的時間內使用此資訊來推斷密碼或獲取密碼的sha2雜湊。蠻力破解8字元長的密碼以及5000輪鹹化雜湊值將花費很長時間。比任何密碼到期策略（甚至最寬鬆的策略）更長的時間。較長的密碼只會使事情變得更加困難。
下表比較了mysql_native_password和caching_sha2_password。
除了新外掛外，還添加了一些功能來防止嘗試識別使用者資訊並減輕與弱密碼相關的風險：
- 支援TLS連線，無需任何額外的努力（伺服器端支援和客戶端端支援）以確保預設情況下連線是安全的
- CREATE USER / ALTER USER提供了幾個 選項來指定密碼管理策略
- 控制可以和不能用作密碼的內容–長度，字元複雜度等。
- 減慢蠻力嘗試猜測密碼會增加延遲以及設定最大嘗試限制
- 用隨機一次密碼重置密碼。
- 防止使用者列舉的其他措施
這些功能與caching_sha2_password結合使用，可增強使用者帳戶抵禦密碼攻擊的能力。
另外，mysql模式的資料可以在靜態時進行加密（InnoDB加密， 二進位制日誌加密）。這樣可以保護敏感資料，例如密碼雜湊，以防止未經授權的檔案訪問。這在OS /檔案系統中隱藏了許多細節。FYI – DBA（具有所需特權集的使用者，例如mysql.user表上的SELECT）可以看到此雜湊資料，而與使用靜態資料加密方案無關。話雖如此，反向工程師密碼的費用仍然很高。
如果僅憑安全性不足以促使您升級到caching_sha2_password，那麼另一項商業動機就是遵守法規。大多數法規禁止將sha1，md5和其他弱密碼用於密碼或其他用途。（HIPAA，GDPR等）
在這裡總結一下：
- 如果您使用的是mysql_native_password，請儘快計劃遷移到caching_sha2_password或支援與外部身份驗證伺服器整合的 企業身份驗證外掛之一。SHA1不夠安全，切換也不困難。
- 對mysql.user表的訪問應儘可能嚴格。即使它不儲存實際的密碼，該表中的資訊也非常敏感-尤其是密碼雜湊。實際上，無論您在何處儲存此類雜湊-無論是在MySQL資料庫中還是在外部身份驗證伺服器（例如LDAP伺服器）上，都必須始終對其進行保護。 OpenLDAP檔案 很好地闡明瞭這一點：
- 使用MySQL提供的密碼策略功能來控制密碼生命週期。
- 使用MySQL提供的控制元件來防止對密碼的暴力攻擊。
- 在mysql模式上，最好在所有表上使用InnoDB加密，以及二進位制日誌加密，以保護靜態資料免受未經授權的訪問。
- 始終使用加密的連線：在HA拓撲中是伺服器-客戶端通訊還是伺服器-伺服器通訊。僅加密靜態資料是不夠的。資料在傳輸過程中必須受到保護。
- 始終通過加密備份來保護備份，以避免資料洩漏