为什么在提交（并再次在服务器上再次对其进行哈希处理）之前，客户端中几乎没有网页会在客户端中对密码进行哈希处理，以“防止”密码重用？

46

Internet上有许多站点需要登录信息，并且防止密码重用的唯一方法是“保证”密码在服务器上被散列，但这并不总是正确的。

因此，我想知道，在将密码发送到服务器之前，在客户端计算机（使用Javascript）中创建一个哈希密码的网页有多困难？从理论上讲，这不会提供任何额外的安全性，但是在实践中，这可以用来防止不会在服务器中哈希密码的“恶意站点”。

— 马丁·菲克斯曼（MartínFixman）
source

18

如果服务器只是在比较哈希，

3

最好的解决方案是（imo）客户端密码管理器。这样，您可以生成一个随机的字符串作为密码，而不必依赖服务器来“保护”您。

— 迪恩·哈丁

2

@Jarrod-在我看来，就像使用不同客户端哈希算法的不同网站一样，可以阻止该漫画描述的攻击。一个广泛使用的密码通过那些不同的哈希算法变成许多不同的密码。客户端哈希计算不会阻止应用其他类型的安全性-例如通过安全连接发送哈希。

— Steve314 2011年

2

@ Steve314我的意思是，默认情况下客户端上的任何内容都受到破坏。您可以进行哈希运算，哈希clear运算和哈希运算，如果它是在客户端上完成并在服务器中来回传递给服务器的，那只是数学上的自慰。我必须修复一个继承的系统，该系统是按照您和OP描述的确切方式设计的，它一直被Wireshark的青少年所黑客入侵。我们只有在进行REAL加密和加密并对所有往返服务器的有效负载进行签名后才将其锁定，帐户操作停止，此后再也没有发生。

5

听起来您保护自己免受流氓站点攻击的计划是要求流氓站点设置更好的安全性。？

— pc1oad1etter 2012年

46

为什么不使用它？因为零增益需要大量工作。这样的系统不会更安全。它甚至可能不那么安全，因为它给人一种更高安全性的假象，从而导致用户采用不太安全的做法（例如密码重用，字典密码等）。

— 赖恩·亨里斯（Rein Henrichs）
source

2

到目前为止，这是最好的答案。

1

就像蓝光和DVD加密一样。它甚至不需要钥匙来解锁。它提供的唯一“保护”是，当DVD首次面世时，购买光盘进行复制所花费的成本要比购买电影的完整副本所花费的成本高。当然，现在您可以花一美元购买DVD，甚至更多的事实是，密钥已经成为公众知识。蓝光光盘也是如此

— 迈克尔·布朗

2

我认为对客户端密码进行哈希处理确实可以增加安全性。如果我正在收听，则只能看到您的哈希，而看不到您的密码。如果服务器发送了质询（应有），则该哈希甚至不可重用。

— Andomar 2012年

2

我认为x4u的方法非常适合安全性要求介于网上传输密码和使用证书之间的某些应用程序。我认为有些反对者忽略了密码的散列，除了标准服务器端凭证处理外，还进行了密码散列。所以问题是这样的：x4u的建议是否提高了在有线场景下传输密码的安全性。我说是的。实现这一点的关键在于使用每密码盐。

— LOAS

6

防止MITM攻击的正确方法是端到端加密。TLS（https）存在：使用它。不要发明自己的加密方案。

— Rein Henrichs

14

从理论上讲，这不会提供任何额外的安全性，但是在实践中，这可以用来防止不会在服务器中哈希密码的“恶意站点”。

这究竟如何保护您？听起来您要做的就是散列哈希密码，这毫无意义。因为散列的密码将成为密码。

Internet上有许多站点需要登录信息，并且防止密码重用的唯一方法是“保证”密码在服务器上被散列，但这并不总是正确的。

如果不对一个以上的站点使用相同的密码，该怎么办？从理论上讲，网站对密码进行哈希处理的原因是，如果密码被盗用，则可以阻止您访问帐户。对多个网站使用相同的密码只是愚蠢的。

