我应该在将密码发送到服务器端之前对其进行哈希处理吗？

Question

我注意到大多数站点通过HTTPS将密码作为纯文本发送到服务器.有没有什么优势,而不是我发送密码的哈希到服务器？会更安全吗？

Answer 1

这是一个老问题,但我觉得有必要就这个重要问题提出我的意见.这里有很多错误的信息

OP从未提及通过HTTP清除发送密码 - 只有HTTPS,但许多人似乎都在回应因某种原因通过HTTP发送密码的问题.那说:

我认为绝不应该以纯文本保留密码(更不用说传输)了.这意味着不能保存在磁盘上,甚至不能保存在内存中.

在这里回复的人似乎认为HTTPS是一个银弹,但事实并非如此.但它肯定会有很大帮助,并且应该在任何经过​​身份验证的会话中使用.

实际上没有必要知道原始密码是什么. 所需要的只是基于用户选择的原始文本生成(并可靠地重新生成)认证"密钥"的可靠方式.在理想的世界中,这个文本应该通过使用不可逆盐来散列它来立即生成"密钥".此salt对于生成的用户凭据应该是唯一的.这个"密钥"将是您的系统用作密码的密钥.这样,如果您的系统将来会受到攻击,这些凭据将只对您自己的组织有用,而且在其他任何地方,用户都懒惰并使用相同的密码.

所以我们有一把钥匙.现在我们需要清理客户端设备上的任何密码跟踪.

接下来,我们需要为您的系统获取该密钥.您绝不应该"明确地"传输密钥或密码.甚至不是通过HTTPS.HTTPS不是不可穿透的.实际上,许多组织可以成为受信任的MITM - 不是从攻击的角度来看,而是对流量进行检查以实现自己的安全策略.这削弱了HTTPS,并不是它发生的唯一方式(例如重定向到HTTP MITM攻击).永远不要认为它是安全的.

为了解决这个问题,我们使用一次性随机数来散列密钥.此随机数对于每次提交系统密钥都是唯一的 - 即使在同一会话期间,如果您需要多次发送,也会使用相同的凭据.一旦它到达您自己的系统,您就可以撤消该nonce以恢复身份验证密钥,并对请求进行身份验证.

此时,我会在它永久存储在您自己的系统中之前,不可逆转地将其最后一次哈希.这样,您可以为了SSO等目的与合作伙伴组织共享凭据,同时能够证明您自己的组织不能冒充用户.这种方法的最佳部分是,您永远不会在未经授权的情况下共享用户生成的任何内容.

做更多的研究,因为它有更多的内容,甚至我已经泄露,但如果你想为你的用户提供真正的安全性,我认为这种方法目前是最完整的响应.

TL; DR:

使用HTTPS.使用每个密码的唯一salt安全地哈希密码,不可逆转.在客户端上执行此操作 - 不要传输其实际密码.将用户原始密码传输到服务器永远不会"正常"或"正常".清除原始密码的任何痕迹.无论HTTP/HTTPS如何,都使用随机数.它在许多层面上都更加安全.(对OP的回答).

Answer 2

由于它是通过HTTPS,所以在没有散列的情况下发送密码绝对没问题(通过HTTPS,它不是明文).此外,如果您的应用程序依赖于HTTPS,以保持它的内容的安全,那么它的无用发送它通过HTTPS之前散列密码(即,如果攻击者能够解密方法电线上的数据,你反正旋)

Answer 3

不,实际上这将是一个漏洞.如果攻击者能够从数据库中获取哈希值,那么他可以使用它进行身份验证而无需破解它.在任何情况下,用户或攻击者都无法获得哈希密码.

散列密码的重点是添加额外的安全层.如果攻击者能够使用SQL注入或不安全的备份从数据库中获取哈希和盐,那么他必须通过强制查找纯文本. John The Ripper通常用于打破盐渍密码哈希值.

不使用https违反了OWASP Top 10:A9-传输层保护不足

编辑: 如果您在实现中计算a sha256(client_salt+plain_text_password)然后计算服务器端的另一个哈希值,sha256(server_salt+client_hash)那么这不是一个严重的漏洞.但是,它仍然容易被窃听和重放请求.因此,这仍然明显违反了WASP A9.但是,这仍然使用消息摘要作为安全层.

我所看到的最接近https的客户端替代品是javascript密钥交换中的一个难以理解的人.然而,这确实阻止了MITM的主动攻击,因此直到技术性违反了OWASP A9.代码的作者同意这不是HTTPS的完全替代品,但它总比没有好,比客户端散列系统更好.

Answer 4

通过线路发送哈希完全违背了哈希的目的,因为攻击者可以简单地发送哈希并忘记密码.简而言之,一个在明文中使用散列的体验的系统是开放的,只能通过网络嗅探来妥协.

Answer 5

明文显示的密码永远不会(甚至在使用HTTPS时)离开客户端.它应该在离开客户端之前进行不可逆转的散列,因为服务器不需要知道实际的密码.

Hashing然后传输解决了在多个位置使用相同密码的懒惰用户的安全问题(我知道我这样做).然而,这并不能保护您的应用程序,因为黑客可以通过传输哈希并让服务器接受它来获取对数据库的访问权限(或以任何其他方式获得哈希).

要解决这个问题,您当然可以散列服务器接收的哈希并在一天内调用它.

我在创建基于套接字的Web应用程序中解决问题的方法是,在连接到客户端时,服务器生成一个盐(在散列之前添加随机字符串)并将其存储在套接字变量上,然后传输此哈希给客户.在将数据传输到服务器之前,客户端获取用户密码,散列它,从服务器添加盐并散列整个内容.然后将其发送到服务器,该服务器将此哈希值与哈希值(DB + salt中的哈希值)进行比较.据我所知这是一个很好的方法,但公平地说我没有读过很多关于这个主题的内容,如果我对任何事情都错了,我很乐意纠正:)

Answer 6

免责声明：我绝不是安全专家，我发帖是希望其他人批评我的立场过于谨慎或需要改进，我会从中学习。话虽如此，我只是想强调，当它离开您的客户端时进行散列并不意味着您不必在将其放入数据库之前在后端进行散列。

两者都做

两者都做，因为：

1. 传输过程中的散列有助于覆盖传输漏洞，如果 SSL 连接遭到破坏，他们仍然看不到原始密码。就能够冒充授权用户而言并不重要，但它将保护您的用户免遭与电子邮件关联的密码读取。大多数人不遵循最佳实践，并且对许多帐户使用相同的密码，因此这对您的访问者来说可能是一个严重的漏洞。

2. 如果有人以某种方式能够从数据库读取密码（这种情况确实发生，想想 SQL 注入），他们仍然无法通过我的 API 执行冒充用户的特权操作。这是因为哈希不对称；即使他们知道存储在数据库中的哈希值，他们也不会知道用于创建它的原始密钥，而这就是您的身份验证中间件用于进行身份验证的密钥。这也是为什么你应该总是给你的哈希存储加盐。

诚然，如果他们可以自由地从数据库中读取他们想要的内容，他们可能会造成很多其他损害。

我只是想在这里强调，如果您确实决定在离开客户之前对密钥进行散列，那么这是不够的 - 在我看来，后端散列更为重要，这就是原因：如果有人拦截来自您的流量客户端，然后他们将看到该password字段的内容。无论这是哈希值还是纯文本，都没关系——他们可以逐字复制它来冒充授权客户端。（除非您按照@user3299591 概述的步骤进行操作，我建议您这样做）。另一方面，散列数据库列是必要的，而且实现起来并不困难。