Web应用程序中令牌身份验证的最佳做法？

Question

我想制作一个简单的REST Web应用程序,用户通过电子邮件中的链接与对象进行交互.这些链接具有一个令牌,可用于在没有用户名和密码的情况下对用户进行身份验证,例如通常用于重置密码的用户和密码.

这种无登名,基于令牌的身份验证系统的最佳做法是什么？

Answer 1

我绝不是安全专家......但是我想到的一些要点是 -

1. 终身 - 令牌应在一段时间后过期.使用令牌的无限期访问当然没有意义.

2. Replay attacks - The mechanism should prevent replay attacks.. which means the token should be valid for not only a set period of time, but also fixed number of calls.. Ideally exactly 1. If this number is not exactly 1, then it opens another can of worms..

Unless, its a feature :( For example, by design, the user is expected to share link with others, and anyone with the link should be able to access the resource in question.

3. Authorization - Granularity of the access granted by the token. Is it black and white.. or is the token also associated with a fixed set of rights. For example - token X was issued for Read-Only access, vs token Y was issued, for same resource with R/W access.

4. Administration - User/Admin should be able to see and verify any currently active and issued tokens, and associated information (permissions granted/affected resource etc), and explicitly revoke them, if necessary.

5. Secure Communication - You should consider security of the medium through which the url with token will be sent to the user. i.e. in your scenario, do the users receive emails over secure channel (TLS/SSL)? Should the email itself be protected with DRM?

6. Man in the Middle/Leaks - Similarly, even though you are providing the url in email, and the user is not logging on using user name and password over SSL, the resource should still be accessed using the url with token over SSL. This will prevent any capturing of the tokens from url, by a man in the middle. You would also need to be very careful about when the users browser may use this url in places you didn't expect..

I can vaguely recall reading about a popular site being affected by their urls being used as Refer Url, when displaying ads on their website.. which means, the advertisers site would probably get the url with the token as Refer.

7. Generation - Choice of algorithm to generate the token - May seem pretty obvious, but the token should be extremely obscure and near impossible to guess or brute force. The tokens should never be reused and the algorithm should avoid collisions.

8. Server Side Security - The tokens should probably be treated with same security as you would secure users id and password. If your user database gets hacked, hackers should not get the users passwords and other sensitive information.. Similarly, if your user/resource/token database gets hacked, despite the expiration on the tokens, hackers should not be able to access the resources as users for x hours. Point is, when the tokens are stored on server side, they should themselves be secured/encrypted.

On the same lines.. just like its bad practice to log information like passwords in log file (specially plain text), You'd also have to consider any place these urls may get logged (plain text) on your server.. For example web server logs. If only super admins should have access to user's database, then they should also be the only ones to be able to see these token.. Not your web server admin and not any hackers parsing the log file after the hack.

9. Auditing - If there will be a need for auditing, you'd need some mechanism in place to prove that while the user didn't log on to the system, they are indeed the ones who performed the action/operation in question. Would you want to track the ip address and other information along with the request which would help such auditing?

10. Consent - Do your users even consent to the use of such alternate means of authentication and authorization? Should this be an optional/opt in feature?

EDIT: I found a link to the referrer url problem I was recalling. Although it was in context of user information.

Answer 2

我同意 Vikas 的 10 点，但从安全角度来看，我必须告诉你几点，你必须小心。

我会尽量保持简单。在这里，我将技术内容简化为您的特殊情况。

首先令牌用于防止跨站点请求伪造攻击（XSRF）。记住这一点。如果表单上没有唯一令牌的网络平台，则任何攻击者都可以强制用户发出恶意请求。

如果您只是尝试使用令牌对用户进行身份验证，这是非常错误的。因为必须没有简单的身份验证过程，您不能依赖令牌。

这是登录系统在官方安全文档中的工作方式，我记得是这样写的：

识别：首先要识别用户，一般用用户名来完成。你会知道你的系统中存在一个用户。

身份验证：假设您已经确定用户 A 想要登录。因此，您必须使用您知道且用户 A 知道的内容对用户 A 进行身份验证。我们简单地称其为密码 :) 您不能使用纯文本方法绕过这一步。密码通常在您的数据库中加密，并且还通过与安全证书的所有通信进行加密，请检查 ssl。

授权：好的，您以某种方式进行了身份验证，用户有权获得授权。假设管理员类型用户登录，他有不同的权限，如果普通用户登录，则她拥有常规权限。

会话控制：最后，您必须以安全的方式控制会话。通常在 Web 应用程序中，人们对所有请求都使用访问令牌，以确保授权用户知道该请求。作为平台所有者，您有责任保护一切，直到会话结束。如果您的安全性不能让用户满意，那么您的平台可能无法生存更长时间。

令牌有不同的寿命到期，不同的访问权限。

现在让我们看看像 Facebook 这样的公司如何使用移动应用程序。对于移动应用程序，他们生成一个始终有效的唯一访问令牌。这里的一个缺点是，如果任何攻击者窃取移动令牌，她通常可以随时在帐户中做任何事情:) 无论如何，我们的重点是他们如何使用这些令牌验证用户；首先，令牌对于该设备是唯一的。（实际上并不完全独特或不依赖于硬件，因为如果您清楚地从设备中窃取了必要的文件，那么您可以在另一部手机上使用它）。因此，有了这个在用户首次登录移动应用程序时使用密码生成的独特访问令牌，他们可以始终使用该密码自动登录。而且这个方法和你想做的有点类似。但是请注意，他们不会使用链接或电子邮件代码对用户进行身份验证。

验证不是身份验证，不要忘记这一点。通过发送电子邮件，您可以验证用户通过电子邮件发送的代码是否唯一且仅在 30 秒或 1 分钟内有效。我希望你明白这一点。

在这里我建议你检查跨多个域的单点登录，这真的很有趣。 跨多个域的单点登录 假设您已登录 google.com，然后访问 youtube.com Opps youtube 已登录？是的，很酷，但存在很长时间。他们可以通过一个小的安全技巧来验证跨域的用户，这些域使用不同的 cookie。您将在链接上阅读。

如果您的服务不是真正保密的，并且您想让您的用户对简单的登录系统感到满意。这是2我的解决方案，我喜欢:)

1-) 询问用户他们的电子邮件地址：只需直接发送 4-6 位代码作为电子邮件。询问用户输入/点击那个。根本没有密码，每次登录只有唯一的代码。

2-) 假设您需要使用比电子邮件更强大的方式来验证用户。然后是手机:) 这里的诀窍是；您不会将验证码发送给用户，但他们会将您告诉他们的内容发送给您。要求用户向您的号码 XXXXXX 发送一条带有唯一代码的 SMS :) 将您的移动运营商与您的网络服务连接起来，并检查该代码是否由用户发送给您 :)

在安全性和简单性以及复杂性之间总是需要权衡。你必须找到平衡。

如果您的安全性消失，请不要试图让它变得简单。

如果它看起来更安全，不要试图让它变得复杂。

希望这些信息对您有所帮助。