如果您确实使用过javascript，那么所有“黑客”所要做的就是在哈希哈希密码上使用相同的方法。一旦获得了哈希信息，就需要计算数据库中的password-> same hash，这是阻止访问帐户的一个因素。

— 猎犬
source

1

如果您的浏览器始终以相同的方式进行哈希处理，那么可以，您的哈希可以在其他任何地方用作密码。但是，如果浏览器在哈希并将其发送到站点之前根据站点（也许是域？）分配了盐怎么办？我认为这是一个有趣的想法。

— Tesserex 2011年

2

如果它在客户端上受到威胁，则客户端上的任何盐都可以清楚地看到，这是一个不合逻辑的问题。如果您不理解@Ramhound的答案，则不应该编写需要安全的代码，并从一开始就开始阅读安全性和加密技术。

3

当您引用原始海报时，请按照以下格式设置文本格式（选择文本并使用编辑器上方的引用图标）

— Marjan Venema

1

贾罗德（Jarrod），请您遵循自己的建议，并在做出荒谬的主张之前对自己有所了解。中间攻击的人对具有合理盐长度的安全哈希函数毫无用处。我的建议绝不是“默默无闻的安全性”，它实际上是安全的，这是基于该领域专家当前已知和接受的，并且在许多协议中都以相同的方式使用它。这不是我的发明，我只是将一个易于理解的过程应用于网站登录。您的错误假设显然不会被许多其他人所接受，因此不会获得任何实质内容。

— x4u

3

如果盐是客户端已知的，并且是从服务器以明文形式发送的，则中间的任何人也都知道。从来没有说过，我需要撤消哈希，如果您知道客户端上的盐，那是不安全的。

11

因为这几乎没有价值。散列的原因是，如果您的数据库被黑客入侵，则黑客将没有有效密码列表，而只有哈希表。因此，他们无法模拟任何用户。您的系统不知道密码。

安全来自SSL证书以及某种形式的身份验证。我希望我的用户提供密码，以便可以从中计算出哈希值。

同样，哈希算法将在服务器上更安全的区域中。将其放在客户端上，即使隐藏了参考脚本文件，也很容易获得Javascript的源代码。

— 乔恩·雷诺
source

3

这是最好的答案。您应该在传输层进行加密。如果不这样做，其余的就是不安全的。是的，您可以编写加密功能...但是该功能对（恶意）最终用户可见。使用SSL。

— pc1oad1etter 2012年

哈希算法的安全性不应该取决于它是否是秘密。用于安全性的哈希算法应该是一种单向函数：即使您拥有代码，也很难撤消它。相反，您应该使用专门为密码设计的众所周知的哈希库。如果它不为人所知，那几乎肯定是马车或目的不当。

— leewz

6

解决方案比这简单。客户证书。我在计算机上创建了一个客户端证书。当我在网站上注册时，我们使用我的客户证书和服务器证书进行握手。

不会交换任何密码，即使有人入侵数据库，他们所拥有的只是我的客户端证书的公钥（服务器应该对它进行加密和加密，以提高安全性）。

客户端证书可以存储在智能卡上（并使用主密码上传到安全的在线保管库）。

这一切的美丽之处在于它消除了网络钓鱼的概念...您永远不会在网站中输入密码，而只是与该网站握手。他们得到的只是您的公钥，没有私钥是没有用的。唯一的敏感性是在握手过程中发现冲突，并且一次只能在一个网站上进行。

微软试图在Windows中使用Cardspace提供类似的功能，然后将其作为开放标准提交。OAuth有点类似，但它依赖于中间的“发行方”。另一方面，InfoCard可以自行发行。这是解决密码问题的真正方法……完全删除密码。

OAuth是朝正确方向迈出的一步。

— 迈克尔·布朗
source

5

