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拓撲中是服務器-客戶端通信還是服務器-服務器通信，僅加密靜態資料是不夠的，資料在傳輸程序中必須受到保護，
- 始終通過加密備份來保護備份，以避免資料泄漏
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/19726.html
標籤：MySQL
上一篇：Mariadb之事務隔離級別