客户端服务器
嘿，首先，让我说，我不是问像md5这样的东西（md5（...，已经有关于它的话题了。
我的问题是这样的：
我们允许我们的客户在本地存储他们的密码。 当然，我们不希望它们存储在计划文本中，所以我们在存储和/或发送之前在本地存储它们。 现在，这很好，但如果这是我们所做的一切，那么服务器将具有存储的hmac，并且由于客户端只需发送hmac而不是纯文本密码，攻击者就可以使用存储在服务器中的散列访问任何人的帐户（当然，在有人会获得对数据库的访问权的灾难性场景中）。
因此，我们的想法是通过hmac将密码编码到客户端，然后将其发送到服务器，然后通过hmac对其进行第二次编码，并将其与存储的两次hmac密码进行匹配。 这将确保：
当然，所有其他的东西（强密码，复盐等）也适用，但与问题无关。
实际的问题是：这听起来像是一个坚实的安全设计？ 我们是否忽略了这样做的缺陷？ 有没有像这样的安全模式？
附录：我们不希望在本地以纯文本形式在客户端存储密码的原因是因为尽管令人难过，但许多人仍然使用相同的密码进行多项服务，因此获得“真实”密码会更大用户的安全漏洞比获取他的哈希被盗。
正如其他人所说的那样，将客户和您的系统隔离开来并不会真正为您购买任何东西 - 第一个哈希就是密码。
如果（很可能）客户端在其他系统上使用相同的密码，则值会出现。 在这种情况下，如果客户端机器受到危害，那么至少您的散列密码的本地副本不允许攻击者访问其他系统。 显然，客户的攻击者现在可以访问你的服务器 - 毕竟他们已经得到了密码。
有权访问服务器上的双重哈希值的攻击者不会购买任何东西，因为它们无法反转获得单个哈希值（即“密码”）。 当然，如果攻击者能够阅读你的安全数据库，那么我怀疑他们有其他攻击媒介可用:)
另外，正如另一张海报所说，确保你在两个哈希上都使用了盐。 如果不这样做，如果密码不够强烈，则反转哈希值可能非常简单。
编辑 - 实际上，考虑一下，因为你使用散列作为密码，你并不需要在服务器上使用salt。 没有办法任何人能够创建一个有效的彩虹表:)但仍然需要一个在客户端上。
我正在跑出门外，但是Skeet被捅了下来，你不会与Skeet混淆。
你正在做的是用另一个常量值替换密码。 你在这里什么都没有得到，你唯一的安全就是在客户端机器上无法发现纯文本密码。
然后，你看起来要做的就是把密码作为密码本身来对待HMAC（你确定你的意思是HMAC？如果是这样，密钥从哪里来，并存储在哪里？），你可以将它从客户端发送到服务器它用于验证。 第二个HMAC或哈希算法没有意义 - 您正在比较发送的值 - 这是其他任何名称的密码。 所以，作为一个攻击者，我不需要窃取密码，而只需要窃取存储在客户端机器上的HMAC。 这里一无所获。
警告：我不是安全专家。 我会对blowdart进行调查，看看他是否有幻想加入进来。
如果客户端只是存储哈希，并有效地传输基于哈希的东西，那么他们会以纯文本的方式有效地存储它。 第一个散列提供的唯一好处是，如果他们在不同的系统上使用了相同的密码，那么如果显示散列，那么其他系统不会受到影响。
换句话说：如果有人能够获得存储在服务器上的散列，那么这就是登录系统所需的全部内容......就像纯文本存储一样。
链接地址: http://www.djcxy.com/p/3669.html上一篇: client & server