首页 用户账号、登录、密码管理的12个最佳实践
文章
取消

用户账号、登录、密码管理的12个最佳实践

用户账号、登录、密码管理的 12 个最佳实践


要区分开 Account(登录用的用户名、密码)与 Profile(identity,用户个人资料,如真名、头像、地址等),这样才能支持同一 account 登录、自由切换多个 profile。

Netflix:一个 Account,多个 Profile 切换(爸爸、妈妈、小孩,不同的 profile);Google:多个 Account 切换,但一个 Account 一个 Profile;YouTube:多个 Account 切换,同一 Account 支持多个 Profile。看起来很容易,但实现起来是很麻烦的。

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

幸运的是,Google云平台 (GCP)带来了一些工具,可以帮助您围绕用户帐户的创建,安全处理和身份验证做出正确的决策(在这种情况下,任何向系统标识自己的人 - 客户或内部用户)。无论您是负责托管的网站谷歌Kubernetes引擎,在API Apigee,使用应用程式的火力地堡 或其他服务与身份验证的用户,此信息将制定出最佳做法,以确保你有一个安全,可扩展,可使用账户认证系统。

1. 哈希那些密码

我最重要的帐户管理规则是安全地存储敏感用户信息,包括密码。您必须将此数据视为神圣数据并妥善处理。

在任何情况下都不要存储明文密码。您的服务应该存储密码的加密密码,该密码无法反转 - 例如,使用PBKDF2,Argon2,Scrypt或Bcrypt创建。散列应该使用该特定登录凭据唯一的值进行加盐。不要使用弃用的散列技术,如MD5,SHA1,在任何情况下都不应使用可逆加密或尝试创建自己的散列算法。

你应该设计你的系统,假设它最终会受到损害。问问自己“如果我的数据库今天被淘汰了,我的用户的安全性和安全性是否会对我们的服务或他们使用的其他服务造成危险?我们可以采取哪些措施来减少泄漏事件造成的损害?”

另一点:如果您可以在提供给您之后的任何时间以外的任何时间以明文形式生成用户密码,那么您的实施就会出现问题。

2. 如果可能,允许第三方身份提供商

第三方身份提供程序使您可以依赖受信任的外部服务来验证用户的身份。Google,Facebook和Twitter是常用的提供商。

您可以使用Firebase Auth等平台在现有内部身份验证系统旁边实施外部身份提供程序。Firebase Auth带来了许多好处,包括更简单的管理,更小的攻击面和多平台SDK。我们将在此列表中触及更多优势。查看我们的案例研究,了解能够在短短一天内集成Firebase Auth的公司。

3. 分离用户身份和用户帐户的概念

您的用户不是电子邮件地址。他们不是电话号码。它们不是OAUTH响应提供的唯一ID。您的用户是他们在您的服务中独特,个性化数据和体验的高潮。精心设计的用户管理系统在用户配置文件的不同部分之间具有低耦合和高内聚性。

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

4. 允许多个身份链接到单个用户帐户

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

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

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

NIST最近更新了密码复杂性和强度指南。由于您(或将很快)使用强大的加密哈希进行密码存储,因此您可以解决许多问题。无论输入长度如何,哈希都会产生固定长度的输出,因此您的用户应该能够使用密码。如果必须限制密码长度,则只能根据服务器允许的最大POST大小来设置密码长度。这通常远高于1MB。认真。

您的散列密码将由少量已知的ASCII字符组成。如果没有,您可以轻松地将二进制哈希转换为Base64。考虑到这一点,您应该允许您的用户在密码中使用他们想要的任何字符。如果有人想要一个由Klingon,Emoji 和两端都有空格的控制字符组成的密码,你应该没有技术理由否认它们。

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

站点或服务要求用户名超过两个或三个字符,阻止隐藏字符并阻止用户名开头和结尾处的空格并不是不合理的。但是,有些网站会满足要求,例如最小长度为8个字符,或者阻止7位ASCII字母和数字之外的任何字符。

对用户名进行严格限制的网站可能会为开发人员提供一些快捷方式,但这样做会以牺牲用户为代价,而极端情况会导致一些用户离开。

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

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

在遗留系统或任何提供电子邮件帐户的平台中,不允许用户更改其用户名,这种情况非常普遍。有充分理由不自动释放用户名以供重用,但系统的长期用户最终会提出使用其他用户名的充分理由,他们可能不想创建新帐户。

您可以通过允许别名并让用户选择主别名来尊重用户更改用户名的愿望。您可以在此功能之上应用所需的任何业务规则。某些组织可能每年仅允许更改一个用户名,或阻止用户显示除主用户名之外的任何内容。电子邮件提供商可能会确保用户在从其帐户中分离旧用户名之前充分了解风险,或者可能完全禁止取消旧用户名的链接。

为您的平台选择正确的规则,但要确保它们允许您的用户随着时间的推移而增长和变化。

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

令人惊讶的服务数量没有自助服务手段,用户可以删除他们的帐户和相关数据。用户永久关闭帐户并删除所有个人数据有很多充分的理由。这些问题需要与您的安全性和合规性需求相平衡,但大多数受监管的环境都提供了有关数据保留的特定指南。避免合规性和黑客攻击问题的常见解决方案是让用户安排其帐户以便将来自动删除。

在某些情况下,法律上可能会要求您遵守用户要求及时删除其数据的请求。如果数据泄露,“封闭”帐户的数据泄露,您也会大大增加您的曝光率。

9. 对会话长度做出有意识的决定

安全性和身份验证经常被忽视的一个方面是会话长度。Google花了很多精力确保用户是他们所说的人,并会根据某些事件或行为进行仔细检查。用户可以采取措施进一步提高安全性。

对于非关键分析目的,您的服务可能有充分理由保持会话无限期打开,但应该有阈值,之后您会要求输入密码,第二因素或其他用户验证。

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

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

10. 使用两步验证

在选择两步验证(也称为双因素授权或仅2FA)方法时,请考虑用户对其帐户被盗的实际影响。由于存在多个弱点,NIST已弃用 SMS 2FA auth ,但是,它可能是您的用户可以接受的最安全的选项,因为他们认为这是一项琐碎的服务。您可以合理地提供最安全的2FA身份验证。启用第三方身份提供商并在其2FA上搭载是一种简单的方法,可以在不花费大量精力的情况下提高安全性。

11. 使用户ID不区分大小写

您的用户不在乎,甚至可能不记得用户名的确切情况。用户名应完全不区分大小写。将所有用户名和电子邮件地址全部以小写形式存储并将所有输入转换为小写比较之前,这是微不足道的。

智能手机代表了越来越多的用户设备。其中大多数提供纯文本字段的自动更正和自动大写。在UI级别阻止此行为可能不是理想的或完全有效,并且您的服务应该足够强大,以处理无意中自动大写的电子邮件地址或用户名。

12. 构建安全的身份验证系统

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

其他

原文参考:12 best practices for user account, authorization and password management

作者:Ian Maddox

本文由作者按照 CC BY 4.0 进行授权