强制Alpha-Numeric用户ID

时间:2008-09-18 22:46:46

标签: security web-applications finance user-experience

我是金融机构的程序员。我最近被告知要强制所有新用户ID至少有一个alpha和一个数字。我立即认为这是一个可怕的想法,我宁愿不实现它,因为我认为这是一个反功能和糟糕的用户体验。问题是我没有很好的理由不执行这个要求。

你认为这是一个好的要求吗?

你有什么理由不这样做吗?

您知道我可以参考的任何研究吗?

  

编辑:关于密码,这是。我们已经有类似的要求,我不反对。

9 个答案:

答案 0 :(得分:4)

反对此的一个论点是,其他区域中的许多用户名/ ID不需要数字组件。用户更有可能更好地记住他们在其他地方使用的用户ID - 如果他们不需要包含数字,则更有可能。

此外,根据系统的不同,当连接到外部系统时,用户ID可以作为默认值运行(ssh在unix类系统下以这种方式运行)。在这种情况下,拥有一个在系统之间共享的ID显然是有益的。

在多个位置使用相同的ID可以提高一致性,这是良好软件界面的一个众所周知的方面。要证明人们与系统的交互方式是用户界面并且应该遵守(至少某些)众所周知的界面指南并不太难。 (显然,如果您考虑多个(可能是未知的)系统之间的交互,那么像键盘快捷键这样的想法就没有意义了,但是一致性等方面都适用。)

编辑:我假设此讨论涉及用户名或公开可见的ID, NOT 与安全性直接相关的内容,例如密码。

答案 1 :(得分:4)

我首先会问他们背后的具体原因。一旦你有了一个项目符号列表及其原因,就可以更容易地反驳或提供替代方案。

至于一般想法:

  • 这是意见,但在用户名中添加数字不一定会增加安全性。人们在便利贴上记下用户名,大多数用户只需在用户名的开头或结尾添加“1”,便于猜测。
  • 从可用性的角度来看,这很糟糕,因为它打破了常态。强制他们在用户名中添加数字只会导致上述观点。他们只需在用户名的末尾或开头添加“1”即可。

请记住,身份验证系统越复杂,普通用户就越有可能找到绕过它的方法并使链中的链接变弱。

答案 2 :(得分:1)

用户ID?要求密码是字母数字通常是一个好主意,因为它使它们更容易抵抗字典攻击。它对用户名没有任何意义。拥有名称/密码组合的重点是名称部分不必保密。

答案 3 :(得分:1)

如果你在金融机构工作,可能会有关于此类事情的规定,所以很可能不在你的手中。但您可以做的一件事是在用户输入无效ID时向用户说明。不要等到他点击提交;在字段旁边显示某种消息,并在输入时更新它。

答案 4 :(得分:1)

上面的一些答案有一个反驳论点:如果用户选择他们在其他网站上使用的相同用户名,那么他们也可能会为金融网站选择相同或类似的密码,从而降低安全性。 / p>

不这样做的理由:如果你对用户施加的限制比他们习惯的更多,他们就会开始写下登录信息,这显然会损失安全性。

我所拥有的两个银行账户都需要一个字母数字用户名和两个用于在线登录的密码。其中一个也有我必须记住的图像。这两个密码必须每月更换一次。因此,我在这里有一个文本文件的所有登录信息。 (即使看着它也没有任何意义;我将不得不再去银行并重新设置我的密码。这是6次登录时总共7次密码重置。谈论安全性,甚至不是 I 可以访问我的帐户。)

答案 5 :(得分:0)

如果它的密码是好的(唉,金融公司喜欢否认你这种担保权利[我跟你说美国快递]。)

用户名,我说不,除非他们愿意。

答案 6 :(得分:0)

在呼叫支持时,(通常)需要在手机上引用用户名,因此与密码不同,它会被公开。此外,用户名字段不会在密码字段等浏览器中被屏蔽掉,因此它会有更多的曝光并在各个地方进行缓存/记录,因此增加的安全性的“好处”将立即撤消。

你制作的内容越难,用户就越有可能将其写下来,这又会破坏安全性(实际上同样适用于密码策略,但这是另一个故事!)

答案 7 :(得分:0)

我也在金融机构工作,我们的用户名(真人和生产ID)都是小写的,按字母顺序排列,最多8个字符,我从来没有认为这是一个问题...避免0和O的混淆,1 vs I,8 vs B - 除非你和我一样在同一家公司工作,并且即将实施一项新政策......

答案 8 :(得分:0)

添加任何功能都会增加成本。现在需要时间来构建和测试它,并在将来支持它。如果没有充分的理由,就不应该构建任何功能。

此功能毫无意义。用户名不应该保密,因此拥有强大的用户名没有任何优势。可能值得花时间使密码(或其他身份验证因素)变得强大,但用户应该能够将其用户名传达给其他用户而不会带来安全风险。

如果您的应用程序对用户ID的选择施加了额外的限制,那么您的某些用户将拥有与您环境中的其他应用程序不同的用户ID。注意:我假设这是一个内部应用程序(供员工使用),而不是面向Internet的应用程序。

具有不一致的用户名会增加许多特定风险:

  1. 这将使审计跟踪更难以遵循(严重的安全风险)。
  2. 如果您以后开始使用single sign on,可能会增加费用。
  3. 由于用户必须记住此应用程序使用了奇怪的用户名,因此会导致糟糕的用户体验。