"These guys are a bunch of farmers and not necessarily the most adept computer users."
Most of the farmers in my extended family are quite intelligent people, many of whom have masters degrees in agriculture.
If instead of "farmers" it said "women" the author would likely get flogged.
That said, there's a lot of good points in this article. SSL wrapping the entire thing so that the autologin URL didn't go over the wire in plaintext would be the obvious next security step.
I am an adept computer user who is also a moron. It stands to reason that there are also very intelligent people who are not very good with computers. I believe this is what the author was getting at.
Meh. The author implies that farmers are likelier to have no clue about computers than people who "would buy their fruit online". That's just nonsense, and it illustrates that the author has a very 1950's idea about farming.
Farming in western coutries these days is about running lean and highly automated businesses on tiny margins. Virtually all professional farmers are comfortable using computers and specialized software.
> Most of the farmers in my extended family are quite intelligent people, many of whom have masters degrees in agriculture.
That's nice, but are they adept computer users? I know plenty of very intelligent people who haven't needed or bothered to learn how to use a computer well. Stop seeing slights where they aren't happening.
This is all fine, with the understanding of exactly who gets to see the authentication token on its way from your server to the customer's inbox: any MTA and if the MTA's pass the e-mail to and fro in clear text, anyone on those networks (including your dear old ISP if you use them for your e-mail provider). Additionally, the webmail provider, and any plugin on the user's browser that can read content out of a web page.
If you are comfortable with that, great. Provide this feature as a nice option. However, if your service hosts any sort of sensitive information at all, or has anything to do with money, please don't turn this on by default. This is one step away from send me my password in clear text.
Yet when I get a reset password email the exact same things happen... so for sites where that reset password is good enough it is also good enough to send auto login links.
Yup. And sending reset passwords link is just as insecure. Just because it is the accepted practice does not mean it's a good idea.
Introducing some sort of security questions helps a bit, depending on implementation. Another idea would be to ask the user to create a temporary PIN, that is then used to sign the token, and is asked for again, when the user actually clicks the emailed link.
Lastly, users are more or less trained not to forward password reset emails. However, getting an email that says "Your stock is burning, click here to sell all." might cause the panic-stricken user to forward this email to his/her broker.
I think he should at least attribute this article: http://sneak.datavibe.net/20110614/please-dont-do-this/ for bringing up the discussion about login links, and would seem to be the most obvious source of inspiration for this post.
Don't get me wrong, the code and implementation brings something to the table on it's own. I just think the original author should get some attention too.
I wrote that post yesterday, but I am far from the "original author" - OKCupid was the first one I saw doing it. My original contribution, if any, is limited to "why doesn't everyone do this?"
As has already been mentioned in the comments on the post earlier today, emailing a direct login link or merely a password reset link actually do have different security implications: when an attacker gains access to the account by resetting your password, you will know about this as soon as you try to login yourself. With a direct login link you won't.
Furthermore, when offering direct login links you are training your users to not remember their passwords. A bad side-effect, unless you have only users who will never login except when notified.
> Furthermore, when offering direct login links you are training your users to not remember their passwords.
Come to think of it, that sounds very convenient. How about a security model that links an account only to an email address? This implies that anyone who can read that email account can log in. For many purposes, this might be fine.
You could do without those nasty passwords entirely then. Logging in from a new computer without cookies stored means having yourself a new "log me in" email sent. Sucks if you have to open your email just for that, but then again, for some services, this might seldomly be a problem because of their email-oriented nature.
I've run an application that used Facebook for this purpose (over 95% of my audience were Facebook users). Just login with Facebook and you gain instant access.
This is basically two-factor authentication, without the first factor.
Isn't Google Authenticator supposed to have an open API so that any service can give you a secure seed and then let you use your mobile phone to login? https://code.google.com/p/google-authenticator/
I think it's probably better to allow the option for single sign-on instead (i.e. Facebook or Twitter). It's just as easy for the user, essentially the same difficulty level for the developer, and seemingly much more secure than sending tokens through email.
Of course, it does have a couple of disadvantages (not all users have Facebook/Twitter accounts or would feel comfortable with you having access to them, plus you're partially dependent on an external service), but I think for most applications SSO would be preferable to authentication tokens.
I do NOT want a link sitting in my email box that logs someone into any account anywhere. I might as well put my password on a post-it and stick it to my monitor.
After sending it to you easily visible on a postcard, delivered by the originator handing it to somebody who happens to be heading in the same direction as your mailbox and who will do the same until it reaches said mailbox.
If you can assume that your users will most likely use the same computer, you can make this technique slightly more secure. Have the random link only log you in if the device is recognized as one that has logged in with a password before. Combine this with two levels of "logged in-ness" and you have a pretty robust, easy to use system.
This kind of URL is called a "capabilities URL" in security circles. It's a common pattern, and often considered more secure than username/password pairs, though its security depends on how the user protects it.
Would love to see some data from a popular site about how often the "forgot my password" link is used and whether it is evenly distributed or only used repeatedly by a subset of the user base.
Another attribute that I would assume of "less adept computer users" is that they usually use the same computer for all their tasks. Again, I'd be interested to learn if the "forgot password" link is used less as more browsers are seamlessly integrating password remembering features.
If you really want to do something like this, PLEASE implement some form of out of band 2FA. For example, SMS a PIN to a mobile number once the link has been clicked. This gives the benefit of not needing to remember your password, but requiring more than just a forwarded email to sign in.
That's the method used by doodle.ch. A security breach in doodle is not very harmful. I don't know how about fruit business.
Whenever money is involved, it is obvious that some people will try to cheat and abuse the system.
The one time use link is a nice trick and would be glad it passes the snake oil check because it provides a significant simplification.
What happen if they loose the link ? What would be the damage if the link gets exposed or stolen ?
28 comments
[ 3.0 ms ] story [ 63.1 ms ] threadMost of the farmers in my extended family are quite intelligent people, many of whom have masters degrees in agriculture.
If instead of "farmers" it said "women" the author would likely get flogged.
That said, there's a lot of good points in this article. SSL wrapping the entire thing so that the autologin URL didn't go over the wire in plaintext would be the obvious next security step.
It's possible he's way off on that assumption, but I would say devoid of data it's a fairly safe one.
I'm sure you could find quite a few insulting fill-in-the-blank nouns.
Farming in western coutries these days is about running lean and highly automated businesses on tiny margins. Virtually all professional farmers are comfortable using computers and specialized software.
That's nice, but are they adept computer users? I know plenty of very intelligent people who haven't needed or bothered to learn how to use a computer well. Stop seeing slights where they aren't happening.
If you are comfortable with that, great. Provide this feature as a nice option. However, if your service hosts any sort of sensitive information at all, or has anything to do with money, please don't turn this on by default. This is one step away from send me my password in clear text.
Introducing some sort of security questions helps a bit, depending on implementation. Another idea would be to ask the user to create a temporary PIN, that is then used to sign the token, and is asked for again, when the user actually clicks the emailed link.
Lastly, users are more or less trained not to forward password reset emails. However, getting an email that says "Your stock is burning, click here to sell all." might cause the panic-stricken user to forward this email to his/her broker.
Don't get me wrong, the code and implementation brings something to the table on it's own. I just think the original author should get some attention too.
Furthermore, when offering direct login links you are training your users to not remember their passwords. A bad side-effect, unless you have only users who will never login except when notified.
Come to think of it, that sounds very convenient. How about a security model that links an account only to an email address? This implies that anyone who can read that email account can log in. For many purposes, this might be fine.
You could do without those nasty passwords entirely then. Logging in from a new computer without cookies stored means having yourself a new "log me in" email sent. Sucks if you have to open your email just for that, but then again, for some services, this might seldomly be a problem because of their email-oriented nature.
Isn't Google Authenticator supposed to have an open API so that any service can give you a secure seed and then let you use your mobile phone to login? https://code.google.com/p/google-authenticator/
Of course, it does have a couple of disadvantages (not all users have Facebook/Twitter accounts or would feel comfortable with you having access to them, plus you're partially dependent on an external service), but I think for most applications SSO would be preferable to authentication tokens.
I agree, though.
Hey, guess what my mom does.
You can find more details here: http://en.wikipedia.org/wiki/Capability-based_security
Another attribute that I would assume of "less adept computer users" is that they usually use the same computer for all their tasks. Again, I'd be interested to learn if the "forgot password" link is used less as more browsers are seamlessly integrating password remembering features.
Automatic login links have the same issues, but them some more.
Please remember people WILL forward emails. This means that people WILL have unauthorised access to your system.
If you are implementing the system as you have described, you are being negligent to your users. You are also setting yourself up to be the next Sony.
The one time use link is a nice trick and would be glad it passes the snake oil check because it provides a significant simplification.
What happen if they loose the link ? What would be the damage if the link gets exposed or stolen ?