当用户在某处输入新密码时，提供有关系统接收到的字符数的反馈会很有帮助。
在我刚刚运行的用户体验 (UX) 测试中，我的用户在她的密码管理器中创建了一个密码短语，然后尝试将其粘贴到终端中的新密码短语提示中。但是由于当前系统没有提供反馈（即光标不显示输入的点），粘贴不起作用并不明显。
因此，从用户体验的角度来看，最好显示一些点，以便用户了解实际出现的字符。
这种反馈会显着降低安全性吗？显然，它会为肩冲浪者提供可用于缩小攻击范围的长度，但我希望对于更好的 UX 影响最小。
为了提供一些上下文，this if 用于终端命令行界面 (CLI)，特别是 Ansible 中的交互式输入提示。它现在没有提供任何反馈，但我正在考虑打开一个功能请求来这样做，并且想知道安全隐患。
知道密码的长度对于猜测或破解密码的难易程度并没有太大的影响。
如果密码很容易猜到或在字典中，则长度无关紧要。
如果密码是随机的，并且您正在尝试暴力破解（以某种方式获得了哈希），那么知道长度几乎没有什么区别，因为破解时间随长度增加的速度有多快。
例如，假设您知道密码长度为 8 个字符，但您不知道它是由什么字符组成的。以 600 亿散列/秒（从体面的 GPU 上的 MD5）暴力破解一个八字符密码（假设每个字符有 95 个可能的选项）大约需要 31 个小时。
如果您不知道密码的长度，那么您可以先尝试暴力破解较短的密码。但是将所有密码从 1 个字符暴力破解为 7 个字符只需要大约 20 分钟，因为每增加一个字符会使攻击时间延长 95 倍。
因此，通过隐藏密码的长度，您只能获得非常微不足道的收益（即大约 1%），并且仅在一种非常特定的情况下（并且攻击者尝试对哈希进行暴力攻击）。
具有这种行为的 UI 确实存在。我见过几个不提供任何视觉反馈的。我也见过一些做随机反馈的。
是安全问题吗？好吧，考虑一下密码的长度。我认为 8-15 个字符是用户的合理期望（有些用户会用更长的密码破坏银行，但我们现在将跳过它们）。该范围内有 8 种可能的密码长度，这意味着您“泄露”了 3 位信息。
鉴于我不相信有任何密码强度算法可以给出精确到 3 位以内的结果，我认为有充分的理由说明为什么几乎所有密码输入都会泄露这些信息。用户体验的价值足以超过安全优势（请记住，可用性和安全性始终处于平衡状态。您不能只关注其中一个）。
确实，我发现越来越多的系统可以通过单击按钮来显示您的密码。因此，如果有的话，实际系统开始远离“模糊密码长度”。
我能想到的唯一真正受此影响的攻击是，如果我碰巧在整个公司中搜索密码长度，并使用它来优先考虑较短的密码以尝试首先破解。但即便如此，也很难争辩到底是哪个问题：显示的密码长度，或者它首先是一个弱密码的事实。
威胁场景极为有限。必须亲自到场并能够计算“点”才能获得长度。这比能够阅读文本更困难，因为大脑没有有效解析的模式。然后他们仍然必须暴力破解密码。
即使攻击者获得了大致长度范围的知识，以这种方式提供反馈也不会以任何显着的方式降低凭证的风险。
一般来说，不，这只能提供极其有限的安全收益，以换取显着的用户体验下降。
不显示键入的字符有两个安全优势：
鉴于正常的蛮力攻击是如何工作的，第一个“好处”的价值有限。暴力破解密码的规范是从某个较低的字符限制增加到任意最大字符数。因为知道长度只能有效地节省您检查较短密码的时间，但可能的密码数量与密码的长度成指数比例，因此可能节省的时间可以忽略不计（平均可能只有几个百分点）。
第二个“好处”可以防止非常特定类型的理论攻击。实际上，如果您有密码中输入的每个字符之间的延迟数据，您可以将其与来自目标用户的大量输入数据相结合，以优化暴力攻击的搜索顺序。在实践中，这将是非常不可靠的，如果受害者设备上没有键盘记录器（此时，你最好只使用它来刮取密码），收集参考数据集将非常困难，而受害者只是使用密码管理器完全回避了这个问题。尽管如此，我实际上听到人们严肃地谈论这种类型的攻击，作为隐藏输入的密码字符的论据，因此我在这里完全提到了它。
相反，您最终会得到零反馈给用户，即输入任何内容都有效，这对许多用户来说是一个巨大的用户体验限制，尤其是当他们被训练期望出现模糊字符时。
附带说明一下，您应该避免某些网站和许多 10 英尺 UI 设计的行为，即显示最后输入的字符一秒钟或直到输入新字符。这仍然可以防止偶然的攻击者，但是任何真正想要主动窃取密码的人只需要一个具有不错分辨率和快速帧速率的相机来读取用户的密码，并且与只有一个按钮让用户取消隐藏文本。