两个密码验证插件的故事……

作者：Harin Vadodaria 译： 徐轶韬

很久以前（在遥远的星系中……提示音乐！），MySQL增加了对身份验证插件的支持，这个插件现在称为mysql_native_password。mysql_native_password插件使用SHA1哈希

• 将密码（SHA1（SHA1（password）））存储在mysql.user表中
• 验证用户

该插件的一个优点是，它允许使用质询-响应机制进行身份验证，可以在未加密的通道上验证客户端的身份，而无需发送实际密码。

随着时间的流逝，我们从身份验证方案的角度发现了需要改进的几个方面。

1. 将值存储在数据库中时，密码的转换必须使用盐值（增加的因素）。没有它，两个具有相同密码的帐户将具有相同的哈希值。尽管不能显示实际的密码，但它提供了用户正在使用的密码的线索，这样会减少暴力攻击和获取密码所需的工作。
2. 防止使用暴力攻击破解存储的密码。最好在存储密码时使用许多（数千）轮哈希。
3. 使用更强大的哈希机制。随着技术的发展，SHA1和其他哈希算法的前身（例如MD5）已被证明非常容易破解。注意：NIST 在2011年已弃用。因此，如果您可以从mysql.user表中获取哈希值，或者通过截取未加密的通道，则可以对这些密码进行快速反向工程和破解，尤其是当密码较短（少于8个字符）时。关于这部分内容可以参阅FIPS 180-4。
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。

请参考 https://mysqlserverteam.com/mysql-8-0-4-new-default-authentication-plugin-caching_sha2_password/ 有关caching_sha2_password插件的博客文章。您也可以参考文档https://dev.mysql.com/doc/refman/8.0/en/caching-sha2-pluggable-authentication.html以获取更多详细信息。页面https://dev.mysql.com/doc/dev/mysql-server/latest/page_caching_sha2_authentication_exchanges.html提供了有关如何使用caching_sha2_password插件执行身份验证的详细信息。

除了新插件外，还添加了一些功能来防止尝试识别用户信息并减轻弱密码相关的风险：

• 支持TLS连接，无需任何额外的工作（服务器端支持和客户端端支持）以确保默认情况下连接是安全的
• CREATE USER / ALTER USER提供了几个选项https://dev.mysql.com/doc/refman/8.0/en/create-user.html#create-user-password-management来指定密码管理策略
• 控制密码的内容–长度，字符复杂度等。
• 减缓暴力破解，猜测密码会增加延迟以及设置最大尝试限制
• 使用随机一次密码重置密码。
• 防止用户枚举的其他措施

这些功能与caching_sha2_password结合使用，可增强用户帐户抵御密码攻击的能力。请根据您的要求使用它们，并让我们知道您的反馈。

另外，mysql系统模式的数据可以在静态时进行加密（InnoDB加密， 二进制日志加密）。

这样可以保护敏感数据，例如密码哈希，以防止未经授权的文件访问。这对OS /文件系统中隐藏了许多细节。参考信息– 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拓扑中，无论是服务器-客户端通信还是服务器-服务器通信。仅加密静态数据是不够的。数据在传输过程中必须受到保护。
• 始终通过加密备份来保护备份，以避免数据泄漏

与往常一样，非常感谢您使用MySQL！