我在 Security.SE 上环顾四周，但找不到与以下问题相关的内容：
我最近注册了Chase Quick Pay，作为我通过兼职工作获得报酬的方式。我听说过愚蠢的密码要求，但从未听说过愚蠢的用户名要求。
当我注册时，我并没有真正考虑到它有多奇怪（我真的应该有，因为在过去的 3 个月中，由于政策的原因，我两次忘记了我的用户名）：
现在，Stack Exchange 引擎如此亲切地向我指出了一个问题的方向，@Polynomial 给出了一个很好的答案，在第一句话中就说明了一切：
身份验证强度应该来自密码，而不是用户名。
所以，简单地说：对用户名有这样的要求有什么意义？
编辑：为了澄清 - 有这些用户名要求有什么真正的安全好处吗？
奖励：我刚刚查看了我自己银行的用户名/密码安全策略，发现以下内容（不是那么异常）：
注意：我真的不明白不允许'X'作为第一个字母的意义......任何能回答的人都会得到+10！
对用户名选择实施要求/限制有两个主要论据。首先是使攻击者更难预测用户名有助于抵抗在线猜测攻击。虽然用户名不一定被认为与密码一样机密，但它们是必须被盗以冒充用户的至少两条信息之一。我们不应该忽视攻击者不知道这些信息的优势。
2007 年的论文Do Strong Web Passwords Accomplish Anything? (PDF)评估在线密码猜测的威胁，并考虑我们应对它的选择。网站可以执行更严格的密码策略，如果用户难以遵守并且对流程感到沮丧，这可能会损害可用性。或者该站点可以强制执行一些用户名限制并保持密码策略相同。他们的理论是，如果攻击者必须尝试许多可能的组合，无论是由于简单的用户名和复杂的密码，还是半复杂的用户名和半复杂的密码，都无关紧要。
这忽略了站点添加第二个身份验证因素以补充密码安全性的第三个选项，同时保留用户名。它还要求网站更加努力地避免泄露有效的用户名，然后攻击者可以将这些用户名与可能的密码配对。
第二个论点是，通过强制执行一些独特的用户名要求，网站可以希望阻止用户选择他们在其他网站上使用过的相同凭据。这是一个非常现实的威胁，除了强制执行不寻常的用户名要求（或自己分配 ID）之外，网站很难做任何事情。然而，2010 年的一项很棒的研究监测了人们在银行和其他网站之间的实际用户名和密码重用情况。研究发现，人们确实有 73% 的时间在其他网站上重复使用他们的银行密码，但也发现即使银行强制执行唯一的用户名约定，人们也会在 42% 的时间里至少在另一个网站上重复使用该用户名。
因此，强制执行独特的用户名要求会降低凭证共享的机会，但肯定不会消除这种可能性。但是，一些网站可能仍然认为这种较低的风险值得给用户带来不便。
另一个可能的原因是遗留系统兼容性，这与其说是争论，不如说是要求。无论什么潜在的旧软件在时髦的 Web 前端后面进行后端处理，都可能被编码为只接受以某种方式格式化的用户名。如果不删除和替换该软件，该网站可能会卡在将限制传递给客户。“用户 ID 不能以 X 开头”行让我相信这可能是您的情况的一个因素。
这些用户名要求可能导致用户名难以预测。我不认为这会带来实质性的安全性改进，但我可以想到几个场景，它们会有所帮助。我怀疑它是否抵消了可用性的损失，但我缺乏具体的证据来得出结论。像往常一样，以牺牲可用性为代价的安全是以牺牲安全为代价的。：如果用户更有可能忘记他们的用户名，这意味着他们要么必须将用户名存储在不安全的位置（违背目的），要么必须有办法让他们恢复他们的用户名（这可能不是强认证）。
不太可预测的用户名可以提高隐私性。如果我尝试创建一个johnsmith帐户但由于该用户名已被使用而失败，这告诉我 John Smith 正在与该公司进行银行业务。如果 John Smith 的帐户是johnsmith1，我需要枚举更多用户名。但是，对于用户选择的用户名，后缀1是一个很好的选择。大多数网站都依赖电子邮件地址作为唯一标记——如果我想创建一个帐户john.smith@emailprovider.example.com，我需要证明我可以阅读发送到该地址的电子邮件。银行通常不愿意依赖外部安全，因此他们往往不想依赖电子邮件提供商。
对银行的大量攻击是在家庭环境中执行的——配偶、孩子、访客等。不太可预测的用户名可以提高对可以访问受害者计算机但更有可能执行的临时攻击者的保密性机会主义攻击比认真研究他们的攻击。同样，对于用户选择的用户名，复杂性要求并没有显着提高：许多用户会将他们的用户名预先填写在浏览器中，如果他们不选择johnsmith1，攻击者可能会知道变化因为他们彼此很了解。
不可预测的用户名还可以通过尝试大量用户名+密码组合直到找到弱的组合来提高对非目标攻击的防御能力。同样，必须尝试johnsmith1除此之外johnsmith并没有提供显着的改进。
至于不以X……开头的用户 ID，它是一家银行。内心深处的某个地方是一个 COBOL 程序，该程序运行在一个模拟的 IBM big Iron 上，该程序运行在一个稍微更新的模拟 IBM big Iron 上，该程序运行在一个模拟 VAX 上，该 VAX 在 x86 处理器的虚拟机中运行。在您出生之前，有人认为通过X在第 17 列中添加一个来指示已删除的记录是个好主意。被要求修复 Y2K 错误的 COBOL 程序员也提出修复这个问题，但被告知这超出了工作规范，他不能碰一些有效的东西（如果银行这样做可能会有所不同）导演的名字是泽维尔而不是乔治）。
用户 ID 难以预测的原因可能是：
应用程序限制每个用户 ID 的密码猜测次数（网上银行的典型做法）。然后攻击者可以发起攻击“尝试所有已知用户 ID 的密码 123456”。如果攻击者不知道大量的用户ID，那么这种攻击就没有多大意义。
一个应用程序可能有一些我们不知道的设计安全缺陷。例如，应用程序可能使用用户 ID 来派生会话令牌。
可能不允许将“X”作为第一个字母，以防止某些（旧版）系统将用户 ID 解释为十六进制数字。
我同意强制使用奇怪的用户名会使破解帐户变得更加困难（因为它作为一种第二密码起作用），而不是使用与他们正在重复使用其密码的 XYZ 帐户中相同的用户名。（但强加一些要求也使用户更容易忘记自己的用户名！）
我看到在用户名上设置最小长度的主要原因是确保他们不使用像“Joe”这样的常用名称，而是强制使用更独特的名称（也许他们添加姓氏、日期……）
如果必须通过电话告知他们，限制特殊字符是有意义的。要求一封信也有助于使它看起来像一个普通的用户名。我认为在用户名中要求一个数字是没有意义的。
银行业规则总体上要健全得多。我怀疑以 X 开头的用户名是内部使用的（例如，测试用户、某些保留帐户……）。