双哈希密码-客户机和服务器

Question

嘿，首先，我要说的是，我不是在问像md5这样的问题(md5(.，已经有关于它的话题了)。

我的问题是：

我们允许客户在本地存储他们的密码。当然，我们不希望它们存储在计划文本中，所以在存储和/或发送之前，我们在本地对它们进行hmac。现在，这很好，但是如果我们只做了这些，那么服务器将拥有存储的hmac，而且由于客户机只需要发送hmac，而不是纯文本密码，攻击者可以使用服务器存储的散列来访问任何人的帐户(当然，在灾难性的情况下，有人将获得对数据库的访问)。

因此，我们的想法是通过hmac对客户机上的密码进行一次编码，将其发送到服务器，然后再通过hmac对其进行第二次编码，并将其与存储的，两次hmac‘’ed密码相匹配。这将确保：

• 客户机可以在本地存储密码，而不必将密码存储为纯文本
• 。客户端可以发送密码，而不必担心(太多)其他网络方
• ，服务器可以存储密码而不必担心有人从服务器窃取密码并使用它登录.

。

当然，所有其他东西(强密码、双盐等)也适用，但与问题并不真正相关。

实际的问题是:这听起来像一个可靠的安全设计吗？我们是否忽略了这样做的任何缺陷？这样的事情有安全模式吗？

增编:我们不想在本地将密码以纯文本形式存储在客户端的原因是，尽管很悲哀，许多人仍然在多个服务中使用相同的密码，因此获得“真正的”密码对用户来说是一个比让他的散列被盗更大的安全漏洞。

Answer 1

正如其他人所说，将客户端和您的系统隔离起来--这并不能真正为您买到任何东西--第一个哈希就是密码。

如果客户端在其他系统上使用相同的密码，那么这个值就会出现。在这种情况下，如果客户端机器被破坏，那么至少您本地副本的散列密码不允许攻击者访问其他系统。显然，客户端的攻击者现在可以访问您的服务器了--毕竟，他们已经获得了密码。

访问服务器上的双哈希值的攻击者不会给他们购买任何东西，因为他们无法逆转这一点以获得单个哈希(即“密码”)。当然，如果攻击者能够读取您的安全数据库，那么我怀疑他们还有其他可用的攻击向量:)

另外，就像另一张海报上说的，确保你在两个散列上都使用了盐。如果不这样做，如果密码不强的话，逆转哈希实际上可能非常简单。

编辑-实际上，考虑到这一点，因为您使用哈希作为密码，您实际上不需要在服务器上使用salt。任何人都不可能创建一个有效的彩虹表:)客户端仍然需要一个彩虹表。

Answer 2

我要跑出去了，但是斯基特敲了一下，你就不会把斯基特弄乱了。

您要做的是用另一个常量值替换密码。您在这里什么也得不到，唯一的安全就是无法在客户端机器上发现纯文本密码。

然后你看起来要做的是治疗HMAC (你确定你是指HMAC吗？)如果是的话，密钥从哪里来并存储在哪里？)将密码作为密码本身--您将其从客户端发送到用于身份验证的服务器。第二个HMAC或散列是没有意义的--您正在将其与发送的值进行比较--它是任何其他名称的密码。因此，作为攻击者，我只需要窃取存储在客户端机器上的HMAC，而不是窃取密码。这里一事无成。

Answer 3

警告:我不是安全专家。我会让blowdart看看他是否愿意加入。

如果客户端只是在存储哈希，并有效地传输基于哈希的内容，那么他们就有效地将其存储在纯文本中。第一个哈希提供的唯一好处是，如果他们在不同的系统上使用了相同的密码，那么如果哈希被泄露，其他系统就不会受到损害。

换句话说:如果有人能够获得存储在服务器上的散列，那么他们就只需要登录到系统.就像纯文本存储一样。