[译]用户帐户、受权和密码管理的 12 个最佳实践

• 原文地址：12 best practices for user account, authorization and password management
• 原文做者：Google Cloud Platform
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：Wangalan30
• 校对者：ryouaki, Potpot

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

帐户管理、受权和密码管理问题能够变得很棘手。对于不少开发者来讲，帐户管理还是一个盲区,并无获得足够的重视。而对于产品管理者和客户来讲，由此产生的体验每每达不到预期的效果。

幸运的是，Google Cloud Platform (GCP) 上有几个工具，能够帮助你在围绕用户帐户（在这里指那些在你的系统中认证的客户和内部用户）进行的创新、安全处理和受权方面作出好的决定。不管你是在 Google Kubernetes Engine 上负责网站托管，仍是 Apigee 上的一个 API，亦或是 一个应用Firebase 或其余拥有通过身份认证用户服务的 APP，这篇文章都会为你展现出最佳实践，来确保你拥有一个安全、可扩展、可以使用的帐户认证系统。

对密码进行散列处理

帐户管理最重要的准则是安全地存储敏感的用户信息，包括他们的密码。你必须神圣地对待并恰当地处理这些数据。

不要在任何状况下存储明文密码。相反，你的服务应该存储通过散列处理以后的、不可逆转的密码 —— 好比，能够用 PBKDF二、SHA三、Scrypt 或 Bcrypt 等这些散列算法。同时，散列时还要进行 加盐 处理，同时，盐值也不能和登录用的验证信息相同。不要用已经弃用的哈希技术好比 MDS 和 SHA1，而且，任何状况下都不要使用可逆加密方式或者 试着发明本身的哈希算法。

在设计系统时，应该假设你的系统会受到攻击，并以此为前提设计系统。设计系统时要考虑“若是个人数据库今天受损，用户在我或者其余服务上的安全和保障会有危险吗？咱们怎样作才能减少事件中的潜在损失。”

另一点：若是你可以根据用户提供的密码生成明文密码，那么你的系统就是有问题的。

若是能够的话，容许第三方提供身份验证

使用第三方提供身份验证，你就能够依赖一个可靠的外部服务来对用户的身份进行验证。Google、Facebook 和 Twitter 都是经常使用的身份验证提供者。

你可使用 Firebase Auth 这样的平台在已有的身份验证体系的基础上再添加额外的身份验证方式。使用 Firebase Auth 有许多好处，好比更简单的管理、更小的受攻击面和一个多平台的 SDK。经过这个清单咱们能够接触更多的益处。查看咱们专为企业设计的的 案例，可让你在一日以内集成 Firebase Auth。

区分用户身份和用户帐户的概念

你的用户并非一个邮件地址，也不是一个电话号码，更不是由一个 OAUTH 回复提供的特有 ID。他们是你的服务中，全部与之相关的独特、个性化的数据和经验呈现的最终结果。一个设计优良的用户管理系统在不一样用户的我的简介之间低耦合且高内聚。

在概念上将用户帐户和证书区分开能够极大地简化使用第三方身份验证的过程，容许用户修改本身的用户名，并关联多个身份到单一用户帐户上。在实用阶段，这样可使咱们对每一个用户都有一个内部的全局标识符，并经过这个 ID 将他们的我的简介与身份验证相关联，而不是将它所有堆放在一条记录里。

容许单一用户帐户关联多重身份

一个每星期用 用户名和密码 在你的服务上认证的用户，每每会选择下次登陆使用 Google 登陆，可是他们可能没意识到这样会建立重复的帐户。一样的，一个用户可能将多个邮件地址链接到你的服务上。若是你可以正确地将用户的身份和认证区分开，那么 关联多个身份 到一个单一用户上将是一件十分简单的事情。

你的系统须要考虑这样一种状况：当用户已经进行了一部分或者已经完成了整个注册过程以后，他们才意识到，他们正在使用一个与他们已有的帐户彻底无关的新的第三方身份。要解决这个问题能够简单地要求客户提供一份普通的身份细节，好比邮件地址、电话或用户名等。若是这份数据与系统中已有的用户相匹配，则须要他们使用已知的身份认证，并将新的 ID 关联到他们已有的帐户上。

不要限制较长或者复杂的密码

NIST 最近在 密码的复杂度和强度 上更新了指南。既然你正在（或者很快就要）使用一个强加密的哈希值来进行密码存储，那么大部分的问题已经解决了。不管输入内容的长短，哈希值总会生成一个固定长度的输出值，因此你的用户应该根据本身喜爱的长度设置本身的用户密码。若是你必须限制密码的长度，请按照你的服务器所容许的 POST 的最大值来设置。实际来讲。这一般超过1M。

你的哈希密码将包含一小部分已知的 ASCII 码。若是不是，你能够轻易地将一个二进制的哈希值转成 Base64。考虑到这一点，你应该容许你的用户在设置密码时自由地使用任何他们想要的字符。若是有人想要一个由 Klingon、Emoji 以及两端带有空格的控制字符组成的密码，你不能因任何技术实现上的理由而拒绝他们。

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

