User P@$$w0rd does not exist [...]
或
An account failed to login: P@$$w0rd [...]
（其中P @ $$ w0rd是实际用户的密码）
很明显找出密码属于谁：通常，同一日志文件上的上一个或下一个（不成功）事件将告诉您同一用户触发的事件。
任何其他分析师，只要查看日志，都可以得到其他人的凭证，而到期所有者甚至不知道该凭证；最坏的情况是网络窃听或实际的日志文件泄露。
我正在寻找一般指导以帮助防止这种情况。我认为简单地屏蔽用户名是不可行的，即使这样，这也可能会消除很多日志分析，因为它们无法告诉谁做了什么。
注意：已经有一篇文章在类似的问题上，但我正在设法解决该问题。
如果不小心在用户名字段（Windows登录）中输入密码，会有什么风险？
接受的答案：我希望我可以从列表中选择一些答案。不幸的是，我只能在论坛中坚持一个，但实际上我可以将它们结合起来。非常感谢您的所有回答；我看到没有单一的解决方案。因为我同意添加“事物”会增加复杂性，从而增加安全漏洞的可能性，所以我必须同意大多数选民的意见，即@AJHenderson作为第一种方法具有最优雅，最简单的答案。绝对是SSL，并且可以在服务器甚至客户端上进行简单的代码验证。当我寻求缓解的不是恶意用户，而是分散注意力的用户时，这样做会很好。一旦到位，如果合适的话，我们可以开始考虑将实施扩展到不良用户。再次非常感谢大家的投入。
#1 楼
一种想法是，如果密码框中没有值，则不允许表单提交。通常，如果他们不小心在用户名中输入了密码，那么密码对话框中可能就没有任何内容。值得注意的是，这不必简单地在客户端完成，但也可以在服务器上完成，只要所使用的传输是安全的并且在通过密码字段不为空的检查后才记录输入。
评论
简单而优雅。希望我能给它+5。
– Iszi
13年5月5日在18:27
绕过的javascript控件会通过存在风险的导线发送用户名。它会被类似于wirehark的东西所选择，如果它的ssl仍然是，例如sslstrip Thoughtcrime.org/software/sslstrip
–撒丁
2013年5月5日19:39
太糟糕了，我们不能说服MS为Windows登录对话框实现此功能。
–丹在火光中摆弄
13年5月5日在20:33
@asadz-是的，这并不是针对攻击者的行为的预防措施，问题只是关于可以采取什么措施来防止用户出错而将密码最终保存在日志文件中。
– AJ亨德森
13年5月5日在21:18
如果没有现代浏览器中的JavaScript控件，是否可以保证？ HTML5之前是否有任何类型的表单必填元素（john.foliot.ca/required-inputs）
– Eric G
13年5月5日在21:19
#2 楼
假设您的后端应用程序和SIEM需要查看对各种应用程序的失败登录尝试（并因此显示“ User P @ $$ w0rd is not valid”错误消息），那么停止该操作就不会很容易了。但是，确保所有发送包括用户名和密码在内的敏感数据的应用程序都实施HTTPS（使用SSL加密的HTTP）是确保网络设备和网络上的任何人都不会获得错误输入的密码的好方法用户名框！
评论
确实。可以解决我一半的问题/疑虑。 +1。非常感谢。
– Lex
13年5月5日在16:32
我猜ssl是一种解决方法，而不是代码修复。问题最好只能从根本上解决。
–撒丁
13年5月5日在17:35
@asadz：应用程序输入错误时显示用户名的事实不是应用程序错误，它是预期的功能，不需要修复imo。
– Fixulate
13年6月6日在9:34
@ devcity2012预期的功能也许但未曾想到；在软件工程中有需求分析的一部分；这是最好在序列图中显示这些东西的地方；为什么在提交之前不检查表格？输入验证无效？
–撒丁
13年3月6日在9:48
如果表单使用用户名和密码，并且两者都存在，则后端配置为显示用户名，如果用户在用户名文本字段中错误地输入了密码，则这不是应用程序错误。
– Fixulate
13年6月6日在9:50
#3 楼
因此，问题在于您不希望分析师看到敏感日志文件中的密码吗？警告：即使您使用Javascript，它也不会处理以纯文本格式存储在磁盘上的密码数据。
一个更好的选择解决方案是在分析师看到日志之前先对其进行预处理，然后在日志中删除信息。
如果将行列入白名单或将其他行列入黑名单，则可以进行逐行筛选。例如：
当用户名出现在具有模式（[az] +数字）或（[az] +句号[[az]）
在AD环境中包含一个域名，后跟一个斜杠“ \”
出现多次
在分析人员看到之前，可以针对已知用户名的LDAP目录进行清洗它
您还可以通过以下方式识别密码并将其列入黑名单：
密码策略通常遵循一种模式（一个符号，上/下，x字符...）
您可以使用此知识来构建自定义日志数据清除程序，以保护您不希望分析师看到的信息。
过滤后的行是什么样的？
您可以通过对可疑用户名进行哈希处理，然后为它们分配一个人类ID并将其存储在安全的位置，来简单地编辑有问题的用户名：<分析人员可以查看哈希重复出现的次数是否一次又一次地出现特定的条目。br />
eb574b236133e60c989c6f472f07827b Redact1
7e67b89a695bfbffc05b7ed2c38f927f Redact2
..etc
分析人员可以查看特定条目是否一次又一次地发生。
您选择的确切哈希方法（或加密方法）存在风险，因为此“哈希数据库”将包含高价值信息。而且播种（根据其性质）将阻止频率分析，这可能对您没有价值。
评论
+1是一个好主意，始终假定日志包含敏感信息，除非已明确编辑或除非另外证明。
–丹尼尔·普赖登（Daniel Pryden）
13年6月6日在6:27
#4 楼
我只能确定您正在讨论的三个问题。用户输入的信息不正确。以明文形式发送，并且容易被中间人窃听。
我认为，这很容易解决。
勉强接受用户错误。
不要记录无效的用户名，而是记录失败的尝试和IP。
不要以明文形式发送用户名。使用HTTPS之类的技术或使用JavaScript编码纯文本（例如ROT13）。
登录失败然后重试成功的示例日志。
[00:00:00] An account failed to login from 192.168.1.100
[00:21:00] Successful login 'root' from 192.168.1.100
在阅读其他答案时，我想包括此内容。
在提交之前验证所有字段。
请考虑分解一下之间的表格如Eric G所提到的多页。
评论
我不确定“用javascript自己滚动”到底是什么意思，但是我很确定这是个坏主意。
–塞缪尔·埃德温·沃德（Samuel Edwin Ward）
13年10月10日在18:23
-1永远不要在JavaScript中滚动自己的https。如果这不是您的意思，请澄清。
–半比特
13年8月24日在14:24
我澄清了@ makerofthings7。我从没说过在JavaScript中滚动https，而是说或javascript（已加密）。尽管不是最容易正确实现的解决方案，但仍有一些资源可用于这种解决方案。这是一个有效的答案，我不明白为什么它值得一个负数。
–弥敦道
13年8月28日在20:07
从服务器传送带有加密代码的Javascript（这似乎是您描述的）很少是一个好主意。服务器可以修改该JS代码并公开本地私钥。另一个向量是XSS / CSRF。这是一个冒险的安全设计。 HTTPS应该是最低要求。让我知道您是否正在考虑其他部署，例如包装在PhoneGap中的HTML / SPA应用程序或类似的应用程序。
–半比特
13年8月28日在20:49
@ makerofthings7，我的思维过程不适合中间人。那是一罐蠕虫。我在偷听。我使用的其中一个系统使用javascript（使用随机密钥）对所有表单数据进行了编码，以使同事之间不会互相窥探。
–弥敦道
13年8月28日在21:25
#5 楼
我看到一些银行（至少在Web应用程序中）实现的解决方案是进行两页登录。在第一页上仅接受用户名
在该过程的下一页上，要求输入密码，并且仅回显用户名，因此它不是可编辑字段
因此第二页上唯一的输入应该是密码。由于用户知道必须使用用户名清除第一页，因此他们知道必须清除该门，因此第二页上的唯一选项是密码。
如果可以实施此工作流程，它将帮助用户集中精力键入内容和输入时间。
此外，考虑您的日志记录：也许您可以更改您的日志记录以不包括实际凭据？
例如，成功登录后，请使用主键ID而不是回显输入：“ ID为'2342342'的用户已尝试登录”，然后单击“ ID为'2342342的用户”已成功提供密码”。
如果您查找并且用户名不存在，则类似“来自IP地址'192.168.0.10'的用户尝试使用无效的用户ID登录”。
这将是您的应用级别日志。 Web服务器日志可能包含查询参数，因此可能难以解决，或者您可以在操作之间以及在写入日志时根据某些规则编写某种类型的代理过滤器之间放置某种类型的代理过滤器。这将是特定于平台的，但看起来可能可以在Apache上实现。
作为辅助控件，请限制对正在处理的各种日志文件的读取访问。
评论
串行身份验证？也许
–撒丁
13年5月5日在19:50
实际上，两步表单是我最有可能绊倒并在第一页的用户名字段中输入密码的地方！
–卡莱布
13年3月7日在11:01
我想对UX案例有更多的了解，您是否有任何理由认为这种情况会发生？网站登录是否在重复访问时存储您的用户名？我想这会有所帮助（但可能会造成伤害），因为如果预填您的用户名，您甚至都不需要输入框。让我知道更多详细信息，然后看看是否可以在响应中添加一些其他信息。
– Eric G
13年8月8日在3:58
感谢我的回答，这使我减少了对我的一家银行这样做的沮丧。
– enderland
13年9月9日在2:17
#6 楼
一般来说，所有客户端代码都足够聪明，足以处理基本错误用户ID和/或密码丢失
密码与准则不匹配
所以在无论如何，当您仍然在日志中看到这些条目时，
User P@$$w0rd does not exit [...]
An account failed to login: P@$$w0rd [...]
没有一个客户端验证有效，并且系统最终通过网络发送了未加密的密码。那么“密码”字段中的内容是什么？绝对不能为空，因为客户端验证将失败。它必须与密码有所不同
，因此要进行两次通过身份验证
第一次通过，将所有加密的详细信息（包括密码）发送到服务器。验证密码字段是否为空。
第一遍，验证密码是否与准则否则错误提示相符。
第一遍，接下来检查数据库中是否存在密码。如果没有错误，请发送
。
将RPC响应发送回客户端，然后让它立即发送用户ID和密码。流程是
将风险降至最低。请注意，您无法消除不信任客户端的风险。
最后，由UX专家审核您的界面。可能是您的界面存在缺陷，导致用户在ID字段中输入密码。
评论
很好的建议。我认为到目前为止，这里的大多数答案都做了一个很好的总结，这很有意义。 +1
– Lex
13年5月5日在19:30
#7 楼
从您对体系结构的描述来看，这是不可行的，但是我认为正确的解决方案是：不要以明文形式发送用户名，也不要记录失败登录尝试的用户名。用户名和密码唯一应该去的地方是检查密码的子系统。在此之前，用户名是未经身份验证的任意数据-任何有权访问登录表单（在Web应用程序中是整个Internet的用户）都可以键入他们想要的任何内容，但是他们经常想要输入-因此对您的兴趣很少。 （除非您的登录表单未暴露于Internet。）这可能会消除很多日志分析，因为它们无法告诉谁做了什么....？
给出的用户名没有正确的密码，您不知道请求实际上是来自该用户的，因此您仍然不知道是谁尝试登录。
评论
+1是向我提出有关我们是否真的需要知道用户名的问题。我倾向于认为我们仍然需要在日志中使用用户名，但是如果参数足够强大，则可以说服用户。原因之一是使用关联引擎将时间，频率，源IP和目标IP与用户名放在一起。就像我说的那样，关于它仍然没有非常定论的观点，但是感谢您的想法：它使我可以对此进行更多思考。@ KevinReid
– Lex
13年3月7日在11:40
#8 楼
通常的问题是基于密码的身份验证。每个家庭旅馆都坚持要求使用密码进行身份验证。这很愚蠢。让其他一些身份提供者为确保凭据安全而进行艰苦的工作。与StackOverflow一样：允许使用OpenID，Gmail等进行身份验证。
您的用户将感谢您不需要在某个地方输入另一个密码。
#9 楼
客户端javascript似乎很合理。在提交之前，请检查密码字段是否为空。检查用户名的格式是否正确。要求用户名是电子邮件地址的地方尤其优雅。您还可以在密码设置/更改机制中禁止使用电子邮件地址形式的密码。然后，在提交表单之前，只需检查用户名是否为有效电子邮件地址即可。可以使用特殊字符或数字类似地完成此操作。 （例如，密码中必须包含数字/特殊字符，但用户名中禁止使用数字/特殊字符。）此外，对所有表单提交都使用最新的库SSL（应这样做是为了防止网络窃听者聆听）。需要提升的权限才能读取这些日志（例如，Web服务器帐户可以写入这些日志，但只有root可以读取它们）。一旦密码未通过身份验证步骤，请勿将用户名传播到其他系统。 （还可以在不同的内部系统之间使用SSL来防止网络窃听。）
#10 楼
我喜欢我目前的公司针对此问题采取的方法：如果您在错误的框中输入密码，自动化系统会导致您的密码立即失效。因此，用户必须更改密码，并且日志中的密码现在不再容易受到攻击。当然，如果用户仍在将该密码用于其他系统，这仍然不是理想的选择，但希望被迫更改其密码将使用户更加意识到可能的安全风险。
评论
这是如何运作的？是否根据数据库中存储的密码检查用户名，如果匹配，则强制重置？该网站是基于Web还是Windows / LDAP级别？如果是这样，这是风俗还是现成的产品？
– Eric G
13年6月6日在5:14
@EricG：这是一个自定义系统，我没有构建它，所以我真的不知道它是如何实现的。也就是说，我相信它可以通过散列用户名并对照密码哈希检查哈希来实现。我的理解是，他们将“可疑情况下发现的密码”保存在某个数据库中，并使与此列表匹配的所有活动密码都过期。
–丹尼尔·普赖登（Daniel Pryden）
13年3月6日在6:23
@jcolebrand：对不起，我想我已经解释了：将输入用户名字段的内容进行哈希处理，并对照密码数据库检查哈希值。如果您的密码数据库很大，并且想快速检查，则可以选择使用Bloom过滤器之类的方法。不过，我不知道这是否是他们的实际工作：也许还有更好的方法。
–丹尼尔·普赖登（Daniel Pryden）
13年6月6日在22:05
这实际上可能是一件事。然后的问题是我可以放入1234567或password1等，并使整个Lotta密码无效。如果我认为我知道我的好友密码，等等。
– jcolebrand
13年3月6日在22:21
我和EricG在一起。我不明白如何以安全的方式实际实施此操作。如果密码数据库使用盐存储密码（并使用慢速密码哈希（例如bcrypt）），则验证不正确的用户名是否实际上是某人的密码并不容易，如果是，请找出密码的真实性，这是您所能做的最好的事情对数据库中的所有用户进行详尽搜索，这是不可扩展的。如果密码数据库不使用salt（或不使用慢速密码哈希），那么您将遇到更严重的问题，这绝对是不行。
– D.W.
13年3月7日在8:57
#11 楼
最简单的答案是正确的答案。现在，我们注意到每个电子邮件地址在域名之前都有一个“ @”符号。在密码中使用“ @”作为不可接受的键可以使解决方案变得显而易见。如果用户名不包含@，并且所有用户名都是电子邮件地址，则仅记录其中至少包含@的电子邮件地址。
现在，如果用户名DONOT具有“ @”，则可能会使某些用户感到愤怒但这是一个很好的解决方案。也就是说，在密码之前必须有一个单字符。就像所有电子邮件帐户的用户名一样，格式也一样。无论答案是什么，所有答案的开头或结尾都有一个特殊字符。因此，当用户输入密码时，您会让他知道需要输入密码。
第三种解决方法是使用COLOR CODING。将用户名字段设置为黄色，将密码字段设置为红色。红色通常会引起您的注意，因为它用于敏感物品。因此，即使他们在看键盘，也会非常快速地了解到密码是红色的。
所以基本上，文本字段和密码标签是红色的，最好在单独的框中，用户名标签和文本字段都为黄色。
评论
使用电子邮件地址作为用户名在公共应用程序中远未普及，在内部应用程序中很少见。颜色编码不太可能会有所帮助：使用错误字段的常见原因是不注意哪个字段（特别是当用户名字段通常被预先填充但由于某种原因不在其中时）。
–吉尔斯'所以-不再是邪恶的'
13年6月6日在15:52
#12 楼
为什么不只是回应呢？That username does not exist
评论
您可能不应该这样做，甚至在响应中花费不同的时间。这样的响应有时会浪费处理时间的差异，从而提供了有效的用户名列表，这些用户名甚至可以用于尝试访问站点/服务本身之外的其他原因（例如，他们可以尝试向gmail等相同的用户名发送电子邮件）。
–加里·韦弗（Gary S. Weaver）
13年5月5日在20:17
@ GaryS.Weaver：<-是的。例如，您在蛮力工具中创建了A / B测试，每当遇到不同情况时，您就知道已经标识了有效的用户名。
– Eric G
13年5月5日在20:22
@ GaryS.Weaver没有万无一失的解决方案，但您不认为这有点过分吗？他没有运行americanexpress.com
– Alex Gordon
13年5月5日在20:31
@Артём-Царионов由您，他和其他所有人来实施他们认为合适的安全措施。
–加里·韦弗（Gary S. Weaver）
13年5月5日在21:10
问题是用户名最终出现在日志文件中，该日志文件以纯文本形式永久记录了用户名。如果服务器受到威胁或管理员不诚实，他们可以访问用户的帐户，而无需在系统中进行任何记录。日志文件仍然需要知道正在尝试使用哪些用户名，因此，如果将密码放在用户名字段中，则该解决方案将需要以某种方式防止将密码存储在日志中。
– AJ亨德森
2013年5月5日21:25
#13 楼
您对接收服务器对此的处理有多少控制权？似乎上述用户提出的同时对用户名和密码进行哈希处理的解决方案可以通过以下两种方法进行操作：方法1（需要JavaScript）：哈希用户名和密码。在数据库中，存储散列的用户名，然后使用该字段进行身份验证查找。如果您可以控制服务器上数据的处理方式，但不控制其日志记录容量，那么这将是理想的选择。方法2（不需要JavaScript）：照常接收纯文本用户名，但是一旦在服务器上收到它，便像方法1一样将其转换为哈希。如果尝试失败，请记录哈希值，而不要记录用户名。日志将仍然有用（如果仔细检查，则用处不大），因为每个哈希仍将唯一地标识用户。这些都不像这里的最高响应那么优雅（我也建议您使用它），但是它们更加详尽。
#14 楼
一个简单而烦人的解决方案可能是使用HTML按钮在屏幕上的键盘布局，其中用户只能使用这些按钮键入其用户名，这样可以防止犯错，我意识到这可能会令人讨厌，但首次登录后，您可以使用Cookie记住用户名，而无需再次使用它。当然需要Javascript。现在，不可能意外地以纯文本形式发送密码。希望对您有所帮助。评论
是的，但是人们从笔记本电脑登录Windows域又如何呢？我们也收集这些日志。
– Lex
13年7月7日在11:42
#15 楼
我有不同的看法...您要真正解决什么问题？密码错误？即当您看到某人使用“密码”（或变体）时，是否希望能够追溯到用户并进行更正？
明文发送的密码？
还是那些白痴的人无法键入或读取表单（或UI可能设计不良）？
总是记住，每当您“添加”到系统时，都可能会增加复杂性，并且肯定会添加代码-两者增加在某个地方的整体体系结构中打开安全“漏洞”的可能性（可能在堆栈中，可以通过网络，也可以通过网络...）。因此，在解决这三个问题中的任何一个时，您必须衡量解决它们的价值是否值得冒一个您不知道的漏洞的风险-您知道的魔鬼总是比您不知道的魔鬼好。
现在为止。
应在设置和更改密码时通过验证规则来解决错误的密码。而且只有那里。要添加另一个位置，仅意味着您有可能使验证规则混乱或不同步。
以明文形式发送密码。谁在乎？被授予可能会“感到”不安全，但请记住，这是n部分身份验证，如果只有1个部分，则与在字典中使用单词没有什么不同。也许，也许只是如果您有一个活动的嗅探器，它可能会为他们提供一些线索，但是已经到位的入侵是您的真正问题，而不是在用户名字段中出现一些偶然的，随机的，繁琐的密码操作。现在，如果您遇到了所有明显的大问题。
问题是白痴还是UI设计不好。修复用户或用户界面。简单。在UI上提供积极的帮助，让部门接受一些培训或其他方面的培训。易于修复，需要进行有限的，低风险的编码更改（或者应该-尽管要注意UI方面）。
虽然我很欣赏这里的许多建议，但其中许多都是以精妙的想法为核心的。我建议使用KISS，而不是BS方法，请始终记住，如果添加到系统中，可能会增加不安全感。
我只需2美分。
#16 楼
仅允许传输用户名和密码的md5散列（或类似的哈希值），因此在日志文件中记录的所有内容始终看起来像固定长度的随机字符，这将使任何人都无法快速猜测它是密码或用户名的md5。
缺点：要与数据库中的用户名进行比较，您必须存储两列，例如“用户名”和“ md5（用户名）”，否则每次查询登录用户名时都必须动态哈希。
仅当用户名存在于数据库中时创建日志条目，否则仅记录ip。
仅允许用户单击使用鼠标而不是键盘单击Enter，或者仅允许在最后两个字段中输入的字符输入5秒后才允许键盘，这将使用户有时间查看屏幕并查看错误。 />
对允许的用户名和密码进行一些限制：
密码必须包含特殊字符，例如！@＃$ ％^＆*（）
用户名不得包含任何特殊字符
这样，您可以使用javascript迅速识别输入的用户名或密码。
#17 楼
生物识别技术现在相当便宜，并且至少有80％的时间可用。我发现它在TabletPC上非常有用，并且一直希望部署生物识别键盘，因为它速度更快（至少在80％的时间内）。我敢打赌，这几乎不是问题所在Win2000，WinXP，Win2003和WinVista，因为默认情况下，用户名字段已经填充了最后一个成功的用户名。不能完全确定哪个版本的ActiveDirectory或工作站已更改，但是现在默认使用的用户名字段为空，这使此问题更加普遍。
评论
@SparKot ॐ-问题在于，如果您对用户名进行哈希处理而没有常见的错误，则很难识别用户。使用用户名的常用盐，就可以对日志进行彩虹表攻击，以查找任何输入错误的密码。如果用户名存在于数据库中，仅记录日志？
我们这些不看键盘就能打字的人也会犯该错误。通常，我们实际上也不需要看屏幕，如果稍微分散注意力，这种错误很容易犯。这是Windows XP Home Edition和更高版本界面的优点，它是用户可以从中选择的菜单。当然，只有少数用户没有用。
过去，这种情况一直在我身上发生，原因如下：通常，当我解锁计算机时，它会记住我是最后一个用户，只需要输入密码即可。在恢复显示器电源之前，我经常[ctrl]-[alt]-[del]并输入密码。但是，如果我最后一次登录是通过远程桌面，则用户名将被清除。在这种情况下，按照我的常规例行程序将密码输入为用户名。
我突然觉得需要更改各种密码...而且，当我过去这样做时，经常发生的事情是我输入的速度非常快，而无意中错过了“ Tab”键以移至下一个字段。换句话说...帐户无法登录：MikeSP @ $$ W0RD