账户管理、授权和密码管理可能对于许多开发者来说是一个没有得到足够关注的黑暗角落。以下内容是Google与平台总结的12条最佳实践。
1、对密码进行Hash
最重要的账户管理规则是安全地存储用户的敏感信息，如密码。在任何时候都不要存储明文的密码，并且存储的密码要是无法解密还原的。常用的方式是使用PBKDF2、Argon2、Scrypt或Bcrypt创建对密码进行hash。另外hash时还要进行 加盐 处理。千万不要使用已经被弃用的hash技术，如MD5、SHA1，在任何情况下都不应使用可逆加密或 尝试创建自己的散列算法 。
在设计系统时，需要问自己，假使数据库泄露了，泄露后是否会对用户使用的服务或者用户使用的其他网站的服务构成威胁，我们可以采取哪些措施来减少泄漏事件造成的损害？
2、如果可能，允许用户使用第三方登陆
第三方登陆服务可以使您可以依赖受信任的外部服务来验证用户的身份。Google，Facebook和Twitter是常用的提供商。您可以使用 Firebase Auth 等平台在现有内部身份验证系统旁边实施外部身份提供程序。Firebase Auth带来了许多好处，包括更简单的管理，更小的攻击面和多平台SDK。我们将在此列表中触及更多优势。查看我们的 案例研究 ，了解能够在短短一天内集成Firebase Auth的公司。
3、将用户身份和用户账户概念分隔开
您的用户不是电子邮件地址。他们不是电话号码。它们不是OAUTH响应提供的唯一ID。您的用户是他们在您的服务中独特，个性化数据和的体验。精心设计的用户管理系统在用户配置文件的不同部分之间具有低耦合和高内聚性。保持用户账户和凭证的概念分离将极大地简化实施第三方身份提供商的过程，允许用户更改其用户名并将多个身份链接到单个用户账户。实际上，为每个用户提供内部全局标识符并通过该ID链接其配置文件和身份验证标识可能比将其全部存储在单个记录中更优。
4、允许多个身份链接到单个用户账户
如果用户在一周前使用其 用户名和密码 进行了登陆，但在这次使用了 Google登陆 ，用户不会意识到可能会创建重复的账户。同样，用户可能有充分的理由将多个电子邮件地址链接到您的服务。如果您正确地分离了用户身份和身份验证，则将 多个身份链接 到单个用户将是一个简单的过程。
您的后端需要考虑用户是否有可能在注册过程中完成部分或全部，然后才意识到他们正在使用未链接到系统中现有账户的新第三方身份。这最简单地通过要求用户提供公共识别细节（例如电子邮件地址，电话或用户名）来实现。如果该数据与系统中的现有用户匹配，则要求他们也使用已知身份提供商进行身份验证，并将新ID链接到其现有账户。
5、不要阻止长密码或复杂密码
NIST最近更新了 密码复杂性和强度 指南。随着你使用Hash算法对密码进行存储，中间的很多很多可以迎刃而解，hash算法会产生固定长度的输出，因此不必去限制用户韩剧密码的长度，如果必须限制密码长度，则只能根据服务器允许的大POST大小来设置密码长度。这通常远高于1MB。
Hash出来的密码将由少量已知的ASCII字符组成（如果输出为二进制，则可以通过 Base64 进行转换）。考虑到这一点，您应该允许您的用户在密码中使用他们想要的任何字符。如果有人想要一个由 Klingon 、 Emoji 和两端都有空格的控制字符组成的密码，你应该没有技术理由否认它们。
6、不要对用户名强加不合理的规则
站点或服务要求用户名超过两个或三个字符，阻止隐藏字符并阻止用户名开头和结尾处的空格并不是不合理的。有些网站确实由这样的要求，例如最小长度为8个字符，或者阻止7位ASCII字母和数字之外的任何字符。对用户名进行严格限制的网站可能会为开发人员提供一些快捷方式，但这样做会以牺牲用户为代价，而极端情况会导致一些用户离开。
在某些情况下，只能做到分配用户名。如果您的服务属于这种情况，请确保指定的用户名是用户友好的，只要他们需要回忆和通信。字母数字ID应避免使用视觉上模糊的符号，例如“Il1O0”。另外建议您对任何随机生成的字符串执行字典扫描，以确保用户名中没有嵌入非预期的信息。这些相同的准则适用于自动生成的密码。
7、允许用户更改其用户名
在遗留系统或任何提供电子邮件账户的平台中，不允许用户更改其用户名，这种情况非常普遍。有 充分理由 不自动释放用户名以供重用，但系统的长期用户最终会提出使用其他用户名的充分理由，他们可能不想创建新账户。
您可以通过允许别名并让用户选择主别名来尊重用户更改用户名的愿望。您可以在此功能之上应用所需的任何业务规则。某些组织可能每年仅允许更改一个用户名，或阻止用户显示除主用户名之外的任何内容。电子邮件提供商可能会确保用户在从其账户中分离旧用户名之前充分了解风险，或者可能完全禁止取消旧用户名的链接。
为您的平台选择正确的规则，但要确保它们允许您的用户随着时间的推移成长和变化。
8、让用户可以删除他们的账号
用户由充分的理由永久关闭账户并删除所有个人数据，但是令人惊讶的是大量的服务并没有提供这样的自助服务。这里需要考虑安全性与合规性的平衡，但大多数受监管的环境都提供了有关数据保留的特定指南。避免合规性和黑客攻击问题的常见解决方案是让用户选择是否进行删除。在某些情况下， 法律上 可能会 要求您遵守 用户要求及时删除其数据的请求。
9、慎重的考虑会话长度
安全性和身份验证经常被忽视的一个方面是 会话长度 。Google花了很多精力 确保用户是他们本人， 并会根据某些事件或行为进行仔细检查。用户可以采取措施进一步 提高安全性 。对于非关键分析目的，您的服务可能有充分理由保持会话无限期打开，但应该有 阈值 ，之后您要求输入密码或其他用户验证。
考虑用户在重新进行身份验证之前应该能够处于非活动状态的时间。如果有人执行密码重置，请验证所有活动会话中的用户身份。如果用户更改其配置文件的核心方面或执行敏感操作时，则提示进行身份验证。考虑禁止从多个设备或位置登录同时是否有意义。
当您的服务确实使用户会话到期或需要重新身份验证时，请实时提示用户或提供一种机制来保留自上次身份验证以来未保存的任何活动。用户填写长表格，稍后提交并发现所有输入都已丢失并且必须再次登录，这是非常令人沮丧的。
10、使用两步验证
在选择 两步验证 （也称为双因素授权或仅2FA）方法时，请考虑用户对其账户被盗的实际影响。由于存在多个弱点， NIST 已 弃用 SMS 2FA（短信二次验证），但是，它可能是您的用户可以接受的最安全的选项。启用第三方身份提供商并在其2FA上搭载是一种简单的方法，可以在不花费大量精力的情况下提高安全性。
11、使用户ID不区分大小写
您的用户不在乎，甚至可能不记得用户名的确切情况。用户名应完全不区分大小写。将所有用户名和电子邮件地址全部以小写形式存储并将所有输入转换为小写进行比较之前是非常容易实现的。
越来越多的设备是智能手机，其中大多数手机提供纯文本字段的自动更正和自动大小写。在UI级别阻止此行为可能不是理想的或完全有效。
12、构建安全的身份验证系统
如果您使用的是Firebase Auth等服务，则会自动为您处理许多安全问题。但是，您的服务始终需要正确设计以防止滥用。核心考虑因素包括实施 密码重置 而不是密码检索，详细记录账户的活动，速率限制登录尝试，在多次不成功的登录尝试后锁定账户，以及对无法识别的设备或长时间闲置的账户要求两步身份验证。安全认证系统还有许多方面，因此请参阅以下部分以获取更多信息的链接。
进一步阅读
有许多优秀的资源可用于指导您完成开发，更新或迁移帐户和身份验证管理系统的过程。我推荐以下内容作为起点：
NIST 800-063B 涵盖身份验证和生命周期管理
OWASP不断更新的 密码存储备忘单
OWASP使用 身份验证备忘单 进一步详细 说明
Google的 Firebase身份验证 网站拥有丰富的指南，参考资料和示例代码库
热门专题
