几乎从不。

正如其他人指出的那样，这只是用“HASH（SECRET）”替换“SECRET”。更糟糕的是，他们记录了哈希，这就是现在的密码。

这是因为客户端仅根据其传输的散列进行身份验证；因此，通过在客户端级别拦截它或将其从日志中删除来了解此哈希，人们可以在未来的任何时间访问该服务，直到密码被更改。

这两件事共同否定了所有日志记录的安全性并产生了问题（您现在正在记录“数据，包括可用于进行欺诈的个性化安全凭证”，这会影响您的 PSD2 合规性）。

在客户端（用于日志记录）和服务器（用于身份验证）上使用不同的哈希值很难实现，因为服务器人员无法快速验证哈希值是否正确，除非他们知道密码（这将必须存储在明确的某处）。我不知道，可能会使用相同的哈希或两级哈希来诊断密码是否正确发送（客户端发送通行证及其哈希，第二个被记录并与哈希相同存储在身份验证记录中，或者是该哈希的哈希只是为了使事情复杂化）——但除非事情变得非常错误，否则此信息与登录状态相同。

更好的方法是让服务器发送一个唯一 ID 和一个时间戳，让客户端将密码、唯一 ID 和时间戳一起散列。然后，服务器可以将 ID、时间戳和用户名发送到只会回答是或否（或“OK”、“NO SUCH USER”、“BAD PASSWORD”、“TIMESTAMP EXPIRED”、“UNIQUEID REUSE”的黑盒“oracle”检测到”等等）。这条路：

• 服务器不知道密码（“oracle”知道）
• 日志可以安全地包含唯一 ID 和时间戳
• 哈希不能重复使用（时间戳会在一段时间后“过时”）
• 密码永远不会以明文形式传播，只有散列可以
• 唯一 id 和时间戳作为彼此的盐

您可能有兴趣查看Thinbus-srp。

发送哈希而不是密码并不能解决日志问题。如果攻击者可以访问日志并且可以读取哈希值，那么就不需要知道密码了。在登录请求中，攻击者只会发送从日志中检索到的哈希值。服务器将不知道客户端是否有密码并创建了哈希，或者客户端是否只知道哈希。

不，这不是一个很好的理由：

这从来没有帮助。该架构只是将秘密“密码”替换为秘密“密码哈希”。两者都不会落入坏人之手，因为哈希足以登录。（你永远不能假设客户端有未经修改的软件。一个简单的调试器就足以让客户端程序发送你想要的任何东西。）

他们正在记录这些哈希值，这是他们根本不应该做的，因为现在他们已经获得了登录所需的所有凭据的明文日志。

手头的问题是过度热心的日志记录，而不是密码。

据我所知，普通散列也不会为凭据贡献任何进一步的因素，所以我只看到可能有用的非常奇怪的用例（例如，如果服务器受到损害，可以避免密码重用漏洞——但是如果你的用户重复使用密码，那么你的服务器被入侵应该是他们最不担心的）。相反，我经常看到它被用作解决更严重但人们试图分散注意力的安全问题的蛇油（“神奇疗法”）——就像这个日志记录问题，或者像未加密的数据库连接之类的事情。

正如许多其他人所说，它不会帮助客户端，因为hash(password)足以让恶意方获得不需要的访问权限。但至少password不会出现在单词列表中，如果服务器被黑客入侵并且所有记录的哈希都公开。