若是一个网站或服务要求用户名长度必须大于两个或三个字 符、限制隐藏字符或不容许用户名的两端带有空格，这都不属于不合理的范畴。然而，有些网站的要求未免有些极端，好比，最小长度为八个字符或不容许使用任何大于 7bit 的 ASCII 字母和数字。

一个对用户名要求严格的站点会给开发者提供一些捷径，但这倒是以用户的损失为代价的，同时，一些极端的状况也会带走必定数量的用户。

有些状况须要咱们分配用户名。若是你的服务属于这些状况，要确保用户名可以使用户在回想或交流时感受到足够友好。由字母和数字组成的 ID 应该尽可能避免会在视觉上会产生歧义的符号，好比“Il1O0”。同时，咱们建议你对全部随机生成的字符串进行字典扫描，以确保没有嵌入用户名中的意外信息。这些相同的准则适用于自动生成的密码。

容许用户修改用户名

使人广泛感到惊讶的是，原有系统或是其余提供邮箱帐户的平台都不容许用户修改他们的用户名。咱们有不少 正当理由 不容许重用已经自动回收的用户名，可是若是你的长期用户忽然想要换个新的用户名，最好能不用另外新建一个帐户。

你能够容许使用别名，并让你的用户选择一个首要的别名，以此来知足他们想要修改本身用户名的要求。你能够在此功能之上应用任何你须要的商务规则。有些系统可能会容许用户一年修改一次用户名或者只显示用户的别名。电子邮件服务提供商应该能够确保用户在将旧用户名与他们的帐户分离开，或是彻底禁止断开旧用户名以前，已经充分的了解了其中的风险。

为你的平台选择正确的规则，可是要确保他们容许你的用户随着时间增加和变化。

让你的用户删掉他们的帐户

没有提供自助服务的服务系统数量惊人，这对一个用户来讲就意味着删掉他们的帐户和相关数据。对一个用户来讲，永久地关掉一个帐户并删掉全部的我的数据有不少的好理由。这些需求点须要与你的安全性和顺从性需求相平衡，但大多数受监管的环境都会提供有关数据存储的相关指导。为避免顺从性以及黑客的关注，一个较广泛的作法是让用户安排他们的帐户，以便将来自动删除。

在某些状况下，你可能会 被合法地要求遵守 用户的需求及时的删掉他们的数据。一样，当“已关闭”帐户的数据泄漏时，你也会极大的增长你的曝光率。

在对话长度上作出理智的选择

安全和认证中一个常常被忽视的方面是 会话长度。Google 在 确保用户是他们所说的人 方面作了不少努力，并将基于某些事件或行为进行二次确认。用户能够采起措施 进一步提升本身的安全度。

你的服务可能有充分的理由为非关键的分析目的保持一段会话无限期开放，可是这应该有 门槛，要求输入密码，第二因素或其余用户验证。

考虑一个用户在从新认证以前须要保持多长时间的非活跃状态。若是某人想要执行密码重置，须要在全部活跃会话中验证用户身份。若是一个用户想要更改他们我的信息的核心内容，或者当他们在执行一次敏感的行为时，提示进行身份验证或第二因素。要考虑不容许同时在不一样设备或地址登陆是否有意义。

当你的服务终止用户会话或须要再次验证时，实时提示用户或提供一种机制来保存自他们上次验证后还没来得及保存的所有活动。对用户来讲，当他们填好一份很长的表格并在以后提交，却发现他们输入的全部信息所有丢失且他们必须再次登陆，这是十分使人沮丧的。

使用两步身份验证

要考虑当用户选择 两步验证 (也称两因素验证或只是 2FA)方法而帐户被盗后的实际影响。因为有许多缺陷，SMS 2FA 认证 被 NIST 反对，然而，它或许是你的用户考虑到这是一项微不足道的服务时会接受的最安全的选择了。请尽量提供你能提供的最安全的 2FA 认证。支持第三方身份验证和在他们的 2FA 上面打包是个十分简单的方法，使你可以不花费太多力气就能提升你的安全度。

用户 ID 不区分大小写

你的用户不会关心或者甚至可能并不记得他们确切的用户名。用户名应该彻底不区分大小写。与输入时将全部字符转换为小写相比，存储时将用户名和邮件地址所有保存为小写显得十分微不足道。

智能手机的使用表明用户设备所占的比重不断增长。他们大多数提供纯文本字段的自动更正和首字母自动大写功能。

创建一个安全认证系统

若是你在使用一个像 Firebase Auth 同样的设备，大量的安全隐患都会自动帮你处理。然而，你的设备老是须要正确地设计以防滥用。核心的问题包括实现 密码重置而不是密码检索，详细帐户活动日志，限制登陆尝试率，屡次登陆尝试不成功后锁定帐户以及需双因素识别已长时间限制的未知设备或帐户。安全认证系统还有不少方面，因此请查看下方的连接获取更多信息。

进一步阅读

还有不少优秀的可用资源能够指导你的开发进程,更新或迁移你的帐户和认证管理系统。我建议如下为出发点:

• NIST 800-063B 包含认证和生命周期管理
• OWASP 持续更新密码存储备忘单
• OWASP 使用认证备忘单进行深刻研究
• Google 的 Firebase 认证网站有丰富的指南库,参考资料和示例代码

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。