用户账号、授权以及密码管理的12个最佳实践

帐户管理，授权和密码管理可能很棘手。 对于许多开发人员来说，帐户管理是一个遗忘的部分，没有得到足够的重视。 对于产品经理和客户而言，由此产生的体验往往达不到预期。

幸运的是，谷歌云平台（GCP）带来了一些工具，可以帮助您围绕用户帐户（这里指所有想要访问系统的人，不分客户账号或者内部账号）的创建，安全处理和身份验证做出正确的决策。 无论您是负责Google Kubernetes Engine中托管的网站、Apigee上的API、使用Firebase的应用程序， 还是其他经过身份验证的用户服务，本文都将列出最佳做法，以确保您拥有安全，可扩展，可用的帐户身份验证系统。

1. 用哈希算法加密密码
最重要的账户管理规则就是加密保存用户信息包括密码，并且将妥善保管。在任何情况不要保存明文密码。推荐使用强哈希算法这样可以避免人为篡改。例如PBKDF2, Argon2, Scrypt, or Bcrypt。不要使用已弃用的加密技术，如md5、sha1.在任何情况下都不应该使用可逆加密或尝试创建自己的散列算法。在设计系统时候应该考虑到系统收到损害的情况，时常问问自己，“如果我的数据库今天被渗透了，用户的安全性和安全性是否会对正用的其他服务造成危险？我们可以采取哪些措施来减少泄漏事件造成的损害？”

另一点：如果给你提供的密码无论你以何种方式出现或者在哪里出现，只要出现明文密码，那么实施一定会收到损害。

2. 如果可以，允许第三方身份验证提供商
第三方身份验证提供商使您可以依赖可信的外部服务来验证用户的身份。 Google，Facebook和Twitter是常用的提供商。

您可以使用Firebase Auth等平台在现有内部身份验证系统来实现外部身份。 Firebase Auth带来了许多好处，包括更简单的管理，更小的攻击范围和多平台SDK。

3. 分清用户验证和用户账号的概念

Separate the concept of user identity and user account

你的用户不是一个邮件地址，而不是一个电话号码。它们不是OAUTH响应提供的唯一ID。 您的用户是在您的服务中集成唯一个人信息数据和用户体验的集合。 精心设计的用户管理系统在用户信息的各个方面之间具有低耦合和高内聚性的特点。

保持用户帐户和凭证的概念分离将极大地简化实施第三方身份提供商的过程，允许用户更改其用户名并将多个身份关联到单个用户帐户。 实际上，为每个用户提供一个内部全局标识符并通过该ID连接其他信息和身份验证标识可能会有所帮助，而不是将其全部存储在单个记录中。

4. 允许多个身份认证关联到单个用户账户

如果用户在一周内使用其用户名和密码对您的服务进行身份验证，则可能会在下一次选择Google登录而不了解这可能会创建重复的帐户。 同样，用户可能有充分的理由将多个电子邮件地址链接到您的服务。 如果您正确地分离了用户身份和身份验证，则将多个身份链接到单个用户将是一个简单的过程。

您的后端需要考虑用户是否有可能在他们意识到他们正在使用未链接到系统中现有帐户的新第三方身份之前完成整个注册过程。 这最简单地通过要求用户提供公共识别细节（例如电子邮件地址，电话或用户名）来实现。 如果该数据与系统中的现有用户匹配，则要求他们也使用已知身份提供商进行身份验证，并将新ID链接到其现有帐户。

5. 不要阻止长或复杂的密码

NIST最近更新了密码复杂性和强度指南。

由于您已使用复杂的密码进行密码存储，那么您可以解决许多问题。 无论输入长度如何，加密都会产生固定长度的输出，因此您的用户应该能够使用密码。 如果必须限制密码长度，则只能根据服务器允许的最大POST大小来设置密码长度。 这通常远高于1MB。这点要注意。
您的密码将子可以由少量已知的ASCII字符组成。 如果没有，您可以轻松地将二进制哈希转换为Base64。 考虑到这一点，您应该允许您的用户在密码中使用他们想要的任何字符。 如果有人想要一个由Klingon，表情和两端都有空格的控制字符组成的密码，你应该允许他们设置。

6. 不要对用户名强加不合理的规则

一般网站或服务要求用户名超过2~3字符，阻止隐藏字符以及用户名开头和结尾处的空格是合理的。但是，有些网站会额外增加一些要求，例如最小长度为8个字符，或者阻止7位ASCII字母和数字之外的任何字符。
对用户名进行严格限制的网站可能会为开发人员提供一些快捷方式，但这样做会以牺牲用户为代价，而极端情况则会驱使一些用户离开。

