通过 SSL 使用密码哈希
好吧，这听起来像是一个奇怪的问题。请在攻击我之前仔细阅读好吗？ ;-)
想象一下这种情况：
- 我们有一个服务器和一个客户端。
- 他们使用 SSL 进行连接。
- 客户端使用密码在服务器上创建帐户。
- 但是，他实际上通过线路传递给服务器的是密码的散列（+盐）（不是密码）
- 服务器将收到的密码散列保存在数据库中（再次用盐散列）
- 在登录时，为了进行身份验证，用户重新-发送密码的哈希值（不是密码！）。
好吧，是的，我意识到这听起来很奇怪。是的，整个对话都是通过 SSL 进行的，因此您可以只发送密码明文。是的，我意识到可以以散列形式安全地存储明文密码。
这就是我要表达的观点：真诚地说“我们永远不会知道您的密码”对我们的企业很有用。
请注意，我并不是说“我们不会以明文形式存储您的密码”，而是说我们真的、永远、永远都不知道它；你从来没有把它给我们。
（想要这个的原因并不相关，只要说用户的密码用于其他东西，例如文件加密）。
是的，我意识到你可能会说，用正常的方式来做这件事“好吧，当你进行散列时，密码只会在内存中以明文形式保存 5 毫秒”，但这更多的是关于可否认性。即，我们可以说 100% 我们甚至没有收到您的密码。
好的，问题是：
以前有人做过或听说过这种事情吗？
这样做有什么安全影响？
我很难看到缺点。例如：
- 没有重放攻击（因为对话是使用 SSL 加密的，攻击者无法看到哈希值）
- 无法查看数据库，因为哈希值本身，呃...，哈希值
OK，你现在可以跳到我身上了： ）
欢迎想法、评论。
谢谢，
约翰
更新：只是想澄清一下：我并不是建议这在某种程度上改进了身份验证过程的安全性。但是，它允许用户的“真实”密码保密，即使对服务器也是如此。因此，如果使用真实密码来加密文件，则服务器无权访问该密码。
我对自己想要这样做的理由完全满意，问题是这是否会妨碍身份验证过程的安全性。
OK this might sound like a strange question. Please read carefully before jumping on me OK? ;-)
Imagine this situation:
- We have a server and a client.
- They connect using SSL.
- Client creates account on server with password.
- But, what he actually passes to server over the wire is the hash (+salt) of the password (NOT the password)
- Server saves this received hash of password in DB (hashed AGAIN with salt)
- At logon time, to authenticate, user re-sends hash of password (NOT the password!).
OK, so yes, I realise this sounds strange. Yes the whole conversation is in SSL, so you COULD just send password plaintext. And yes, I realise one can store the plaintext password safely in a hashed form.
Here is the point I'm driving at: it is useful for our business to genuinely say "We will never know your password".
Note I'm NOT saying "we don't store your password in plaintext", but that we really, never, ever know it; you never give it to us.
(The reason for wanting this is not relevant, sufficed to say that user's password is used for other stuff, e.g. file encryption).
Yes, I realise you might say that with the normal way of doing this "well the password would only in plaintext in memory for 5ms while you do the hashing", but this is more about deniability. i.e., We can say 100% we don't even receive your password.
OK so here's the question:
Has anyone done or heard of this kind of thing before?
What are the safety implications of doing this?
I'm struggling to see a downside. For example:
- No replay attacks (since the conversation is encrypted using SSL an attacker can't see the hash)
- Can't look in the DB because the hash is itself, erm..., hashed
OK you may now jump on me :)
Thoughts, comments welcome.
Thanks,
John
Update: Just wanted to clarify: I'm not proposing that this is somehow an improvement to the security of the authentication process. But, instead that it allows the user's "real" password to remain secret, even from the server. So, if the real password is used for, say, encrypting files, the server doesn't have access to that.
I'm completely satisfied in my reasons for wanting this, the question is whether it is a hindrance to the security of the authentication process.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
考虑一些事情：
最终的结果是盐+密码成为了他们的新密码。总的来说，我同意大多数人的观点，这样做没有什么好处。
Consider a few things:
The end result is that the salt + password has become their new password. Overall, I agree with most people, there's little benefit in doing this.
在我看来，这个方案有一个我没有看到提到的好处（也许我错过了）。人们当然可以争辩说哈希+盐成为真正的密码。然而，就重复使用密码的人的安全而言，它增加了价值。如果我在您的网站上使用我的密码“asdfasdf”，并且有人破坏了您的服务器，他们将无法提取我在 dubdubdub.superfinance.com 上使用的密码。
It seems to me that there is one benefit to this scheme that I didn't see mentioned (maybe I missed it). One can certainly argue that the hash+salt becomes the real password. However, in terms of security for people who re-use passwords, it adds value. If I use my password of 'asdfasdf' with your site and someone compromises your server, they will not be able to extract my password that I use at dubdubdub.superfinance.com.
这正是密码哈希器为网络浏览器所做的事情。
每个人对你的想法的问题不是它是一个坏主意，而是它是一个坏主意。只是，由于您是客户端和服务器的开发人员，因此信任客户端的计算机而不是服务器不会给您带来任何真正的好处（毕竟，客户端可能有键盘记录器或某物）。所以回答你的问题：这对你来说只是一个障碍。
This is exactly what password hashers do for web-browsers.
The problem everyone has with your idea is not that it's a bad idea; it's just that, since you are the developer for both the client and server, trusting the client's computer but not the server does not give you any real benefit (the client, after all, could have a keylogger or something). So to answer your question: it is only a hindrance to you.
除了上面提到的问题之外，另一个问题是：除非您再次对收到的值进行哈希和加盐处理，否则您实际上是在以明文形式存储所有密码。任何获得数据库读取访问权限的攻击者都可以轻松地以任何用户身份进行身份验证。
Another problem in addition to those mentioned above: Unless you hash and salt the received value again, you are essentially storing all your passwords in the clear. Any attacker who gets read access to your database can trivially authenticate as any user at all.
所以在这一点上，真的没有任何帮助。让我们假设您的 SSL 已被泄露。他们嗅探经过哈希处理和加盐处理的密码。然后，当您的服务器接受散列+加盐密码作为他们的密码时，他们就可以发送该密码。您所做的只是添加一层复杂性（无法在密码框中输入密码），在这种情况下，他们可以手动将其发布到您的服务器。
更不用说如果它是在客户端完成的，您不仅要向他们提供您的哈希算法，还要向他们提供您的盐以及您如何组合它。
总结：我认为没有什么太大的好处，但我可能是错的。
我个人在服务器端实现了哈希+加盐，并在登录页面上强制使用 SSLv3/TLSv1。
So at this point, really it doesn't help at all. Lets assume that somehow your SSL has been compromised. They sniff the hashed + salted password. Then they can just send that as your server is accepting the hashed+salted password as their password. What you're doing is just adding a single layer of complexity (not being able to enter the password in your password box) in which case they can manually POST it to your server.
Not to mention if it's done client side you're handing them not only your hashing algorithm, but your salt and how you combined it.
Summary: No great benefit in my mind, I may be wrong though.
I personally implement the hashing+salting server-side and force SSLv3/TLSv1 on login pages.