J. *_*ver 9 security passwords hash design-patterns hmac
嘿,首先,让我说,我不是在问md5之类的东西(md5(......,已经有关于它的话题了).
我的问题是:
我们允许客户在本地存储密码.当然,我们不希望它们存储在计划文本中,因此我们在存储和/或发送之前将它们本地hmac.现在,这很好,但如果这就是我们所做的全部,那么服务器将拥有存储的hmac,并且由于客户端只需要发送hmac而不是纯文本密码,攻击者可以使用服务器中存储的哈希值访问任何人的帐户(在灾难性的情况下,当然有人会获得对数据库的访问权限).
因此,我们的想法是通过hmac在客户端上对密码进行一次编码,将其发送到服务器,然后通过hmac对其进行第二次编码,并将其与存储的两次hmac密码进行匹配.这将确保:
当然,所有其他东西(强密码,复盐等)也适用,但与问题无关.
实际的问题是:这听起来像一个坚实的安全设计?我们是否忽略了以这种方式做事的任何缺陷?这样的事情可能有安全模式吗?
附录:我们不希望在客户端上以纯文本本地存储密码的原因是因为很多人仍然使用相同的密码进行多项服务,因此获得"真实"密码会更大用户的安全漏洞比窃取他的哈希漏洞更严重.
blo*_*art 12
我正在跑出门,但是Skeet砰的一声,你不要乱搞Skeet.
你正在做的是用另一个常量值替换密码.你在这里什么也得不到,你唯一的安全就是无法在客户端机器上发现纯文本密码.
你接下来要做的是处理HMAC(你确定你的意思是HMAC?如果是这样,密钥来自哪里,并存储?)密码作为密码本身 - 你将它从客户端发送到服务器所在的服务器它用于验证.第二个HMAC或散列是没有意义的 - 您正在与发送的值进行比较 - 它是任何其他名称的密码.因此,作为攻击者,我只需要窃取存储在客户端计算机上的HMAC,而不是窃取密码.这里什么都没有.
正如其他人所说的那样,将客户端和你的系统隔离开来,这并没有真正为你买任何东西 - 第一个哈希就变成了密码.
如果(很可能)客户端在其他系统上使用相同的密码,则会出现该值.在这种情况下,如果客户端计算机受到危害,那么至少您的哈希密码的本地副本不允许攻击者访问其他系统.显然,客户端的攻击者将现在能够访问你的服务器-他们,毕竟,得到了密码.
有权访问服务器上的双散列值的攻击者不会购买任何东西,因为他们无法反转它以获得单个散列(即"密码").当然,如果攻击者能够读取您的安全数据库,那么我怀疑他们有其他可用的攻击向量:)
另外,正如另一张海报所说,确保你在两个哈希上使用盐.如果不这样做,如果密码不强,则反转哈希实际上可能非常简单.
编辑 - 实际上,考虑一下,因为你使用哈希作为密码,你真的不需要在服务器上使用salt.没有人能够创建一个有效的彩虹表:)虽然在客户端仍然需要一个.