尽管对于某些用例而言，客户端证书是一种合理的方法，但它们不能轻易添加到网站登录中。它们需要用户的大量合作，并取决于用户私钥的安全性。私钥的使用既可以安全也可以方便，但不能同时使用。

— x4u 2011年

5

这里的大多数答复似乎都完全忽略了客户端密码哈希的意义。

重点不是要确保对您正在登录的服务器的访问安全，因为拦截哈希值并不比拦截纯文本密码安全。

关键是要确保用户密码的安全，这通常比单个站点的登录访问权限更有价值，因为大多数用户将其密码用于多个站点（他们不应该这样做，但现实是他们这样做是不应该放弃的））。

ssl非常适合防止mitm攻击，但是如果服务器上的登录应用程序受到攻击，ssl将无法保护您的用户。如果有人恶意访问了Web服务器，则他们很可能能够截取纯文本格式的密码，因为在大多数情况下，密码仅由服务器上的脚本进行哈希处理。然后，攻击者可以使用类似的用户名在其他（通常更有价值）的网站上尝试这些密码。

安全是深度防御，而客户端哈希只是增加了另一层。请记住，虽然保护对自己站点的访问很重要，但是由于其他站点上的口令可重复使用，保护用户密码的保密性更为重要。

— 拐杖的
source

2

接受的答案可以很好地分享您的观点。即使“大多数答复”没有，并且因为您的答案并没有真正增加太多价值，所以没有必要复活这个问题。

— 弗兰克，

它可能更像是评论，而不是答案（对无法弄清楚如何添加到接受的答案评论线程表示歉意），即使我的观点在接受的答案中是共享的，但由于回答似乎很不明确，刷掉它。感谢您的反馈

— 糟糕的

@Frank接受的答案太长而无法打扰阅读。它过多地详细介绍了如何实施该方法，并最终忽略了收益。在其他答案中使用TL; DR是有益的。

— 2013年

2

@Jules：这就是为什么存在编辑的原因。

— 罗伯特·哈维，

1

@JarrodRoberson我认为您将安全性与不安全感混淆了吗？如果发生了MITM，已经放弃了对该站点的访问，不是吗？除非您使用客户端证书而不是密码，否则这对于普通用户而言将过于复杂。按照我的看法，假设每个哈希算法都是唯一的，则客户端哈希可以防止在其他站点上泄露相同的密码。它可能不会更安全，但是在任何方面都不会更安全吗？那么，为什么要如此努力呢？我从meta碰到了这一点，这是到目前为止我看到的最好的答案。

— zypA13510

1

绝对有可能，实际上您不需要等待网站。

看看SuperGenPass。这是一个书签。

它仅识别密码字段，将您输入的内容与网站域连接起来，对其进行哈希处理，对其进行某种程度的修改，以便仅在密码中获得“允许的”字符，然后才将您的哈希密码发送到网络上。

通过在此过程中使用站点域，即使您始终重复使用相同的密码，您也可以获得每个站点的唯一密码。

它不是非常安全（base64-MD5），但是如果您愿意，可以完美地分发基于sha-2的实现。

唯一的缺点是如果域更改了，在这种情况下，您将需要让网站重置密码，因为您将无法自行恢复它……尽管这种情况很少发生，所以我认为这是一个可接受的权衡。

— 马修·M。
source

这是我阅读问题时所想的。对于站点执行其自己的客户端哈希来说，这实际上是没有用的，但是这样做的浏览器扩展（使用基于域的某种盐）将有效地消除与密码重用相关的风险。当然，当您尝试从另一台计算机登录时，有趣的部分就来了

— Aaronaught

3

这比其他任何以明文方式通过密码的方案都不安全。它使密码具有唯一性，但仍未加密；但是，如果我在中间有服务器，则可以获取复杂但仍清晰的密码，并按需要使用它，并且不会更改。哈希不是魔力之子，它甚至不是加密，它们被称为加密哈希，但这并不意味着它们就是加密。不管我的密码是password和还是password客户知道的SHA-256 带有一些盐，中间附件中的一个人都可以捕获它。

