密码“散列”的密钥拉伸算法与节流答案

【问题标题】：Key stretching algorithms vs throttling for password "hashing"密码“散列”的密钥拉伸算法与节流
【发布时间】：2015-02-27 07:18:16
【问题描述】：

为什么人们建议使用 bcrypt/pbkdf2 等需要更长计算时间（故意）的密钥扩展算法，而不是使用更快且安全的算法，如盐渍 sha-256 或 sha-512 并使用节流机制限制暴力攻击？

限制不受 CPU 限制，并且会为暴力攻击提供相同的“延迟”，同时对于普通用户来说仍然很快。另一方面，bcrypt/pbkdf2 受 CPU 限制，并且总是很慢。

【问题讨论】：

标签： security hash password-protection

【解决方案1】：

当您使用密钥拉伸时，您就可以为攻击者从您的数据库中窃取哈希值的情况做好准备。然后，攻击者可以开始离线攻击，并利用其 GPU/CPU 的全速暴力破解密码。

只有计算散列的绝对必要的代码才是重要的，因为像限制这样的所有其他代码都可以简单地省略。要设置每个哈希的最短时间，您必须使问题本身难以解决。这就是密钥拉伸，没有更便宜的方法可以计算所有轮次的散列，以获得可比较的散列。

像 BCrypt/SCrypt 这样的一些算法是在某种方式上额外设计的，因此它们很难用 GPU 来解决。

【讨论】：

这是有道理的。但是，如果攻击者能够获得对哈希的访问权限，那么就安全性而言，这是一个更紧迫的问题。在大多数情况下，攻击者还可以访问用户的私人数据。如果可以假设散列（数据库层）是安全的（这应该是设计要求和管理要求），那么更快的散列难道不是理想的解决方案吗？
@Climax - 在没有人对您的哈希感兴趣的理想世界中，您甚至可以将它们存储为纯文本。但在现实世界中，您的哈希值可能以多种方式泄漏，因此您绝对应该使用密钥拉伸（SQL 注入、丢弃的备份、废弃服务器的硬盘、主机或 db-admin）。请记住，人们经常重复使用他们的密码，因此即使您的网站不重要，您也可能会破坏更重要的网站。也许您可能会对我的tutorial 感兴趣，了解如何安全存储密码。
感谢您的教程非常好。我同意您的回答，因为它描述了 bcrypt/scrypt 必不可少的场景。但是，我想问一下，是否可以使用一种临时的 hashmap 缓存来至少提高性能？该用例可能用于 API 查询，其中 bcrypt 必须在短时间内连续执行相同的密码。
@Climax - 好的，你有一个休息服务器的问题，它必须对每个请求进行身份验证？这通常可以通过身份验证服务解决，您可以进行一次身份验证并获取令牌。与会话一样，此令牌具有一定的生命周期，并且可以与后续的身份验证请求一起发送。由于此令牌是强令牌（与弱密码相反），因此无需使用密钥拉伸或加盐，只需将此强令牌的 SHA-512 存储在数据库中即可。
确实如此，但也适用于每秒有数百甚至数千个身份验证请求的高容量站点。对于 SHA，这不会有任何影响。对于 bcrypt，这将是一个阻碍。在您的示例中，身份验证服务还必须将密码存储在某处，并且为了安全起见，应该是 bcrypt。旁注：我使用 JWT 进行会话管理