如果在跨行发送用户密码并将其保留在内存中的纯文本中之前对其进行哈希，这会提高应用程序的安全性吗？
我假设这通过保护存储在客户机内存中的数据来减轻一小部分漏洞。但实际上，如果我们担心有人在读客户的记忆，可能会有更大的问题我们无法解决。
在客户机端散列有点不对劲。
客户端密码散列是一种常见的做法吗？这样做还有什么好处或缺点吗？
编辑：假设通信通道是安全的(SSL)。在什么条件下使用这种方法是可以接受和值得的？我之所以这么问是因为"安全专家"建议我在某些应用程序功能中使用这种方案。
- 接受的答案是错误的。如果您在服务器端对散列本身进行盐散列，那么它确实会给您带来一个优势。请参阅security.stackexchange.com/a/23285/2379，security.stackexchange.com/a/23033/2379
不。
当客户端发送东西时，无论是P还是H(P)或H(H(P))任何截获的人都可以简单地重新发送完全相同的东西，从而使类似这样的功能等同于直接使用密码。
这就是为什么您应该使用nonce；服务器可以发出一些随机垃圾k，客户机将计算H(P,k)，并将其发送到服务器。HMAC是这种方法的一种流行实现。
如果服务器从不接受同一个nonce两次，那么这是安全的，可以抵御重播攻击。
- …但这就创造了一个DOS机会：捕获发送到客户机的每个服务器nonce，并在合法客户机能够使用之前使用它；瞧，现在客户机根本无法登录，因为客户机发送请求时，每个nonce都已过期。不是一个完全实际的场景，但和往常一样，安全性需要与可用性保持平衡，有时添加一个会降低另一个。
- 正如其他答案所指出的，散列在客户机上有一些小的优势，因为许多用户在多个服务中重复使用密码。
- @Pettys：不，没有。加密或MAC保护散列有好处，但是在客户机上进行不安全和不受保护的散列没有好处。
- @piskvor：在客户机上散列密码并不能解决这个问题，而且这样的DOS机会是不可能的，因为攻击者可以在这种情况下简单地修改用户体验。
- @geocar：我同意你的主要观点，如果你依靠这个来实现端到端的安全性，那你就是在做错事；我同意你使用nonce/hmac来加强安全性的建议。我只是不同意你的绝对声明，即客户散列绝对没有好处-在其他答案中，卢卡斯阿曼，大卫桑利和用户1700819都指出了散列对客户的潜在轻微好处。
- …我可能在这里误解了一些事情-如果我是的话，请随意纠正我-但是HMAC不要求双方共享同一把钥匙，对吗？在这种情况下，如果站点使用基于密码的身份验证，但不哈希客户端，那么数据库必须直接存储密码，否则无法验证HMAC。这本身就是一个严重的弱点。通过使用h(k=密码，m=用户名)的hmac而不是直接使用密码，可以改善用户或应用程序主机的漏洞，而不会造成明显的损失。
- 如果您实际上不需要密码本身，那么存储加密的密码是愚蠢的(如果有人破解了您的服务器，那么担心所有人的密码都会立即泄漏的相关开销也会增加)，而您不需要这样做。您真正需要的是身份验证令牌。
- 好的是，攻击者将无法并行破解密码(因为他们用登录名加了盐)，您不需要每次都提供nonce(这样您就可以服务静态登录页面)，您仍然可以在第一个客户端HMAC上实现防重放攻击的HMAC身份验证，您不必存储或查看PAssword，你知道密码的安全性取决于密码本身的熵，就像它必须的那样(因为它是一个HMAC，并且它们被设计用来隐藏密钥)。
- @Parthianshot-hmac要求双方使用密钥执行计算，但不要求他们存储密钥；如果填充了H(P,的状态(您会注意到它与hmac一起使用)，则可以安全地保存该状态。
- @geocar，但根据H(P,假设，你的意思是只从密钥中获得信息，对吗？如果是这样的话，EVE可以为该状态的不同用户收集一系列这些状态，并找出哪些状态并行地比较弱——不是通过颠倒使用的单向函数，而是通过猜测可能的密码。同样的原因你需要盐。
- 使用salt，客户机不能再强制服务器证明它知道密钥(因为它不知道)。
正如其他人指出的那样，发送散列密码并不能提高您站点的安全性(因为您接受散列密码，所以坏人只需要知道散列版本)。它也不是很安全，因为坏人可能会加载你的登录页面并检查部署的JavaScript或Java。
它所做的是防止监视数据包的人能够提取密码，这是相当有用的。许多人在多个站点上使用同一个密码(除了更高安全性的站点之外，我对所有站点都使用相同的密码)，因此，如果您可以从这些站点上获得一个密码，则可以登录到其他站点上的其他帐户。
它还可以防止真正的密码被存储在您的站点上，即使是暂时的，如果您的站点被破坏，这可能会提供一点额外的安全性。
所以，虽然我认为用户端散列可能是一件好事，但不值得再麻烦了。
而且，正如其他人告诉你的，不要破坏你自己的安全。有太多的事情会出错。你不会像一个训练有素的坏人那样注意到他们。
- It's also not really secure, since the bad guy can presumably load your login page and examine the Javascript or Java deployed.良好的安全性不应依赖于攻击者不知道您的算法。所以，这一点是假的。这是你试图让你更难确定的关键，而不是算法。攻击者还可以查找实现SSL的源代码。并不意味着攻击者可以破坏SSL。
在您描述的场景中，散列与来自安全POV的密码完全相同：如果我截获了散列，我不需要知道密码，我可以将截获的散列发送给服务器。
为了避免这个问题，身份验证协议有一定的长度；安全性很难，您最好选择和实现一个理解良好的协议，而不是滚动自己的协议。
如果您的流量超过了SSL，那么您就不会被拦截，而散列则不会给您带来额外的好处。
- 唯一不等价的方法是，用户的密码(可能用于多个帐户)不在野生状态。
- @Lucasoman很抱歉，但是一个基本散列对保护密码没有任何作用，它提供了一种错误的安全感。像hashcat这样的工具可以在商品硬件上每秒运行数十亿个基本哈希。让它通过客户端散列提供任何保护的唯一方法是运行一个完整的bcrypt/pbkdf2，并进行几万或几十万次迭代，就像我们在服务器上存储密码一样。这很愚蠢，因为就服务器而言，结果散列值仍然是密码。只需使用ssl。
- @Tito"一个简单的基本散列对保护密码没有任何作用"，这是一个明目张胆的谎言。hashcat正在进行暴力攻击，这意味着如果密码有任何长度，攻击者就无法猜测。因此，如果在多个服务中使用相同的长密码，那么只有哈希的攻击者只能在接受该哈希的服务上使用它。如果每个执行此操作的站点都使用相同的哈希算法，但使用了不同的、特定于供应商的nonce，那么您实际上可以保证哈希只在一个站点上有用。
是的，你应该。P＞＜／
IEEE有日期在which emails和违约暴露密码的10万是从博客。P＞＜／
ieeelog.com http：/ / /P＞＜／
IEEE should not have暴露明显，他们的博客！but if they had the at the client端密码hashed have been近，this as就不会坏。P＞＜／
as the美国第一的答案，你应该在目前的使用。如果你不能利用足够长(例如128位)，你不真的需要担心的服务器将不重用，as the same(Ask for the不能正确crng assuming种子两次，等)。P＞＜／
不，客户端散列不能"完全"保护密码。当选择在客户机上散列密码时，提交到服务器的摘要实质上就是密码。如果部署了SSL，这本身就不是问题。
然而，这个方案最终产生的问题比它解决的要多。如果服务器在不执行任何进一步加密操作(尤其是对输入数据进行哈希处理)的情况下，将客户端提交的哈希与数据库中存储的哈希进行比较，则出于所有实际目的，密码将以明文存储。任何有权访问存储哈希的人都可以将其重新提交到服务器并获得对帐户的访问权。
简单来说，如果提交的哈希(与提交的哈希相同)通过应用程序中的任何其他漏洞(例如，通过SQL注入)泄漏，则应用程序存在一个漏洞，其中对密码的保护不充分。
如果必须修复基础漏洞，则有必要将提交的哈希视为明文密码，然后在与存储的哈希进行比较之前，应对其进行哈希处理(最好使用salt)。
- hashing at the client does not protect the password 'completely'嗯，没有什么能完全保护密码。如果你的攻击者愿意每分钟杀死一个孩子，直到你让他们在你的WordPress博客上发帖，假设你最终会让他们上传所有的猫图片。关键是它是否更加保护密码，您的答案显然是"否"。不，不是。身份验证令牌是纯文本的，但密码是隐藏的。
- 我知道身份验证令牌和密码之间的区别可能看起来很幼稚，但如果我是一个习惯性地使用主动核发射代码作为密码的人，或者我是Rush Limbaugh，我的密码是"1993年我杀了一个小女孩，这是我有法律约束力的认罪"，那么不同的是会议非常重要。
我想在一个环境让感恩；你不想知道的plaintext the client'任何密码。如果你的客户在客户端的哈希，哈希散列，然后盐和迭代的方式你会在the same plaintext PW。其他比它的愚蠢的那个点。P＞＜／
只需确保通过安全通道(SSL)发送密码即可。如果客户机可以读取应用程序的私有内存，那么很可能他们有更大的问题，比如键盘记录器。
如果你使用安全远程密码协议(SRP)，你会过得更好。它是为这个设计的。
我可以给你方法different kind of如果你have not SSL客户端的哈希密码，你可以在服务器端和客户端使用了它hashed在线商店hashing another method and them在线数据库当用户登录密码给process with the same匹配与存储的密码hashes双hashedP＞＜／
- 这里的危险，以及在其他答案的评论中提到的，是重放攻击
- @乔治·格里芬：重播攻击与混淆或加密传输有什么特别的关系？它是否也适用于纯文本传输，除了这种情况，精确的密码可能会更快，甚至在不经意间被泄露？
hashing在线客户端上另一个巨大的洞opens：你可能hashing expose the algorithm。你不要说this is whether(基于Web客户端或客户端的JavaScript =)厚，但你给他们更多的信息。is given the通道安全，你不要担心密码被sniffed the clear text。P＞＜／
如果你besides hashing algorithm……，你会好的盐，盐曝光，如果你让他们过，which means to the access数据库，他们可以decrypt摇篮到每个密码。P＞＜／
- 不是真的。1)安全性不应依赖于隐藏正在使用的算法。2)即使您知道salt，也很难解密密码(前提是使用标准方法加密密码)，除非您有一个彩虹表中的"salt"。
- 这个答案似乎误解了盐的作用。如果您对每个密码都使用相同的salt，那么您的操作是错误的，您也可能根本不使用salt。