Many a times I need to log into a website that I used months ago and have forgotten my password. So clicking the reset password link and the site sends me an email with a single use link which allows me to enter a new password and logs me in.
Happy days.
This got me thinking; how about we skip the whole password thing and just send a single use link in an email that I click which logs me into a month long session.
So, tell me. Why wouldn't this work?
This is a reasonable idea. Almost all passwords can be reset through email, and lots of users of many websites do this frequently, often every time or almost every time they log in (if it's a site that isn't used very frequently). If an attacker has control of your email the only advantages of using passwords rather than this method are:
For anything that isn't important enough to need two-factor authentication at password reset, this is probably a good idea. It also adds some security, compared to resetting your password each time you use the site - it eliminates password guessing or bruteforcing and the problem of choosing string passwords.
One problem is probably although there are many forums, etc. that we log in to very infrequently, many of these websites believe or hope that we are going to use them all the time - no website wants to think they are the one we don't use much.
It seems like some respondents have conceived this differently to how I have. I think the OP means that the link in the email would work only once, taking you to a page where you are considered to be logged in, and your browser can save cookies to that effect which last for one month. Therefore the old login emails saved in your client are not any use to an attacker - just as they can't use old password reset emails to re-reset your password. If you login on a different device, you have to re-request a login email, which then lets that browser instance be logged in.
It would work. But it would be pretty aggravating to anyone who has graylisting set up on their mail server, which would delay your email for 15+ minutes. And certainly you wouldnt want to be sending an unencrypted login link for a site that has any e-commerce purpose or stores personal information.
A better approach for you may be to use Social Login, and allow people to register and log in with their Facebook, Google, Yahoo, or other social network accounts. I would never require the use of that, but as an option it removes the issues relating to forgotten user id's and passwords.
I guess a downside to that approach would be that the enduser would have to login to their email account every time they want to access your application. Setting a month long session variable could also be a moot point if the user is on a public computer, or on a shared computer where two or more users of your application would be accessing the site. It could require the enduser to have to check their email frequently if multiple accounts are accessing the app on the same machine. I always feel like emails are a good idea for login credentials for two reason.
1) You can require the email to be unique to cut down on duplicate aliases, and the enduser will typically remember their email address a lot easier than a userID they created solely for your application.
2) It forces the enduser to input a valid email address as opposed to junk to access their account. If they use a disposable email address to verify their account, they will no longer have access to it if they need to make any changes to their account in the future, so they will be reluctant to put a junk address in if the application is worthwhile.
Downsides are obvious. It's annoying to have to input your email address (especially if it is on the longer side) for verification, but I've always felt that if the enduser will have an easier time recalling an email address for a login parameter as opposed to a userID established specifically for one application/site. Hope this helps. Just my two cents!
First, your email isn't secure. Once a thief knows a certain website is sending out access links, they'll start paying closer attention.
Regardless of the format, this is no different than saving the username and password unprotected on the server. Whether it's a username & password combination or some lengthy and complex link string sent to your email address, it's not a good idea to store any of this on the server side in plain text (i.e. not salting & hashing).
Don't you feel more confident when the provider doesn't even have access to your password or whatever type of access link?
Edit: I guess the real question is why not keep sessions for a month.
