用户身份验证最佳做法清单

用户身份验证是每个Web应用程序共享的功能。我们已经实现了很多次，所以很早以前就应该完善它。然而，错误无时无刻不在发生。

造成这种情况的部分原因是，可能出问题的清单很长。您可能会错误地存储密码，可能会具有脆弱的密码重置功能，可能使会话遭受CSRF攻击，会话可能被劫持，等等。因此，我将尝试汇编有关用户身份验证的最佳做法列表。每年， OWASP TOP 10总是您应该阅读的内容。但这可能还不够。

所以，让我们开始吧。我会尽量简明扼要，但我会尽可能涵盖所有相关的陷阱-例如，用户会话登录后可能出什么问题：

使用bcrypt / scrypt / PBKDF2存储密码。没有MD5或SHA，因为它们不利于密码存储。长盐（每位用户）是强制性的（上述算法已内置）。如果您不这样做，并且有人控制了您的数据库，那么他们将能够提取所有用户的密码。然后在其他网站上尝试这些密码。
使用HTTPS。期。（否则，用户凭据可能会通过不受保护的网络泄漏）。如果用户打开纯文本版本，则强制使用HTTPS。并确保仅使用最新的协议（目前使用TLS 1.2； TLS 1.1似乎没有漏洞，因此也可以受支持）。您可以进行Qualys扫描以检查支持的协议版本是否正确。
将Cookie标记为secure 。使饼干盗窃更加困难。
使用CSRF保护（例如，随每个请求验证的CSRF一次性令牌）。框架具有内置的此类功能。
禁止取景（ X-Frame-Options: DENY ）。否则，您的网站可能会以隐藏的iframe包含在另一个网站中，并通过javascript被“滥用”。
有一个同源政策
注销–通过删除所有cookie并使会话无效，让您的用户注销。这样可以更安全地使用共享计算机（是的，用户最好使用私有浏览会话，但并非所有人都那么聪明）
会话期满–没有永久的会话。如果用户关闭您的网站，则其会话应在一段时间后到期。取决于提供的服务，“一会儿”可能仍然是很大的数字。对于ajax繁重的网站，您可以进行常规的ajax轮询，以在页面保持打开状态时使会话保持活动状态。
记住我-由于永久性cookie被盗的风险，（在这台机器上）实现“记住我”功能实际上很困难。 Spring-security使用这种方法，如果您想实现更持久的登录，我认为应该遵循。
忘记密码流–忘记密码流应依赖于向用户发送一次（或到期）链接，并在打开密码时要求输入新密码。 0Auth在这篇文章中对此进行了解释，邮戳给了一些最好的事实。如何形成链接是一个单独的讨论，有几种方法。将密码重置令牌存储在用户配置文件表中，然后将其作为参数发送到链接中。或者不要在数据库中存储任何内容，而是发送一些参数： userId:expiresTimestamp:hmac(userId+expiresTimestamp) 。这样，您将拥有过期的链接（而不是一次性链接）。 HMAC依赖于秘密密钥，因此不能欺骗链接。但是，由于OWASP指南的方法略有不同，因此在该主题上似乎尚未达成共识
一次性登录链接–这是Slack使用的选项，它发送一次性登录链接，而不是询问用户密码。这取决于您的电子邮件受到严格保护，并且您始终可以访问它。如果不经常访问您的服务，则可以使用该方法代替密码（而不是除密码之外）。
限制登录尝试–无法通过Web UI进行暴力破解；因此，如果登录尝试次数过多，则应将其阻止。一种方法是仅基于IP阻止它们。另一个是根据尝试的帐户阻止它们。（这里是Spring示例）。哪一个更好-我不知道。两者实际上可以合并。除了完全阻止尝试之外，您还可以在第5次尝试后添加验证码。但是，请勿在首次尝试时添加验证码-这是糟糕的用户体验。
不要通过错误消息泄漏信息–您不应该允许攻击者弄清楚是否已注册电子邮件。如果未找到电子邮件，则登录后仅报告“凭据不正确”。重置密码时，可能类似于“如果已注册电子邮件，您应该已经收到了重置密码电子邮件”。这通常与可用性不符–人们通常不记得他们过去用来注册的电子邮件，因此在进入之前检查大量电子邮件的能力可能很重要。因此，此规则不是绝对的，尽管它是理想的，尤其是对于更关键的系统。
确保仅在确实必要时才使用JWT，并要注意一些陷阱。
考虑使用第三方身份验证-OpenID Connect，Google / Facebook / Twitter的OAuth （但也要注意OAuth的缺陷）。依靠第三方身份提供者存在相关风险，您仍然必须管理cookie，注销等，但是简化了某些身份验证方面。
对于高风险或敏感应用程序，请使用2因子身份验证。不过，Google身份验证器有一个警告-如果您丢失了手机，就会丢失帐户（除非有手动过程来恢复它）。这就是为什么Authy似乎是存储2FA密钥的好解决方案。