我在网上和这个网站上都看了一遍，试图找到更多关于这个安全性的信息，但没有找到任何东西。在我的特定情况下，该产品是一个网站，但我认为这个问题适用于任何拥有大量用户的软件。
我知道有许多网站允许您更改用户名，但同时也有许多不允许更改。我敢肯定，有些不允许这样做可能只是为了简单，但也可能是为了安全。
我的问题就像标题一样：
从安全的角度来看，您认为允许个人更改用户名是好还是坏？
我目前想不出任何不允许它的理由，因为它做得正确（即不可能重复用户名，需要输入当前密码以确保仍然满足不包含用户名的密码要求等），但我可以'忍不住想我缺少一些东西。
我知道从用户的角度来看，允许他们更改用户名是有好处的。例如，如果他们将用户名设置为他们的电子邮件地址并决定稍后使用不同的电子邮件地址。相反，如果您允许他们更改用户名，我很好奇有关应用程序和登录过程安全性的好处与风险。
编辑：
一些答案就公开显示的名称提出了很好的观点，但要澄清的是，问题不在于任何公开显示名称，而是用于登录的唯一用户名。
许多人已经从安全和社区的角度研究了不允许更改名称的原因。但是，允许更改用户名有很多正当理由，即使用户名与显示名称是分开的，例如：
即使它只是一个用户名，必须使用带有创伤的旧名称也会加剧创伤。此外，跟踪者/骚扰者很有可能知道他们目标的登录凭据，并且能够更改凭据的两个部分降低了攻击面；此外，监控登录废弃用户名的尝试允许建立针对不良代理的法律案例。
即使在私人用户名的情况下，被迫使用自己的“死名”也是非常痛苦的。（我可以谈谈这方面的个人经验。）
这对内部用户名的影响较小，但在我看来，最好还是出于善意。
这些对于用户的舒适度都很重要，而且在许多情况下，人们可能只是用新名称创建一个新帐户，所以不妨支持它。
避免社会工程当然很重要，但有一些方法可以帮助减轻这种情况，例如各种形式的验证（如在几个社交网络上看到的那样）、公钥密码学和配置文件指标（“N 个月前最后一次更改名称；名称已更改K 次”）。而且，由于此问题已被编辑为与内部用户名而非公共显示名有关，因此这些担忧甚至与讨论无关。
此外，请记住，更改用户名提供的许多攻击面也存在于仅创建新帐户的人，如果用户名更改选项不可用，则用户可能会创建一个新帐户 - 可能使用相同的密码作为旧的，否则会做可能导致安全性受损的事情。
维护用户名更改的审计跟踪并禁止创建使用以前使用的用户名的新帐户是一个好主意（至少如果用户名最后一次使用是在过去，比如说，一年），但没有理由首先，用户名应该是用于将数据与用户帐户相关联的主键，因为更改用户名是有合法目的的，并且所有帐户记录都应该首先规范化为一个抽象的内部唯一 ID。
我会说，只要他们无法更改其唯一标识符。即，他们可以更改他们显示的名称，但该名称与不变的用户 ID 号相关联（这也会使您的 DBA 更快乐）。我还要确保用户不能将他们的名字更改为另一个用户的旧名字（以帮助减轻潜在的安德斯正在谈论的骗局）。因此，您将考虑存储用户在某一时刻经过的所有名称。
请求更改用户名，处理合法案例（如电子邮件案例）可能会更好，并且没有用户可自动化的方法来做这件事。
我们目前使用您对联系我们请求更改的个人的建议，但由于手动工作，它的可扩展性不高，并且要求我们询问他们的安全问题的答案以进行验证。
那肯定是错的。不仅您必须手动执行此操作，而且您还必须向处理此类请求的每个人提供安全答案响应。
如果你想保持控制，那就半自动化吧：让用户做所有的准备工作，即填写新名称，写下他们的理由（如果你关心的话）并回答安全问题。现在，服务台人员只需要批准或拒绝请求。
其他答案中已经给出了许多支持和反对允许用户名更改的原因。请注意，您可能会走中间路线：允许一次自动更改，例如，每年一次。这足以处理 99% 的请求，但又足够限制以防止大多数滥用行为。
如前所述，允许用户轻松更改用户名（我们称其为“显示名称”以消除歧义）使用户更容易躲避骚扰或欺骗其他用户的后果。如果您的网站具有社交功能，不妨考虑是否禁止、阻止、报告、聊天历史记录等通过用户名切换进行（即，即使名称已更改，用户是否会意识到他们正在与同一个帐户交谈？ ）。
要考虑的另一点是匿名或隐私问题。经常有人用他们的真实姓名创建一个帐户，然后出于某种原因后悔将他们的真实身份附加到该帐户上。有时这是因为他们被欺负了，但通常是出于正当的原因，比如过度分享他们生活的个人细节，或者他们成为欺凌的受害者。这个最近的问题作为一个不同的例子浮现在脑海中：
在这种情况下，提交服务票据以供人工审核或允许有限数量的帐户名称更改听起来是合理的方法。