https安全性-密码应在服务器端还是客户端进行哈希处理？

#1 楼

如果在客户端上进行哈希处理，则哈希处理后的密码将成为实际密码（哈希算法仅是将用户存储的助记符转换为实际密码的一种手段）。

这意味着您将在数据库中存储完整的“纯文本”密码（哈希），并且您将首先失去了哈希的所有优势。

如果您决定走这条路，不妨放弃任何哈希运算，而只是传输和存储用户的原始密码（顺便说一句，我不特别推荐）。

#2 楼

仅当您不以某种方式信任服务器并且不想向其显示“实际”密码（人类用户记住的密码）时，在客户端上进行散列才有意义。您为什么不希望将密码显示在该密码可以使用的网站上？因为您在其他地方重用了密码！现在通常很糟糕，但是有一个相对安全的版本，它包含在无数的浏览器扩展或书签中，例如一个或那个（我不保证其质量）。这些是人类用户记住“主密码”的工具，使用站点域名作为一种盐可以从中生成特定于站点的密码，以便两个不同的站点获得不同的密码。

尽管这种情况有意义，但使用服务器本身发送的Javascript却没有用。确实，散列密码客户端的要点是服务器可能是敌对的（例如，被攻击者颠覆），因此，该服务器发送的Javascript代码至少是可疑的。您不想在某些恶意Javascript中输入您的宝贵密码...


客户端哈希的另一种情况是慢哈希。根据定义，由于密码是弱密码，因此您希望阻止字典攻击。您假设坏人得到了服务器数据库的副本，并且将在自己的计算机上“尝试输入密码”（有关此问题的讨论，请参阅此博客文章）。为了降低攻击者的速度，您可以使用固有的慢速哈希处理（例如bcrypt），但这会使每个人（包括服务器）的处理速度变慢。为了帮助服务器，您可能需要分担客户端上的某些工作，因此至少要在客户端浏览器中运行的某些Javascript代码中完成部分工作...

不幸的是，JavaScript在这种工作上非常慢（通常比体面的C代码慢20到100倍），并且客户端系统将无法为哈希工作做出很大贡献。这个想法是合理的，但是必须等待更好的技术（不过，它会与Java客户端一起工作：对于一个不错的JVM，对于散列工作，优化的Java代码比优化的C代码慢大约2至4倍）。


总而言之，从服务器本身发送的Javascript代码进行客户端密码哈希处理并没有很好的案例。只需通过HTTPS隧道将密码“按原样”发送给服务器（登录页面，表单目标URL以及受密码保护的任何页面都应通过SSL进行服务，否则，与使用密码）。

#3 楼

我发现您的所有顾虑都不错，但我的建议是在服务器端进行操作。

用户总是有很大的机会将其终端保持解锁状态，从而可以进行操纵。并且;

另一种选择是在服务器端生成密码。那么您就不会发送明文密码。但是您仍然需要将密码传达给用户。而且由于大多数用户仍不使用加密电子邮件，因此我认为这种方法的安全性较低。

我已经看到了通过加密隧道将密码发送到手机的解决方案。但是我怀疑安全性要比SSL好。也许有人可以证明/反驳？

#4 楼

正如所有其他答案所表明的那样，对服务器端进行哈希处理很重要，但是我想补充一下，除了对服务器端进行哈希处理之外，对客户端进行哈希处理也是一项不错的安全功能。

客户端散列在以下情况下具有优势：


服务器受到威胁时保护用户的密码。即如果客户端没有受到破坏，但服务器受到攻击，如果客户端对密码进行哈希处理，则服务器仍可以访问一个系统，但是您已经保护了用户的密码，如果用户在其他地方使用该密码，这很重要。 br />当用户认为自己正在登录一台服务器但实际上正在登录另一台服务器时（用户错误），它会保护用户的密码。例如，如果我有两个银行帐户，并且我不小心在错误的银行网站上键入了我的银行密码之一，如果该银行在客户端加密了该银行的密码，那么该银行将不知道我的另一银行的密码。我认为对客户端进行哈希处理是“礼貌”的事情，这样它们的纯文本密码就永远不会通过网络传输。

大多数情况下，它表示尊重用户的密码。用户共享的秘密可能不是您的软件独有的，因此，如果您尊重该秘密，则应尽一切努力保护它。

#5 楼

如果您位于HTTPS隧道中，则应从以太网监视中保护密码或哈希值。

在客户端，也许可以用会话ID来添加哈希值。
这可能是恶意Javascript更难模拟。

#6 楼

散列密码的客户端将需要Javascript。有些人在其浏览器上禁用了Javascript。您必须处理这种情况。

我已经看到了论坛软件，该软件在客户端执行密码哈希处理，并在可能的情况下在登录时发送哈希，否则密码以纯文本形式发送。因此，无论哪种情况都可以使用。

如果您将使用https，则明确发送密码并不是主要问题。理想情况下，服务器应然后拒绝提供http中的页面，以免中间人受到攻击。原因是：攻击者可能会强制将您的连接从https降级到http，并开始嗅探流量（例如，使用SSL Strip之类的工具）。

#7 楼

@Nicole Calinoiu的公认答案当然是正确的，但是一开始可能很难理解。

重点是应该在服务器上对密码进行哈希处理，以使恶意人员无法使用哈希他已经从服务器的数据库中窃取了访问您的帐户或数据的权限。

如前所述，如果您在客户端进行哈希并且后端支持该哈希，则哈希成为您的密码，并且如果哈希通过黑客被盗，则黑客具有密码。
/>
@Thomas Pornin的回答也提出了一个很好的观点，为什么您希望在客户端上散列密码，但是他在第一个故事中描述的内容只有在后端才能完成服务器的确支持处理散列密码（即，如果已经散列，则不对密码进行散列，但是有人试图支持类似的事情是极不可能的），在大多数情况下，我猜不是这样。他的第二个故事很好。

#8 楼

您可以同时执行这两种操作，并在客户端对其进行哈希处理，因此，如果攻击者可以通过https安全性获得保护，则他们将无法看到纯文本密码。然后在服务器上再次对其进行哈希处理，这样，如果攻击者获得了存储在服务器中的密码，他就不能仅将其发送到服务器并获得对密码的访问权限。

#9 楼

如果您的服务器将拥有多个可能的管理员，并且您不一定要信任所有人都不会获得ram dump，那么您应该真正对客户端进行哈希处理，以防止管理员窃取用户密码（尽管在其他网站上可能会重用）是一种不好的做法，用户会这样做，并将继续这样做。]，然后对该哈希服务器端进行哈希处理，以使窃取表不会自动为攻击者提供网站本身的所谓纯文本密码。

只要使用安全哈希函数，就可以在双方使用相同的盐。

#10 楼

出于所有目的和目的，您只希望在客户端进行哈希处理。哈希背后的想法是防止除用户之外的任何人都不知道密码。因为任何好的站点都应该使用TLS，所以将哈希发送到服务器这一事实是无关紧要的（请注意，即使担心发送纯文本密码也同样糟糕）。

最后列出的答案似乎没有意识到，如果服务器遭到破坏，则服务器上的每个个人密码都会被泄露，因为密码是以纯文本形式发送给它的。