在某些情况下，最好的方法是分配用户名。如果您的服务属于这种情况，请确保指定的用户名是用户友好的，只要他们需要回忆和通信。字母数字ID应避免使用视觉上模糊的符号，例如“Il1O0”。还建议您对任何随机生成的字符串执行字典扫描，以确保用户名中没有嵌入非预期的消息。这些相同的准则适用于自动生成的密码。

7. 允许用户更改其用户名

   在遗留系统或任何提供电子邮件帐户的平台中，不允许用户更改其用户名这种情况非常普遍。 他们有充分理由 不自动释放长时间未用的用户名以供重用，但系统的长期用户最终会提出使用其他用户名的充分理由，他们可能不想创建新帐户。
您可以通过允许别名并让用户选择主别名来尊重用户更改用户名的愿望。 您可以在此功能之上应用所需的任何业务规则。 有些组织可能每年只允许更改一次用户名，或者阻止用户显示除主用户名之外的任何内容。 电子邮件提供商可能会确保用户在从其帐户中分离旧用户名之前充分了解风险，或者可能完全禁止取消旧用户名的链接。 

8. 让您的用户删除他们的帐户

    发现有大量服务没有自助维护手段，不允许用户删除他们的帐户和相关数据。 用户永久关闭帐户并删除所有个人数据有很多充分的理由。 这些问题需要与您的安全性和合规性需求相平衡，但大多数受监管的环境都提供了有关数据保留的特定指南。 避免合规性和黑客攻击问题的常见解决方案是让用户安排其帐户以便将来自动删除。
在某些情况下，您可能在法律上要求您遵守用户要求及时删除其数据的请求。 如果数据泄露，“关闭”帐户的数据泄露，您也会大大增加您的曝光率。

9.对会话长度做出有意识的决定
安全性和身份验证经常被忽视的一个方面是会话长度。 Google花了很多精力确保用户是他们所说的人，并会根据某些事件或行为进行仔细检查。用户可以采取措施进一步提高安全性。
对于非关键分析目的，您的服务可能有充分理由保持会话无限期打开，但应该有阈值，之后您会要求输入密码，第二因素或其他用户验证。

考虑用户在重新进行身份验证之前应该能够处于非活动状态的时间。如果有人执行密码重置，请验证所有活动会话中的用户身份。如果用户更改其配置文件的核心方面或执行敏感操作时，则提示进行身份验证或第二因素。考虑一次禁止从多个设备或位置登录是否有意义。

当您的服务确实使用户会话到期或需要重新身份验证时，请实时提示用户或提供一种机制来保留自上次身份验证以来未保存的任何活动。用户填写一个长表格，在一段时间之后提交它并发现他们的所有输入都已丢失并且他们必须再次登录是非常令人沮丧的。

10.使用两步验证
在选择两步验证（也称为双因素授权或仅2FA）方法时，请考虑用户对其帐户被盗的实际影响。由于存在多个弱点，NIST已弃用SMS 2FA auth，但是，它可能是您的用户将接受的最安全的选项，因为他们认为这是一项琐碎的服务。您可以合理地提供最安全的2FA身份验证。启用第三方身份提供商并在其2FA上搭载是一种简单的方法，可以在不花费大量精力的情况下提高安全性。
11.使用户ID不区分大小写
您的用户不在乎，甚至可能不记得用户名的确切情况。用户名应完全不区分大小写。将所有用户名和电子邮件地址全部以小写形式存储并将所有输入转换为小写比较之前，这是微不足道的。
智能手机代表了越来越多的用户设备。其中大多数提供纯文本字段的自动更正和自动大写。在UI级别阻止此行为可能不合适或完全有效，并且您的服务应足够强大，以处理无意中自动大写的电子邮件地址或用户名。

12.构建安全的身份验证系统
如果您使用的是Firebase Auth等服务，则会自动为您处理许多安全问题。但是，您的服务始终需要正确设计以防止滥用。核心考虑因素包括实施密码重置而不是密码检索，详细的帐户活动记录，速率限制登录尝试，在太多不成功的登录尝试后锁定帐户，以及对无法识别的设备或长时间闲置的帐户要求双因素身份验证。安全认证系统还有许多方面，因此请参阅以下部分以获取更多信息的链接。