Clever Geek Handbook

Best practice for authenticating tokens in web applications?

I want to create a simple REST web application where the user interacts with objects via links in an email. The links have a token that can be used to authenticate a user without a username and password, such as those commonly used to reset a password.

What are the best practices for such a token-based authentication system?

+3


source to share


2 answers


I am from no means security expert. But some moments that come to mind are

  • Lifetime - the token must expire after a specified period of time. Undefined access using a token certainly doesn't make sense.

  • Repeat attacks . The mechanism must prevent replay attacks. This means that the token must be valid not only for a certain period of time, but also for a fixed number of calls. 1. If this number is not equal to 1, then it opens another jar of worms.

If it is not, its function is :( For example, by design, the user should exchange links with others, and anyone with the link should have access to the resource in question.

  1. Authorization - Granularity of access provided by the token. Is it black and white .. or is it a token also associated with a fixed set of rights. For example, token X was issued for read-only access, and for volume Y it was issued for the same resource with R / W access.

  2. Administration . The User / Administrator should be able to see and check any active and issued tokens and associated information (permissions, granted / affected resource, etc.) and explicitly revoke them if necessary.

  3. Safe communication . You should consider the security of the environment through which the token URL will be sent to the user. i.e. in your scenario, users receive emails over a secure channel (TLS / SSL)? Should the email be DRM protected?

  4. Man in the middle / diversion . Likewise, even though you provide the URL via email and the user is not logged in with a username and password over SSL, the resource must still be accessible using a URL with a token over SSL. This will prevent the person in the middle from grabbing tokens from the URL. You also have to be very careful when the user's browser might use this URL in places you didn't expect.

I can vaguely recall reading about a popular site that was influenced by their URLs being used as a link URL when displaying ads on their website. This means that the advertisers' site is likely to receive a URL with a token as a link.



  1. Generation . Choosing an algorithm for generating a token. It might seem pretty obvious, but the token should be extremely obscure and almost impossible to guess or brute force. Tokens should never be reused and the algorithm should avoid collisions.

  2. Server side security . Tokens should probably be handled with the same security as protecting user IDs and password. If your user database is compromised, hackers should not obtain user passwords and other confidential information. Likewise, if your user / resource / token database is compromised despite the expiration of the tokens, the hackers should not be able to access the resources as users in x hours. The point is when tokens are stored on the server side, they themselves need to be secure / encrypted.

On those same lines .. just like its bad practice to log information like passwords in a log file (especially plain text), you also need to consider any place these urls might be logged (plain text) on your server. For example, web server logs. If only super admins are to be able to access the user database, then they should also be the only ones who can see this token. Not a web server administrator, not hackers analyzing the log file after being compromised.

  1. Audit . If you need to conduct an audit, you will need some mechanism to prove that, while the user was not logged in, they were indeed the ones who performed the action / operation in question. Would you like to track the IP address and other information along with a request that will help in such an audit?

  2. Consent . Can your users even agree to use such alternative means of authentication and authorization? Should it be an optional / optional feature?

EDIT: I found a link to the referrer url issue I was thinking about. Although it was in the context of user information.

+8


source


I agree with Vikas' 10 points, but from a security point of view, I have to tell you a few points that you must be careful.

I'll try to keep it as simple as possible. And here I am simplifying the technical details in your special case.

First, tokens are used to prevent Cross Site Request Forgery (XSRF) attacks . Keep this in your mind. If forms contain a web poster without unique tokens, any attacker can trick the user into making malicious requests.

If you're just trying to authenticate a user with a token, that's pretty wrong. Because there shouldn't be a simple authentication process and you can't rely on a token.

This is how the registration system works in official security documents, I write as I remember:

Authentication : You must first identify the user, which is usually done with a username. You will know that a user exists on your system.

Authentication . Let's say you have already determined that the user wants to log in. This way you can authenticate user A with what you know and user A knows. We just call it a password :) You cannot go through this step with simple text methods. Passwords are usually encrypted in your db and also across all communication with secure certificates, check ssl.

Authorization : you somehow made authentication, the user has the right to get authorization. Let's say if a user of type administrator is logged in, it has differences, and if a normal user is logged in, it has normal rights.

Session Control : Finally, you must securely manage your session. Here, generally in web applications, people use access tokens for all requests to ensure that the authorized user is aware of the request. As the platform owner, you are responsible for keeping everything safe until your session ends. If you don't satisfy users with your safety, then your tablet will probably no longer survive.

Tokens have different lifetime for the expiry and different access rights .



Now let's take a look at what facebok is like a company with mobile apps. For the mobile application, they generate a unique access token that is always alive. One of the drawbacks is that if any attacker steals a mobile token, she can do anything at all on the account :) Anyway, here we are talking about how they verify users with these tokens; first, the token is unique to this device. (This is actually not entirely unique or hardware independent, because if you explicitly steal the necessary files from the device, you can use it on another phone). So with this unique access token, which is generated from the user's password when they first log into the mobile app, they can automatically log in with this.And this method is a bit like what you want to do. Note, however, that they do not authenticate users with links or email code.

Verification is not authentication , don't forget this. By sending email, you can verify users if the email code is unique and valid for only 30 seconds or 1 minute. Hope you understand.

Here I suggest you check a single sign across multiple domains, which is really interesting. Single sign -on across multiple domains Let's say you're signed in to google.com and then visit youtube.com. Opps you're already signed in to? Yes, cool, but it has been around for a long time. They can authenticate users across domains that use different cookies with a small and secure trick. You will read the link.

If your service is not confidential and if you want your users to be happy with a simple login system. Here are two of my solutions that I like :)

1-) Ask users for their email address: just send 4-6 digit code by email. Ask the user to enter / click on this. There will be no password at all, only a unique code for each login.

2-) Let's say you need to validate a user in a stronger way than email. Mobile phone then :) Here's the trick; you will not send a verification code to the user, but they will send what you tell them. Ask the user to send an SMS with a unique code to your number XXXXXX :) Connect your operator with your web service and check if the code is sent to the user :)

There is always a trade-off between security and simplicity, as well as complexity. You must find a balance.

Don't try to keep it simple if your security is going away.

Don't try to make it difficult if it seems more secure.

Hope this information helps you.

+4


source






More articles:


All Articles