@Jarrod Roberson：您当然可以使用密码，但是您不能将其再次用于我的其他帐户。因此，如果我连接的一个网站被盗了他的密码库，并且将其以明文形式存储，那么我的其他帐户是安全的。

— Matthieu M.

@Aaronaught：那就是它真正闪耀的地方。由于发送的密码完全来自您登录的网站域和您选择的主密码，因此只要拥有书签，您就可以从任何计算机（和浏览器）登录。这就是为什么它比证书更舒适的原因。

— Matthieu M.

6

@Jarrod：这不是网站的安全措施，而是用户的安全措施。如果每个人都使用这样的方案，那么密码重用就不会成为问题。MITM方案可以使用客户端哈希密码来访问该站点，但只能访问该站点。这就是改进之处。通常，您希望仅通过破解一个密码就可以访问许多帐户，因为该密码很可能会被重用。在这种情况下，实际上可以保证该破解密码仅对在其中找到的网站或数据库有效

— 。– Aaronaught

0

我喜欢X4u的答案，但是在我看来，应该将它集成到浏览器/ html规范中，因为它目前仅是答案的一半。

作为用户，这是一个问题-我不知道我的密码存储在数据库中时是否会在另一端进行哈希处理。我和服务器之间的线路可能已被加密，但是我不知道密码到达目的地后会怎样处理-密码可能以纯文本格式存储。数据库管理员可能最终会出售数据库，而在您不知道该数据库之前，全世界都知道您的密码。

大多数用户重复使用密码。非技术人员，因为他们没有更好的了解。技术人员，因为一旦获得第15个密码，大多数人就没有机会记住它们，除非他们将它们写下来（我们都知道这也是一个坏主意）。

如果Chrome或IE或我使用的是什么，都可以告诉我，使用服务器生成的盐立即将密码框作为客户端哈希，并有效地对密码本身进行沙箱处理-那么我想知道，作为用户，我可以重用风险较小的密码。我仍然希望加密通道，也不要在传输过程中掉落任何屋檐。

用户需要知道他们的密码甚至无法发送到服务器，而只能发送给哈希。目前，即使使用X4U的解决方案，他们也无法知道情况是否如此，因为您不知道该技术是否正在使用。

— 克里斯·内维尔
source

1

它已集成到浏览器中的查询摘要身份验证中，您将看到在HTTP中执行的来回步骤，以散列密码，附加信息并在服务器上进行了验证。

— gbjbaanb

-1

我认为这是在构建诸如框架，CMS，论坛软件等之类的东西时使用的一种好方法，在这些地方您无法控制可能安装在其上的服务器。也就是说，是的，您应该始终建议使用SSL进行登录和登录活动，但是某些使用您的Framework / cms的站点将没有SSL，因此他们仍然可以从中受益。

正如其他人指出的那样，这样做的好处不是MITM攻击不允许其他人像您一样登录该特定站点，而是该攻击者随后将无法使用相同的用户名/密码组合来登录到您可能拥有帐户的其他数十个站点。

这样的方案应该与随机盐或某些特定于站点和用户名的组合盐一起撒盐，以便获得密码的人不能将其用于其他站点上的相同用户名（即使是使用相同哈希方案的站点）），也不要针对可能具有相同密码的网站其他用户。

其他人建议用户应该为他们使用的每个站点创建唯一的密码，或者使用密码管理器。虽然这在理论上是合理的建议，但我们都知道在现实世界中依靠它是愚蠢的。做这两种事情的用户所占的比例很小，我怀疑这种情况很快就会改变。

因此，如果网站所有者和最终用户都疏忽大意，那么JavaScript /密码哈希器至少是框架/ cms开发人员可以采取的措施，以限制有人在传输途中截获密码（这在如今的wifi网络上很容易）关于安全性（他们可能是）。

— matthewv789
source