是的。但另一方面，您不希望日志文件可能包含密码，如果有人破坏登录并发送密码而不是用户名，就会发生这种情况。

我认为可能是一个可行的妥协可能是记录：

• 尝试使用有效的用户名和无效的密码，记录用户名但不记录密码。
• 尝试使用无效的用户名（可能是密码或其他），将用户名记录为“INVALID”。

理由是多次尝试使用单个有效用户名会告诉您可能会对该用户名进行暴力破解；针对 INVALID 用户名的大量尝试将警告大规模的“用户名具有明显密码”攻击，如果您有适当的密码策略，这种攻击虽然令人恼火但无害。对知名用户的尝试更是如此。

可以想象，有人可能会尝试暴力破解单个无效用户名；如果这是一个问题，您可能会将无效的用户名记录为（部分和/或加盐的）哈希。即使被敌对方捕获，这种明文信息的价值也基本上为零。

极少数对 INVALID 用户名的尝试可能是由于用户拼错了自己的姓名，或者输入了密码而不是姓名；或故意破坏他们的第一次登录的偏执狂，认为这是为了防止凭据被捕获。

尤其是如果紧随其后的是来自同一地址的有效登录（除非它是一个伪装成大型网络的系统......），这种偶发的身份验证错误可能会被视为噪音并被忽略。

（如果需要，您可以进一步区分一小组“有效的无效名称”，例如info、 admin*、Administrator、guest，但这可能有点过分了）。

此外，对于真正的偏执狂，您可以将所有有效的用户名和字符串“INVALID”填充为相同的固定长度（比如...... 20 个字符？）。如果攻击者有机会远程观察日志文件的增长，他将无法判断系统上是否存在用户名。

您应该记录无效的用户名。

考虑攻击者使用用户名和密码字典对您的服务执行在线暴力攻击的场景。攻击者没有对您系统上的任何特定帐户执行有针对性的攻击，而是尝试使用随机用户名。

如果您不记录无效的用户名，那么暴力攻击可能会被忽视。如果您记录无效的用户名以及 IP 地址等信息，则更有可能识别针对您的系统的暴力攻击，从而允许您采取适当的措施来阻止攻击。

您可以记录无效用户名的加密值。

如果有人从多个 IP 地址执行暴力攻击，您可以/必须通过分析 Web 服务器上的流量来识别它，而不是通过查看记录的用户名。这可以在应用层完成。如果您从某个 IP 地址收到异常数量的登录请求，您可以简单地阻止该 IP 地址（在您认为合适的一段时间内）。否则，您可能会在有机会查看记录的用户名/密码之前很久就发现您的 Web 服务器已被入侵。

但现在假设合法用户不小心在用户名框中输入了他/她的密码。如果您存储原始文本，则入侵者可以读取记录的用户名（密码）（假设入侵者以某种方式获得了对您数据文件的访问权限）。您的目标是在这种情况下使入侵者无法读取数据。这时候加密就派上用场了。

如果您使用的是 DBMS，则加密可以由数据库系统完成。例如，您可以加密存储用户名和散列密码的表/列。

如果您将此信息存储在 CSV 文件中，则可以在应用程序层完成此加密。如果您能够使用公钥密码术，那么您的生活将变得轻松。应用程序可以简单地使用公钥加密输入的值，您（或任何知道私钥的人）可以使用私钥解密它们 - 保持私钥安全应该相当容易。如果您必须使用对称密钥加密，有几种方法可以安全地存储密钥（在线搜索）。它可能不会像使用公钥加密那样安全和简单，但它比保留原始文本要好得多，对吧？

请记住，目标是让入侵成本高昂，而不是让您的系统 100% 免疫……因为这根本不切实际。

按照作为评论提供的链接makerofthings7，因为它有很多关于如何首先停止它的详细信息，但您仍然应该记录所有尝试。

为什么认证系统只记录有效用户名的无效认证尝试是不够的？

无效的登录尝试可能表明可能存在攻击。如果您只记录那些具有有效用户名的人，您将看不到所有的攻击，如果它被分发，这可能会帮助您更好地抵制尝试，或者它可能会为您提供一些其他有用的信息。

在极少数情况下，如果日志被公开/可访问，攻击者可以使用它来枚举有效/无效的用户名（每次登录时进行 A/B 测试；但如果您的日志被公开......）。

根本问题是可能会记录密码。如果用户在用户名字段中输入了密码，但仍然在密码字段中输入了一些内容，这种情况也很可能发生。

最好在存储时加密整个日志或至少用户名部分（或包含的任何其他 PII）。如果加密对于给定值始终相同，则任何 SIEM 等仍然可以关联。由于存储所有无效尝试是一个好主意，因此加密允许您将所有这些限制在密码的暴露范围内。