用户认证最佳实践清单，开发并实施认证时请仔细阅读
发布时间：2022-11-21 12:50:43 所属栏目：Asp教程 来源：
导读： 所有网站现在都有能力提供身份验证。然而，开发人员实施起来仍然非常棘手。开发认证时请阅读最佳做法。
用户身份验证是每个Web应用程序共享的功能。我们应该在很久以前完善它，并且已经实施了很多次。而
用户身份验证是每个Web应用程序共享的功能。我们应该在很久以前完善它，并且已经实施了很多次。而
|
所有网站现在都有能力提供身份验证。然而，开发人员实施起来仍然非常棘手。开发认证时请阅读最佳做法。 用户身份验证是每个Web应用程序共享的功能。我们应该在很久以前完善它，并且已经实施了很多次。而且一直都有很多错误。 部分原因是因为可能出错的事情很长。你可以不正确地存储密码，你可以有一个易受攻击的密码重置功能，你可以暴露你的会话到CSRF攻击，你的会话可以被劫持等等。所以我会尝试编译一个关于用户认证的最佳实践列表。在 OWASP十大总有一些事情你应该阅读，每年。但这可能还不够。 那么，我们开始吧。我会尽量简明扼要，但我会尽可能多地包含相关的陷阱 - 例如，登录后用户会话可能会出现什么问题： 用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解释它在这个岗位和邮戳给出了一些最佳实践。如何形成链接是一个单独的讨论，并有几种方法。将密码重置令牌存储在用户配置文件表中，然后将其作为链接中的参数发送。或者不要在数据库中存储任何内容asp验证码，但发送一些参数：userId:expiresTimestamp:hmac(userId+expiresTimestamp)。这样你就会过期链接（而不是一次性链接）。HMAC依赖于一个密钥，所以链接不能被欺骗。然而，似乎没有就这个主题达成共识，因为OWASP指南有一些不同的方法。 一次性登录链接 - 这是Slack使用的一种选择，它发送一次性登录链接而不是询问用户密码。它依赖于您的电子邮件已经很好的保护，并且您可以随时访问它。如果您的服务没有经常访问，您可以使用这种方法而不是密码（而不是密码）。 限制登录尝试 - 通过Web UI的暴力应该是不可能的; 因此如果出现太多情况，您应该阻止登录尝试。一种方法是根据IP阻止它们。另一个是基于试图登录的帐户来阻止它们（这里是Spring示例）。哪一个更好？我不知道。两者实际上可以结合。而不是完全阻止这些尝试，你可以在第5次尝试之后添加一个验证码。但是不要为第一次尝试添加验证码 - 这是不好的用户体验。 不要通过错误信息泄漏信息 - 你不应该让攻击者弄清楚电子邮件是否被注册。如果找不到电子邮件，登录后只需报告“不正确的凭据”。在密码重置时，可能类似于“如果您的电子邮件已注册，您应该收到密码重置电子邮件。” 这通常与可用性不一致 - 人们经常不记得他们用来注册的电子邮件，并且在进入之前检查其中的一些电子邮件的能力可能是重要的。所以这个规则并不是绝对的，尽管它是可取的，特别是对于更重要的系统。 确保只有在真正有必要时才使用JWT，并且要小心这些陷阱。 考虑使用第三方身份验证 - OpenID Connect，Google / Facebook / Twitter的OAuth（但也要小心OAuth漏洞）。依赖第三方身份提供商存在相关风险，您仍然需要管理Cookie，注销等，但一些身份验证方面已经简化。 对于高风险或敏感的应用程序，请使用双因素身份验证。但Google Authenticator有一个警告 - 如果您的手机丢失了，您将失去您的帐户（除非有手动过程来恢复它）。这就是为什么Authy似乎是存储2FA密钥的好方法。 我确定我错过了一些东西。而且你看到它很复杂。令人遗憾的是，我们仍然处于最常见的功能 - 认证用户 - 非常棘手和麻烦的地步，您几乎总是会发现一些错误。 （编辑：百科站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