MySQL新密码机制介绍caching_sha2_password

Z时代
2024-01-10
分类：综合

database

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等）

在这里总结一下：