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拓扑中是服务器-客户端通信还是服务器-服务器通信。仅加密静态数据是不够的。数据在传输过程中必须受到保护。
- 始终通过加密备份来保护备份，以避免数据泄漏
