匿名用户名是必要的吗?

我们的安全pipe理员坚持认为我们应该使用匿名用户名

例如,对于名为John Doe的用户,他的用户名将是“ g74h19 ”而不是“ jdoe ”。

我们已经有一个策略,在三次无效login尝试后locking一个帐户。 因此,除了可能使DOS攻击更难,我不能看到这将如何帮助安全 – 更糟的是,你将不再能够看到日志中的谁是谁。

有没有支持匿名用户名的安全build议? (链接)

这里有人在用吗?

我将从Windows域的angular度来看待这个问题。 如果我是攻击者, 我不在乎用户名是什么。 我只是想要他们。 所以我打算寻找一个没有RestrictAnonymous或Windows 2000系统的系统,我将扫描域中的所有用户名。 或者,我将在域上获得一个有效的用户帐户,然后发出所述扫描。 现在我有所有的用户帐户来反对。

哦,我也可以扫描组。 所以我会寻找像域pipe理员或企业pipe理员或看起来特别有趣的组非常好的。 我会看看谁是这个小组的成员,然后看看他们。

所以,虽然匿名用户名似乎有帮助,但我不认为他们真的提高安全性很多。 最终用户,支持人员和pipe理员在对特定用户问题进行故障排除时,会使其更加困难。

匿名用户名是另一个默默无闻的安全例子。 通过匿名用户名,使得攻击者难以猜测,比如说一个电子邮件地址。 例如,Exchange经常使用用户名作为电子邮件地址的一部分。

正如你所说,你有一个有效的locking政策,那么你已经有一些安全的方法,所以匿名化将使它更可能达到暴力攻击的极限。 你应该考虑的一件事是,如果用户无意中放弃了密码呢? 在没有匿名用户名的情况下,攻击者拥有密码,很可能能够在3次尝试中从他们的电子邮件中猜出用户名。 如果用户名是匿名的,这个可能性就小得多。

所以有一些好处,但这取决于这种有限的好处是否超过了简单的用户名的便利。 贵组织有多less安全性?

安全性和可用性必须不断相互平衡。 这可以提高安全性,防止暴力或用户名猜测攻击,但是对用户来说,生活会变得更加困难。 用户现在必须记住2条(给他们)随机信息才能login并执行其工作职能。 这对于业务来说是一个风险,因为用户更可能写下他们的用户名(如果他们写下来,这是写下密码的一个非常短的飞跃),或忘记他们的用户名导致生产力损失。

我不认为这是值得随机化用户名。 这些在屏幕上以明文forms显示,所以无论如何都很容易受到肩膀冲浪的影响。 也会给用户造成不必要的伤害。 最重要的是,他们鼓励用户练习不良的安全习惯。

他们也可以用来掩盖员工之间的数据。 写薪水报告的人们并不确切地看到谁在做什么。 其他情况下,如果pipe理层正在select裁员和员工performance数据,用匿名用户名表示不能被指责挑选。 像这样的随机事物。

对于大部分组织来说,使用部分名字和姓氏会导致很多重叠,这会造成更大的差异。

编辑:模糊的用户名也使得有点难以弄清楚你想打扰哪些用户帐户试图破解。 通过一个标准的计划,每个人都会知道CEO / CIO / CFO / Director的用户名。 要弄清楚他们是哪个员工号码就困难得多了。

为.EDU工作已经出现,但不是出于安全原因。 像许多人一样,我们在注册时以真实姓名为基础,使用我们的用户名(由于用户环境中旧的Solaris服务器的存在,仍然停留在8个字符的限制内)。 由于我们在任何时候都有19,000到23,000名在职学生,这是通过algorithm完成的,所以猜测给定用户的用户名和他们的真实姓名并不难。 根据您阅读法规(FERPA)的方式,这可以视为他们有权退出的“目录服务”。

这就是问题。 如果名字相当独特的用户注册,例如Farheed Zakaria,账户生成过程将为其分配一个用户名。 在这种情况下,这将是“zakarif”。 很容易猜到。 如果你认为这是一个目录,他们select退出,那么我们将不得不改变用户名。 更改用户名是一个棘手的过程,并不是自动的。 当学生结婚并更改姓氏时,我们不会更改他们的用户名。 我们的工作人员在90年代初结婚,仍然有用户名,包括他们的旧姓。

那么,去思考,如果在创build账号时我们指派用户不容易派生名字? 在我gradle的大学,上面的名字是“zaka0008”; 姓氏的前四个字母和唯一性的数字。 从给定名称中派生出来并不容易,但仍然包含一些标识符以帮助用户记住它。 这将允许我们避免做帐户重命名。

我们还没有这样做,因为我们还没有确定FERPA适用于这种情况。 但是,这是一个真正的例子,不太明显的用户名。

从技术上讲,用户名是密码的一半,所以使用易于猜测的用户名与使用易于猜测的密码相同。