密码、盐、哈希、数据库：百万次答案

【问题标题】：Password, salt, hash, DB: For the millionth time密码、盐、哈希、数据库：百万次
【发布时间】：2012-03-06 06:00:14
【问题描述】：

我知道这个话题已经讨论了一百万次了。但这对我来说是新的，我读得越多，我就越不了解实际发生或应该发生的事情。

我将每个用户的盐添加到用户密码的散列存储中，因此存储的密码散列如下所示：hash(password + perusersalt)。这导致不同用户的相同密码在数据库中存储为不同的字符串。凉爽的。但我不担心有人闯入数据库并查找散列密码。我担心有人暴力查询我的服务器以获取用户名和密码的组合。在这种情况下，密码的加盐和哈希存储是没有用的，因为用户名和密码的正确组合将产生成功的登录。对吧？

在这种情况下盐毫无用处的印象是正确的吗？因为服务器只接受接口的用户名和密码（不传输盐），所以普通的字典攻击就可以了，对吧？

所以盐只是用来从有权访问数据库的人那里混淆用户的密码（只能通过反向彩虹表查找获得）。嗯。

相关：我的网络应用程序甚至不传输纯密码。密码已经在客户端进行了哈希处理，只是为了完全拒绝对某人被盗密码负责，并且整个事情都使用 SSL。

这是否意味着我或多或少处于可能的最高安全级别，因为用户名和密码的正确组合当然必须产生成功登录？

感谢您清理了我脑海中的混乱。

【问题讨论】：

标签： database hash passwords

【解决方案1】：

您对蛮力攻击的假设是正确的。如果用户有一个简单的密码，salt 和 hash 就无关紧要了。字典攻击会猜测“密码”并允许攻击者进入。您必须要求用户提供安全密码，然后进行单向加密（用盐对其进行散列），并像您一样使用 SSL。

【讨论】：

如果你控制了网络前端，你可以人为地限制每分钟可以尝试的密码数量，并在一些无效的尝试减慢速度后添加一个验证码图像，以供其他网站（如 hotmail）使用。
取决于 RDBMS 解决方案，即使您不控制等式的 Web 端，您通常也可以控制它，但如果您决定切换到新数据库。
你也可以使用 bcrypt，它是专门设计用来变慢的，不管你的服务器有多快，都会让暴力破解变慢。
我个人是使用 PHP 的 Whirlpool 的忠实粉丝。我将它用于企业网站，发现它非常易于实施，而且非常安全。它足够晦涩，不会引起 SHA 黑客的注意，但它也很快。
请注意：请记住，哈希不是您在此处所述的加密。这是一个简单的算法混淆。加密需要密钥。

【解决方案2】：

“密码是 [...] 散列客户端 [...] 以 [...] 拒绝对某人的被盗密码负责，整个事情都使用 SSL。”

客户端是否发送哈希（密码+盐）？

通过这种设计，客户端不需要密码就可以成功登录，它只需要哈希。所以你可能仍然要为泄露真实密码（哈希）负责。

【讨论】：

客户端发送一个没有任何盐的散列密码，与数据库中存储的盐无关。使用 SSL 保护传输。拒绝责任意味着我的哈希密码帐户无法在其他地方打开相同密码的同一用户，为用户提供服务并增加他的隐私，并且我永远不会被指责对用户的明文密码有错误，因为我从未收到过他们。这对我的系统来说并没有增加安全性（也没有降低），但非常酷。
更酷：将足够长的固定盐硬连线到客户端，当客户端已经传输哈希（硬连线盐+普通密码）时，现成的彩虹表会失败。我的项目中使用的散列方法当然在 JavaScript 中可见（在本例中为 SHA-256），这可以防止巧合地使用相同方法与其他站点发生散列冲突。