Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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).

share|improve this question
    
Is it because mobile device identification? –  Andrew Smith Aug 22 '12 at 7:52
    
Just found this on Hacker News nopassword.alexsmolen.com I was thinking of the same thing. –  jcubic Sep 25 '12 at 16:41

3 Answers 3

up vote 2 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
    
Also, rotating the token every now and then is also a very good idea. This might not be as practical depending on your application, but if you are sending notification emails with a link to view directly this is a very good option. How often you regenerate depends on your application, and on how secure you need it to be. –  creativedutchmen Aug 22 '12 at 15:47

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.

share|improve this answer
    
I was thinking about sha1(time()) (in php) –  jcubic Aug 22 '12 at 12:16
    
@jcubic it is not secure, but forgot brute force, if the url has a long-live token, it could be sniffed or if someone looks the history of the browser, the account would be compromised. Also, have you consider race conditions? if two users gets/requests the url at the same second... time() works with seconds, so you could end up with two users with the same token, and then what? –  eversor Aug 22 '12 at 12:26
    
Thanks for the tip about race conditions, I will use sha1(array_sum(explode(' ', microtime()))); instead –  jcubic Aug 22 '12 at 12:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.