用户帐户，授权和密码管理的12个最佳实践

4. 允许多个身份关联到单个用户账号
一开始使用 用户名和密码 认证登录到服务的用户，后面可能会使用 Google Sign-In 来登录。他们并不知道这会创建多余的账号。类似地，由于某些原因，服务中的一个用户可能会关联到多个电子邮箱。如果能正确的分离用户身份和认证信息，将 多个身份链接 到同一个用户就会变得简单。
你的后台需要考虑到用户可能会通过一部分甚至所有途径来通过注册过程，但他们并没有意识到在新的第三方身份没有关联到他们已经存在于系统中的账号。最简单的实现是要求用户提供一个共同的细节用于识别，比如电子邮件地址，电话或用户名等。如果该数据与匹配到系统中现有的用户，则要求他们认证已知身份并将新的 ID 关联到已存在的账号上。
5. 不要拒绝长密码或者复杂的密码
NIST 最近更新了关于 密码复杂度和强度 的准则。如果你正在(或马上会)使用高强度的散列算法来保存密码，很多问题就会迎刃而解。不管输入的内容有多长，散列算法都会生成固定长度的输出，所以用户可以使用他们喜欢的长密码。如果你必须限制密码长度，应该仅从服务支持的最大 POST 大小来考虑限制。严格地说，这通常大于 1M。
散列后的密码由大家都知道的一小部分 ASCII 字符组成。就算不是，也很容易通过 Base64 把二进制数据转换过来。考虑到这一点，你应该允许用户在密码中随意使用字符。如果有人想在密码中使用克林贡语、表情字符和控制字符并在两端加入空白字符，你应该没有技术方面的理由来拒绝他们。
6. 不要为用户名强加不合理的规则
有些网站或服务要求用户名的字符数不低于两三个字符，不允许不可见字符，前后不能有空格，这些都毫无道理。然而，有些网站会要求最小长度为 8 个字符，只允许使用 7 位(bit) 的 ASCII 字母和数字。
在网站上严格限制用户名，可能会为开发者带来方便，但在某些极端情况下对用户的要求会让某些用户望而却步。
某些情况下最好的办法是指定用户名。如果你的服务中遇到这种情况，需要确保指定的用户名对用户来说很容易想起来也很容易告诉别人。字母数字组合的 ID 应该避免视觉上不易识别的符号，比如“Il1O0”。同时还建议对随机生成的字符串进行字典扫描，确保用户名中没有意外嵌入一些信息。这一原则同样适用于自动生成的密码。
7. 允许用户更改他们的用户名
在遗留系统或任何提供电子邮件帐户的平台中，不允许用户更改其用户名是非常常见的。这里有很多 好的理由 支持不自动释放用户名以供重复使用，但系统的长期用户最终会给出一个很好的理由来使用不同的用户名，并且他们可能不想创建新的帐户。
你可以通过允许别名并让你的用户选择主别名来满足用户期望更改其用户名的愿望。你可以在此功能之上应用所需的任何业务规则。某些组织可能每年仅允许更改一次用户名，或将阻止用户显示除主用户名以外的任何内容。电邮供应商可能会确保用户在将老用户名从其帐户中分离出来之前充分得了解了相关风险，或者可能完全禁止将老用户名断开链接。
为你的平台选择合适的规则，但要确保它们允许你的用户随着时间的推移而成长和改变。
8. 允许你的用户删除自己的账号
相当数量的服务没有用于用户删除其账户及相关数据的自助服务手段。用户永久关闭帐户并删除所有个人数据有很多好的理由。这些问题需要根据你的安全行和合规需求进行平衡，但大多数受监管的环境提供了有关数据保留的具体指导。避免合规和黑客攻击的常见解决方案是让用户自己规划其帐户以备将来自动删除。
在某些情况下，你可能需要 遵照 用户的要求，及时删除其数据。如果发生数据泄露，对于发生“已关闭”帐户的数据泄露情况，你还可以大大提高你的曝光率。
9. 在会话长度上有意识地做决定
在安全验证上常常被忽略的是 会话长度 。Google 作出了一些努力来 确保用户的行为 并进行双重检查，这主要基于某些事件和行为。用户可以有步骤地 进一步加强他们的安全性 。
你的服务可以有明确的理由来保持会话，而不是非关键分析目的无限期开放，但是，应该有一个 门槛 来要求您输入密码、或第二个因素或其他用户验证。
考虑多久的时间用户应该认证，并明确之前是不活跃的。如果有人进行密码重置，就需要验证所有活动会话的用户身份。如果一个用户更改核心方面的配置文件或当他们执行敏感的行动，应该提示身份验证或第二因素。并考虑不允许从多个设备或位置登录是否有意义。
当你的服务用户会话到期或需要重复认证，提示用户实时或提供一种机制来保护任何活动来保存未保存的最后验证。用户填写表单，提交它一段时间后，发现他们所有的输入已经丢失，他们必须再次登录，这是非常令人沮丧的。