根据记录被拒绝的密码是常见的做法吗？，我知道记录被拒绝的纯文本密码是个坏主意，但是如果我存储被拒绝密码的散列形式呢？我想了解有关登录失败的更多信息以进行分析，例如：
检查是否只是拼写错误：如果用户第一次使用相同的哈希密码登录失败但后来成功登录，则可能只是拼写错误
检查是否有人试图猜测密码：一些常见的密码，如 123456 和生日，具有固定的哈希值，如果存在这些尝试，则可能是密码猜测者登录失败。
检查用户是否有备用帐户：有些用户可能有备用帐户但密码不同，如果用户通常使用相同的哈希登录失败，并且哈希与另一个帐户相同但登录成功，则可能是用户尝试使用其他帐户登录但忘记切换密码。
我的问题是，记录被拒绝密码的散列形式与记录纯文本被拒绝密码有同样的问题吗？
如果正确散列（即使用随机盐和强散列），散列密码是不可逆的，即使密码相同，不同帐户的散列密码也会不同。
这意味着您想要做的任何分析几乎都不能首先使用正确散列（即随机盐）密码完成，即您从记录密码中几乎没有任何收获，最多您会因为您将一些信息泄漏到某些地方而丢失攻击者可能更容易访问，因为日志通常不像存储的密码那样敏感。
当使用普通哈希代替（无盐）时，您提到的一些事情可能会以增加攻击向量为代价，因为现在攻击者可以使用预先计算的哈希表来反转您记录的密码。
也许您对正确的密码哈希意味着什么有一些误解。我推荐阅读如何安全地散列密码？了解如何正确地进行密码散列以及为什么这样做，但在下文中，我将解决您似乎有的一些误解：
检查是否只是拼写错误：如果用户第一次使用相同的哈希密码登录失败但后来成功登录，则可能只是拼写错误
您无法使用散列密码检查拼写错误，因为即使输入的微小变化也会导致输出发生巨大变化。您也无法检查原始密码中的拼写错误，因为您无法反转哈希以获取密码进行比较。要检查输入的错误密码是否始终相同，您可以按照 Jon Bentley 在评论中的建议记录使用与存储的（正确）密码相同的盐加盐的哈希值。如果日志至少与存储的密码一样受到保护，那么这只会稍微增加攻击面，但正如我所说，日志通常不像密码存储那样敏感。
... 一些常见的密码，例如 123456 和生日，具有固定的哈希值，...
正确的密码散列使用随机盐来使使用普通密码的预先计算的散列进行攻击是不可能的。这意味着相同的密码在被散列时会产生不同的散列，即您对这些密码具有固定散列的假设是错误的。同样，您可以在这里使用更容易反转的未加盐哈希，但会增加攻击面。
当输入的密码仍然可用并且只记录此分析的结果时，最好进行这种分析。
...如果用户通常无法使用相同的哈希登录，并且哈希与另一个帐户相同但随后成功登录，...
由于相同密码的哈希值不同，因此您需要最初输入的密码来进行这种比较。由于您无法从记录的哈希中获取此信息，因此记录哈希密码无济于事。同样，您可以使用未加盐的哈希值进行此类分析，但这意味着您的所有帐户都必须以不安全的未加盐方式提供密码——这大大增加了攻击面。您可能也可以使用加盐密码进行此类分析，但随后需要记录新输入的密码，并使用您当前使用的所有盐（即每个帐户一个）进行盐哈希处理。
这不是一种常见的做法，并且通常违反安全性。恕我直言，您列出的所有原因都不足以记录散列密码。事实上，我想不出一个很好的理由来记录它们。您可能会遇到合规/立法问题（例如 PCI）。用户通常会因为拼写错误、忘记他们在哪个站点使用的密码等而无法输入密码。如果您通过 syslog 使用某种日志记录，您也将在数据库以外的地方拥有这些密码，甚至是远程服务器。
这些都不是记录散列密码的原因。要直接回答您的问题，与纯文本密码相比，记录散列密码“更好”，但两者都非常糟糕，不应该这样做。
示例：HIPPA 的一部分侧重于通过遵守良好和标准做法来充分有效地保护电子受保护健康信息 (ePHI) 的必要性。根据与我合作的审计员的说法，记录密码（散列或其他）会使您不合规，因为这不是推荐的标准做法。
您正在对以下方面做出许多假设：
如果用户登录失败，可能有多种原因。例如，这可能是因为他们有多个密码并且正在循环使用它们，想知道他们在网站上使用了哪个密码......现在您从存储一个站点的用户密码的（加盐的）散列到潜在的多个（加盐的） ) 用户倾向于使用的散列密码。与电子邮件类似，我使用了多封电子邮件，我可能不记得我用于该网站的电子邮件。现在，您正在存储我的电子邮件以关联它们（这部分取决于您将密码与用户逻辑相关联）。基本上，您正在为您网站的潜在未来对手制作用户名/电子邮件和密码组合的概要。你的一些想法：
“检查它是否只是拼写错误”
你为什么在乎？如果是错字，则用户打错字并弄清楚了。如果您的目标是开发指纹识别来告诉攻击者暴力破解，还有其他方法。这对于正确加盐和散列的密码也是不可能的。这就是加盐和散列的目标，您自己不应该不费力气就对原始纯文本进行逆向工程。如果你没有纯文本并且散列算法很好，你将无法判断是否有错字。
“检查是否有人试图猜测密码”
首先，确保实际用户没有这些密码。其次，还有其他方法。第三，如果您真的想要，您可以在流中对输入进行哈希处理并将其与已知弱密码的哈希值进行比较，如果是这样，则记录它匹配的内容，无需以任何形式记录密码本身。
“检查用户是否有备用帐户”
除非您有明确的理由这样做，否则违反您的条款，从用户的角度来看，这是不需要的。此外，正确加盐和散列的密码不会立即与系统中的其他记录进行比较。这就是加盐的重点，因此无法匹配各种纯文本输入的预先计算的哈希值。因此，如果某人确实在两个不同的帐户中拥有相同的密码，那么根据添加到他们的盐是随机的概念的哈希值无论如何都不会匹配。即使它们确实匹配，也可能是完全不同的用户使用相同的密码或密码只有一个字符（错字或密码变体）。
这个想法几乎违反了所有存在的安全概念。我不会推荐它。
Steffen 的回答是正确的，但我认为重要的是要知道您有其他选择而不记录散列密码。我的答案假设您正在运行一个登录的外部网站。如果它是内部的，您可以存储有关他们登录的计算机/设备的几乎所有内容。
检查是否只是拼写错误：如果用户第一次使用相同的哈希密码登录失败但后来成功登录，则可能只是拼写错误
只需在用户失败和成功时记录。您可以运行报告并查看用户是否经常在第一次登录时失败。
检查是否有人试图猜测密码：一些常见的密码，如 123456 和生日，具有固定的哈希值，如果存在这些尝试，则可能是密码猜测者登录失败。
记录登录尝试的 IP 地址。虽然这是一种常见做法，但您必须确保在您经营的地方以合法的方式执行此操作。如果您在不熟悉的地方登录，许多网站需要额外的信息。
检查用户是否有备用帐户：有些用户可能有备用帐户但密码不同，如果用户通常使用相同的哈希登录失败，并且哈希与另一个帐户相同但登录成功，则可能是用户尝试使用其他帐户登录但忘记切换密码。
这似乎是其他两个答案的组合。