账户管理,授权和密码管理往往是很棘手的。对很多开发者来说,账户管理功能是一个暗角,不会引起足够的重视。对于产品经理和用户来说,产品的最终体验往往超出预期。
幸运的是,谷歌云平台(GCP)提供了一些工具,能够使你在产品创造、安全处理和用户账号(本文中指任何在你系统中注册的人——消费者或者内部用户)认证方面做出更好的决策。不论你负责的是什么系统,部署在Google Kubernetes Engine上的WEB网站、 Apigee上的API服务、使用Firebase的应用或者任何包含用户认证的服务,这篇文章会提供最佳实践,来保证你拥有一个安全的、可伸缩的、可用的账户认证系统。
对于账户管理,最重要的原则就是要安全地存储用户的敏感信息,包括用户的密码。用户的数据是神圣的,必须要适当的处理。
任何情况下都不要存储明文密码。你的服务中要艺术的哈希处理密码,并且不能解密密码——例如,使用PBKDF2, Argon2, Scrypt, or Bcryp创建。这个哈希值应该是对用户唯一的登录凭证加盐处理后的结果。不要使用过时的哈希处理技术如MD5、SHA1,并且在任何情况下都不应该使用可解密的算法或者尝试发明哈希算法。
你应该假设你设计的系统最终会被泄露。问问你自己“如果我的数据今天泄露了,在使用我的服务或者他们使用的别的服务时,我的用户的安全和隐私会受到威胁吗?我们可以做些什么来减轻这种潜在的数据泄露可能造成的危害?”
另一个需要考虑的事情:当用户提供给你密码之后,如果你能在任何时候产出一个用户的明文密码,那么你的实现就是有问题的。
一开始使用用户名和密码认证登录到服务的用户,后面可能会使用 Google Sign-In 来登录。他们并不知道这会创建多余的账号。类似地,由于某些原因,服务中的一个用户可能会关联到多个电子邮箱。如果能正确的分离用户身份和认证信息,将多个身份链接到同一个用户就会变得简单。
你的后台需要考虑到用户可能会通过一部分甚至所有途径来通过注册过程,但他们并没有意识到在新的第三方身份没有关联到他们已经存在于系统中的账号。最简单的实现是要求用户提供一个共同的细节用于识别,比如电子邮件地址,电话或用户名等。如果该数据与匹配到系统中现有的用户,则要求他们认证已知身份并将新的 ID 关联到已存在的账号上。
NIST 最近更新了关于密码复杂度和强度的准则。如果你正在(或马上会)使用高强度的散列算法来保存密码,很多问题就会迎刃而解。不管输入的内容有多长,散列算法都会生成固定长度的输出,所以用户可以使用他们喜欢的长密码。如果你必须限制密码长度,应该仅从服务支持的最大 POST 大小来考虑限制。严格地说,这通常大于 1M。
散列后的密码由大家都知道的一小部分 ASCII 字符组成。就算不是,也很容易通过 Base64 把二进制数据转换过来。考虑到这一点,你应该允许用户在密码中随意使用字符。如果有人想在密码中使用克林贡语、表情字符和控制字符并在两端加入空白字符,你应该没有技术方面的理由来拒绝他们。
有些网站或服务要求用户名的字符数不低于两三个字符,不允许不可见字符,前后不能有空格,这些都毫无道理。然而,有些网站会要求最小长度为 8 个字符,只允许使用 7 位(bit) 的 ASCII 字母和数字。
在网站上严格限制用户名,可能会为开发者带来方便,但在某些极端情况下对用户的要求会让某些用户望而却步。
某些情况下最好的办法是指定用户名。如果你的服务中遇到这种情况,需要确保指定的用户名对用户来说很容易想起来也很容易告诉别人。字母数字组合的 ID 应该避免视觉上不易识别的符号,比如“Il1O0”。同时还建议对随机生成的字符串进行字典扫描,确保用户名中没有意外嵌入一些信息。这一原则同样适用于自动生成的密码。
在遗留系统或任何提供电子邮件帐户的平台中,不允许用户更改其用户名是非常常见的。这里有很多好的理由支持不自动释放用户名以供重复使用,但系统的长期用户最终会给出一个很好的理由来使用不同的用户名,并且他们可能不想创建新的帐户。
你可以通过允许别名并让你的用户选择主别名来满足用户期望更改其用户名的愿望。你可以在此功能之上应用所需的任何业务规则。某些组织可能每年仅允许更改一次用户名,或将阻止用户显示除主用户名以外的任何内容。电邮供应商可能会确保用户在将老用户名从其帐户中分离出来之前充分得了解了相关风险,或者可能完全禁止将老用户名断开链接。
为你的平台选择合适的规则,但要确保它们允许你的用户随着时间的推移而成长和改变。
在安全验证上常常被忽略的是会话长度。Google 作出了一些努力来确保用户的行为并进行双重检查,这主要基于某些事件和行为。用户可以有步骤地进一步加强他们的安全性。
你的服务可以有明确的理由来保持会话,而不是非关键分析目的无限期开放,但是,应该有一个门槛来要求您输入密码、或第二个因素或其他用户验证。
考虑多久的时间用户应该认证,并明确之前是不活跃的。如果有人进行密码重置,就需要验证所有活动会话的用户身份。如果一个用户更改核心方面的配置文件或当他们执行敏感的行动,应该提示身份验证或第二因素。并考虑不允许从多个设备或位置登录是否有意义。
当你的服务用户会话到期或需要重复认证,提示用户实时或提供一种机制来保护任何活动来保存未保存的最后验证。用户填写表单,提交它一段时间后,发现他们所有的输入已经丢失,他们必须再次登录,这是非常令人沮丧的。
评论删除后,数据将无法恢复
评论(3)