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

身份证验证 校验码

用户身份验证是每个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密钥的好解决方案。

我确定我缺少什么。 您会发现它很复杂。 遗憾的是，我们仍然处在最常用的功能（验证用户身份）的棘手和繁琐的位置，以至于您几乎总是会误解其中的至少一部分。

翻译自: https://www.javacodegeeks.com/2018/04/user-authentication-best-practices-checklist.html

身份证验证 校验码