传输前散列密码？ （网络）

Posted 2023-04-19

【中文标题】传输前散列密码？ （网络）

【英文标题】：Hash passwords before transmitting? (web)

【发布时间】：2010-06-09 19:06:24

【问题描述】：

我正在阅读有关密码安全的Ars article，它提到有些网站“在传输之前对密码进行哈希处理”？

现在，假设这不使用 SSL 连接 (HTTPS)，a。这实际上是安全的吗？如果是这样，你会如何在安全的庄园里做到这一点？

编辑1：（基于前几个答案的一些想法）

c。如果您在传输之前对密码进行哈希处理，如果您只在用户凭据数据库中存储密码的加盐哈希版本，您将如何使用它？

d。只是检查一下，如果您使用的是 HTTPS 安全连接，是否有必要这样做？

【问题讨论】：

如果您使用的是HTTPS，请按照输入的密码发送。仍然存在潜在的漏洞，但远不如不使用SSL，而且我想不出SSL有这样的漏洞方案没有。

【参考方案1】：

只有在服务器发送不可重复使用的盐（当然，如果您使用安全哈希）时，这才是安全的。

否则，攻击者可以简单地嗅探用户哈希，然后重放哈希以作为用户登录。

请注意，登录容易受到中间人攻击。

【讨论】：

+1 当然，如果黑客可以简单地将哈希重新发布到服务器，它并不比明文密码更安全。

@Paolo：至少攻击者不能在其他网站上使用密码。

那么这是否是一个可行的实现（假设启用了 javascript）：当用户提交时，使用唯一 id 为请求进行 ajax 调用，服务器根据 id 使用不可重用的 salt 进行响应，客户端浏览器使用 SHA-1（或更好）对盐和密码进行哈希处理，然后将其传输到检查密码、ajax id、用户名的服务器？

没关系，这行不通，我刚刚阅读了 Thorarin 的帖子和 cmets 并意识到双重哈希将是一个问题。如果您在数据库中安全地存储为盐渍哈希，除非您使用某种可解密的哈希，否则您将无法将其与 ajax salt/hash 一起使用。

PS：可解密的哈希称为加密。

【参考方案2】：

我不会称它为安全的，但总比没有好。如果您让服务器在每次用户登录时选择一个哈希盐，这将防止重放。但是，没有什么可以保护用户在登录时免受中间人攻击。

当用户登录时，您必须将生成的盐存储在服务器上的某个位置。如果这是一个问题，您可以使用另一个（固定）盐对盐进行哈希处理，将结果用作校验和并将两者相加作为隐藏字段添加到您的登录表单中。

周围有一些JavaScript SHA-1 implementations 应该可以解决问题。如果可以，请不要使用 MD5。

【讨论】：

+1 -- 但如果您完全关心安全性，那总比没有好。

@tvanfosson：一个问题是您最终不得不以纯文本形式存储密码，或者使用某种双重哈希。后者使它相当复杂，收益有限。

我更担心 Mallory 会根据她传递给 Bob 的盐生成彩虹表（或者，因为她很聪明，所以会生成几个彩虹表并使用不同的盐）并最终对 Bob 的真实密码，以便她以后可以使用它与 Alice 交谈。

@tvanfosson：这是一个问题，是的。每个新的哈希值都使某人更有可能找到原始密码。如果他们足够努力:)

【参考方案3】：

您可以通过使用加盐数据库哈希生成对称加密的密钥来保护此方案免受中间人攻击。

它会像这样工作：

服务器在数据库中查找密码哈希 H_D 以及盐 S_D 服务器选择随机盐S_R 服务器通过使用 S_R 对数据库散列进行散列来生成密钥 K 服务器发送S_D和S_R给客户端

---

客户端通过使用S_D对用户密码进行散列计算H_D 客户端通过散列 H_D 和 S_P 来计算 K 客户端使用 K 加密所有服务器通信

此方案根据用户密码创建随机会话密钥K。 中间的人在不知道用户密码（或 H_D，必须保密）的情况下无法推导出 K，因此无法模拟服务器。