Instant access to application using token in url

Question

Is it good idea to give access to the site using token in url, this token can be send via email, some sites have reset password done in this way, but I want give access to the whole site (I think I have seen this kind of sites too).

This question is similar to this Security drawbacks for using short-lived access token in javascript client side . But the token can be outside of the browser.

So my questions is: is it dangers to have short live tokens (like sent in email to reset password) and is it for long live tokens without expiration date (user will be able to find old email and use link in this email - with message that he will be able to use this url anytime - and use the site without login).

Answer 1

It is probably not a great idea to send a user an email with a long-lived token that allows access to a user's account in perpetuity. Why do you want to do that? What problem are you trying to solve?

Instead, send the user a reset link with a short-lived, single-use token that lets the user reset their password. See the advice on this site on password reset tokens for the details of how to do that as securely as possible.

Answer 2

This could be done (relatively) safely, but you have to watch out for a few things.

First, you should make sure nobody can access the token from another person easily (doh!). This is harder to do in practice than it seems. For instance, if you are emailing the token in plain text (which you will), you are basically passing the token from smtp server to smtp server you have no control over. EDIT: but the same would also hold for one-time tokens. Using SSL on your server is also a good idea, as that will encrypt the request headers that include the secret string.

Secondly, you should make sure the key is long enough for brute force attacks to take too long. If you combine this with brute-force-detection on your server (the hiawatha webserver can do this out of the box) you should be pretty safe against these.

Third, make sure the key is random! If you are using microtime, this means that an attacker can make an educated guess on the registration time of the victim (most websites have some sort of "registered at" feature), and just test all hashes from timestamps around that time. This reduces the number of hashes to test (for a single, targeted user!) from impractically large to just one million. That might seem a lot, but with one PC, and a 100ms response time this only takes a day. Remember, this is a targeted attack, which makes this very dangerous.

Another option you might implement is to use both the hash of the username, and the access hash in the URL. This way targeting every user at once is not possible.

IMO, when these things are taken into account, getting a token based login can be safer than a "regular" login, where people choose bad passwords and write them down on pieces of paper on their desk.

Answer 3

By using long-lived tokens, you are easing things for bruteforce attacks, I do not know how do you create your tokens, but with almost infinite time to test, and being something so simple as trying different urls, it seems easy to, at some point, break into an account. Also, the url could get sniffed.

The tokens sent to the email to reset the password only works once (if the application is secure). If you do not render useless these tokens after its first use, you are again risking your user's accounts to the problems I described before.

So, to sum it up, I think is a bad idea to have tokens that last more than a single use.