通过HTTP连接使用哈希代码有什么好处

时间:2014-03-15 07:08:42

标签: security hash

我想知道我们何时通过HTTP发送数据并哈希密码,为什么攻击者需要实际密码并使用字典攻击? 只要将收到的哈希码与商店哈希码进行比较,他们就可以在请求中使用哈希码并访问我们的站点。 如果是真的那么Hashing有什么优势呢!为什么不保护我们并加密呢?

3 个答案:

答案 0 :(得分:2)

如果您真的要发送哈希进行身份验证,这实际上没有提供任何安全优势,因为哈希实际上将成为新密码。但通常它是以另一种方式完成的:客户端发送密码,接收器对其进行哈希处理并将其与存储的哈希值进行比较。当然,您应该加密此通信以防止窃听者。如果攻击者以某种方式访问​​您的数据库,则只存储密码版本的密码以使其更难恢复。

答案 1 :(得分:1)

您所描述的不是使用散列密码的正确方法,并且确实存在您所指的安全漏洞。

通常,这样做的方法是保护通信通道(例如,使用带有由认可的证书颁发机构签名的证书的HTTPS)并将密码发送到服务器。然后,服务器对密码进行哈希处理,并将其与该用户的正确密码的哈希值进行比较。

在服务器上散列密码可以保护站点用户免受网站本身的侵害(使攻击者更难以获取数据库并获取与他们可能在其他站点上使用的用户名相关联的密码列表

将密码发送到服务器并非绝对必要,但每个替代方案都需要权衡。替代方案包括:

  • CHAP - 要求服务器存储明文密码。
  • 证书 - 失败的易用性测试(很难)。

答案 2 :(得分:1)

这里有两个不同的问题。

您要解决的第一个非常正常的问题是如何保护存储服务器端用于身份验证的密码。首先,您应该阅读How to securely hash passwords?。然后选择SCrypt,BCrypt或PBKDF2,确定迭代计数/工作因子,它占用您在峰值负载期间可用的时间量,使用8到16个字节左右的加密随机盐,并存储盐(明文) ),迭代计数/工作因子(明文,因此可以简单地增加),以及数据库/存储介质中产生的哈希值。

如果您选择PBKDF2,请注意PBKDF2-HMAC-SHA-384和PBKDF2-HMAC-SHA-512的64位实现会降低优势攻击者的利润率,因为2014年早期的老式GPU已超过您的大概CPU由于这些GPU的64位操作速度非常慢,所以基于解决方案。

另外关于PBKDF2的注释 - 特别是对于密码散列,从不选择大于本机散列大小的输出大小。对于SHA-512,即64字节,SHA-384是48字节,SHA-256是32字节,SHA-224是28字节,SHA-1是20字节。

您要解决的第二个问题是如何保护从客户端到我的服务器的运动密码。通常,人们只需依靠TLS就可以了。但是,如果您愿意,可以使用与服务器端相同的技术客户端(上图),然后当您在服务器上获得密码哈希时,您仍然应用SCrypt / BCrypt / PBKDF2,就好像您在' d从客户端收到明文密码!因此,获取身份验证数据库副本的攻击者仍然无法通过正常的应用程序通道登录,直到他们使用针对正确哈希密码的常规攻击方法,因为他们必须发送的哈希值不同于数据库中的哈希值!

为了回答标题中的问题,除了要求窃听者做工作以确定用户输入的内容之外,基于HTTP的哈希并不会做太多事情 - 他们仍然可以使用哈希对您的应用程序进行身份验证。改为使用HTTPS!