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拓撲中是服務器-客戶端通信還是服務器-服務器通信。僅加密靜態數據是不夠的。數據在傳輸過程中必須受到保護。
- 始終通過加密備份來保護備份，以避免數據泄漏