发行数字用户名的银行相当烦人。虽然我比大多数人更偏执，但你可能是对的，有人只是粗暴地摸了他们的身份证，直到他们把你锁在门外才意识到这一点。

为了回答这个问题，一些银行确实帮助确保您尝试使用正确的用户帐户登录。您在某些银行登录页面上看到的那些“安全图像”，是的，银行告诉您这些图片可以帮助您确保您正在登录他们的网站。但真正的好处是帮助用户意识到他们正在尝试登录其他人的帐户。使用此过程的站点将在主登录页面上询问您的用户名，然后将您带到一个带有“安全图像”和密码字段的新页面。如果您从以前从未见过您登录的计算机登录，他们还可能会在询问密码之前询问另一种形式的身份验证（安全问题等）。

如果您每次登录时都会看到您在注册时选择的图像，那么您更有可能（假设您经常使用该网站）注意到该图像何时不同。这可能意味着您正在登录网络钓鱼站点，但更有可能的是，您对用户帐户进行了粗暴的操作。

编辑：-回答您的编辑-

在处理数字用户 ID 时，只有 10 位数字，并且它们被塞在 10 键和移动设备上的一个非常小的区域内。考虑到数以万计（或数十万）的用户、数字的稀缺性以及它们在三种常见布局中的两种布局中的接近程度，实际上没有办法充分确保任何一个 ID 与另一个 ID 足够不同以防止常见的错误输入错误.

此外，如果您从性能的角度考虑，在大多数设计良好的系统中，检测新 ID 是否为 uniq 是一个非常有效且快速的过程。但是，检测新 ID 是否与其他 ID 不同需要遍历所有其他用户 ID，并将两者与您的算法进行比较。这将是一个（相对）缓慢而痛苦的过程。如果有足够的时间和精力，您可以缓存 ngram 和任何其他比较点来帮助加快速度，但仍然会很慢。

简而言之，我不知道有任何公司在用户 id 上这样做，当然不是在数字上。（但我很乐意阅读有关某人这样做的白皮书或工程博客）

其他几个用户（包括 Philipp）提到了校验和数字，我没有讨论它，因为我最初关注的是系统方面和问题的不同用户名焦点。但进一步考虑，它确实在这次谈话中占有一席之地。校验和通常用于增加帐号，即信用卡号，任何第一学期的编程学生都可以为其编写验证工具。这几乎消除了错误输入，并且可以在客户端检查，而无需发布到条目表。不可能说（没有内部知识）是否有人在数字用户帐户上使用它......我敢说有人是，但我还没有看到它，因为它不会在社区内引起有趣的讨论（或文档），所以没有听说有人这样做。我想我们都同意，你的银行不是。:)

您可以通过获取一个连续数字并附加一个或多个附加数字来生成密码，这些数字是实际数字的校验和。您可以通过检查用户输入的校验和数字是否与密码的实际部分匹配来检查客户端密码的有效性。

一个校验和数字将意外输入另一个用户的有效密码的机会减少到十分之一、二到一百零三到一千分之一。

然而，缺点是密码越长，越难记住，这反过来又会导致人们忘记密码并再次消耗人力来恢复密码。这意味着系统的设计者必须在人们输入他人密码和忘记密码所产生的不便之间找到适当的平衡。

他们阻止了对您帐户的攻击。这是一个理想的结果——如果他们能够尝试无限制的密码，他们就会猜到你的。攻击及时停止，给您带来了一点不便。如果这种模式被重复以严重给您带来不便，银行可以简单地给您一个新的随机密码。

他们对防止廉价的不便不感兴趣，因为他们对防止代价高昂的欺诈不感兴趣。

编辑：

随机分配的 8 位数字的问题是，如果您不必定期使用它，您可能不会记住它。你怎么记得你的号码是 82640927 还是 82604927？

长期以来用于减少拼写错误的是 Luhn 校验位算法。它将验证号码，提示系统要求用户重新输入号码，如果任何一个数字不正确，或者一对数字被意外调换。信用卡已经使用了几十年。但是 Luhn 算法不会阻止所有偶然的问题，也不会阻止故意的尝试。

减少意外碰撞的最好方法是增加潜在的数字空间，并在数字空间中随机分配用户。如果用户编号为 0000000001、0000000002、0000000003，那么简单地拥有 10 位数字并不会停止冲突……实现此目的的一种方法是使用顺序种子，然后将其输入哈希算法以生成 10 位数字（采用底部四个字节的无符号整数是实现此目的的一种方法。）它足够随机，任何两个数字都不会相互关联，从而使意外的拼写错误确实很少见。Luhn 数字也可以用作礼貌检查，以帮助用户不要浪费时间在明显错误的帐号上输入密码。

Web 服务可以考虑登录请求的来源位置，并与您过去的登录尝试相关联。类似于信用卡公司在发现您的信用卡上有“异常活动”时会与您联系的方式。这是在网络上提供服务的组织可以用来解决此类事件的一种逻辑。如果他们可以高度自信地说与连接关联的用户名不是您 - 他们可以采取措施隔离这些事件，以免影响真实账户。

在您的情况下，如果尝试使用您的帐户 ID 登录的个人与您来自同一地区 - 或者如果他们确信这是一个完全不同的地理区域，银行可以对逻辑进行编程或分析师推断。

另一条有助于他们了解情况的途径是他们可以从事件中获得的日志。听起来您所说的客户服务代表无法访问所述日志 - 并且可能不具备查看它们的专业知识。即使他们这样做了——谁说应用程序详细记录了这些信息？他们甚至想要它吗？那么有多少人可以访问这些信息？

在这些情况下，高级逻辑会很快变得棘手。在这种情况下，您的银行如何处理这听起来像是所有相关人员最直接且成本最低的回应。如果您在服务中的唯一中断是与您的银行打了 5 分钟的电话 - 这是解决潜在高损失情况的一种非常低影响的方式。