客户端密码哈希 [英] Clientside password hashing
问题描述
我和我的一个朋友正在讨论在将其发送到我们的服务器之前是否应该对我们的Web应用程序用户的密码进行预哈希处理.
A friend of mine and me are having a discussion about whether we should pre-hash the passwords of the users of our webapp before sending it to our servers.
我知道已经有多个问题可以解决此主题，但是它们都是关于将其安全地传输到服务器的问题.我们的想法不是关于传输安全性(我们使用SSL)，我们希望对客户端进行哈希处理以防止真实"密码到达我们的服务器.
I know that there are multiple questions that already handle this topic but they're all about transferring it securely to the server. Our idea is not about the transfer security (we use SSL) we want to hash clientside to prevent that the "real" passwords reach our server.
这个主意是在Twitter宣布他们的bug导致密码以明文形式打印到日志文件时出现的.
The idea came as Twitter announced their bug that caused passwords to be printed to a logfile in cleartext.
我们目前正在讨论这个概念是否有意义，以及如果我们要使用SHA512对其进行哈希处理的话，它将如何影响密码的安全性(就Bruteforce而言).
We are currently discussing about whether this concept makes sense or not and how it affects the security of a password (in terms of Bruteforce) if we would hash it with SHA512.
TL; DR:
我们想在客户端对密码进行哈希处理，以防止我们的服务器以明文形式获取密码(我们使用SSL进行传输).
We want to hash passwords clientside to prevent our servers from getting them in cleartext (we use SSL for transfer).
这有意义吗?
哪种算法最适合用于散列?
Does this make any sense?
What algorithm would be best to use for hashing?
然后，将使用bCrypt将散列的密码再次在服务器端进行散列.
The hashed passwords would then serverside be hashed again with bCrypt.
推荐答案
100％有意义:实际上，这个概念已经由许多人提出，但是困难在于正确实现.如果做错了，则会有很多陷阱，最直接的陷阱就是如@ swa66所描述的那样容易受到哈希传递"的影响.为了防止这种情况，您需要在两侧进行哈希运算.客户端哈希应较慢(bcrypt，scrypt，argon2或pbkdf2)，而服务器哈希应较快(sha256).
It 100% makes sense: in fact, the concept has been proposed by a number of people, but the difficulty is in implementing correctly. There are a number of pitfalls if you do it wrong, the most direct one is being vulnerable to "pass-the-hash" as @swa66 describes. To prevent that, you need to hash on both sides. The client-side hash should be slow (bcrypt, scrypt, argon2, or pbkdf2) whereas the server side hash should be fast (sha256).
编辑:许多人在不了解其工作原理的情况下对其进行了否决，因此，我现在在此处包括基本细节(以前，我仅链接至此工作原理).这个想法是在客户端应用慢速哈希(例如bcrypt)，然后在服务器端应用快速哈希(例如SHA256).需要快速散列来防止散列攻击.在数据库泄漏的情况下，攻击者可以通过散列反转快速散列(不可能-违反了密码散列函数的单向属性)，也可以强行将原映像强行映射到快速散列(不可能-大小为慢散列的输出长度(例如bcrypt的184位)，或者蛮力组合慢散列和快速散列-使攻击者回到相同的位置，就像整个计算已经发生一样服务器端.因此，在数据库泄漏的情况下，我们不会通过将大量计算转移到客户端来降低密码攻击的安全性.
EDIT: A number of people have down-voted this without understanding how this works, so I now include the basic details here (previously I only linked to how this works). The idea is to apply a slow hash such as bcrypt on the client side, and then a fast hash such as SHA256 on the server side. The fast hash is required to prevent pass-the-hash attacks. In the event of the database leak, an attacker either hash to invert the fast hash (impossible -- violates the one-way property of a cryptographic hash function), or brute force the preimage to the fast hash (impossible -- the size is the length of the output from the slow hash, for example 184-bits for bcrypt), or brute force the combination of the slow hash and the fast hash -- which puts the attacker back at the same position as if the entire computation had happened server side. So we have not reduced the security of password attacks in the event of a database leak by shifting the heavy computation to the client side.
我已经在保护Web数据库中密码的方法中调查了许多类似的建议应用程序.此外，我分析了利弊，找出了以前没有发现的弱点(帐户枚举)，并提出了一种安全地做到这一点的独特方法.该研究基于许多来源，包括:
I've surveyed a number of proposals like this in Method to protect passwords in databases for web applications. Additionally, I analyse the pros and cons and identify weaknesses that have not been identified before (account enumeration), and propose a unique way of doing this securely. The research is built off a number of sources, including:
- 安全身份验证:部分客户端关键拉伸…请检查/批评我的想法
- 如何安全地对密码进行哈希加密?-请参阅客户端哈希"部分
- 客户端密码哈希
- 在Hacker News上来自不同作者的讨论-参见oleganza，mschuster91的评论，十字军等...
- Secure authentication: partial client-side key stretching… please review/criticize my idea
- How to securely hash passwords? -- see section on Client Side Hashing
- Client side password hashing
- Discussion from various authors on Hacker News -- see comments from oleganza, mschuster91, crusso, etc...
您引用了Twitter的示例，而GitHub也做了类似的事情.当我在上面撰写论文时，防止服务器看到明文密码的最著名示例是Heartbleed，我在论文中对此进行了评论(第1.3节的底部).
You cite the Twitter example, and GitHub did similarly. When I wrote the paper above, the most prominent example for preventing a server from seeing the clear text passwords was Heartbleed, which I comment on in the paper (bottom of Section 1.3).
There has been subsequent follow up research by others identifying similar ideas -- Example: Client-Plus-Server Password Hashing as a Potential Way to Improve Security Against Brute Force Attacks without Overloading the Server. No one person deserves all the credit, but the main takeaway is yes it is a good idea if you do it securely, but you really need to understand the risks (it is easy to do insecurely if you have not read the research).
这篇关于客户端密码哈希的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
