If I include a Forgot Password service, then what's the point of using a password?

Question

I've implemented a Forgot Password service in the following way:

1. User goes to login page, clicks on "Forgot password?"
2. User is presented with a form that asks for their email address.
3. Email is sent to given address if in the database, with a link that contains a (supposedly) unique, long, randomly generated string, which is also stored in the database along with the time requested, allowing for a time limit to be set on the link (which it is)
4. User clicks on link, it is validated, they are then asked to provide a new password.

That's fairly standard, (though I could change small aspects of it), but it made me wonder - since good passwords are so infrequently provided/remembered, why not dispense with the password altogether and use the Forgot Password system instead?

1. User goes to login page, fills out email address (or maybe a username to be more secure?)
2. Email is sent with link. Link has very short time limit (< 5 mins) validity.
3. User clicks link, they're in.

In both scenarios, the user's email security - whether sniffed or broken in to - is the common threat, but in the second scenario:

• The link is valid for a much shorter time.
• It is also likely to be used up more quickly (any sort of validation email can be left alone, but if you definitely want to log in now you're going to use up that link when you get it).
• The user doesn't get to provide a shoddy password.
• The user only has to remember one password.
• A single account can't be shared among several people (unless they share an email address).
• An automated attack needs to break in to the email system and wait for an email, which is likely to be longer than the wait for a password to be unhashed i.e. better than bcrypt.

I'm just wondering what are the downsides? I can see:

• User irritation, perhaps at having to wait for an email or log in to their email too
• It would likely open a new browser window, which can be irritating if you want to organise tabs
• A user might realise they have to protect their email account with a better password, change it, and then lock themselves out :-)

It's just a thought.

---

Thanks to everyone who put forth an answer, there are some really interesting (and definitely valid) points made that have really made me think and given me more areas to investigate. D.W. gets the tick because of the link provided that gives further insight into this particular type of situation, but I really appreciate all the answers given.

Answer 1

That's reasonable. From a security perspective, it is reasonable. I know some people who never write down their passwords for web servers; they just use the "forgot my password" link every time they want to log in.

From a usability perspective, it might be a bit unfortunate, because email isn't instantaneous. Users will have to click "Email me", then wait for the email to show up, then click on the link in their email. Unfortunately, if users have to wait a few minutes (or even just 15 seconds) for the email to show up, they might get annoyed, give up, and go do something else -- or go to your competitor.

A further improvement. It is possible to improve the idea a little bit further, to reduce the usability impact. When the user clicks the link in the email, you could set a persistent secure cookie on their browser. The result is that when the user clicks the link, they're in, and they won't need to go through the rigamarole again in the future on this computer (unless they clear their passwords). On future visits from the same computer, the site will automatically recognize them and no login or links will need to be clicked.

This is not appropriate/sufficient for high-security services, like online banking, where you need to prevent the user's roommate from logging into their account -- but it might be fine for most web sites.

Evaluation. Here is a research paper that investigates this approach and finds it provides increased security against the attacks evaluated in the paper:

Chris Karlof, J.D. Tygar, and David Wagner. Conditioned-safe Ceremonies and a User Study of an Application to Web Authentication. NDSS 2009.

Answer 2

This seems like OpenID, but worse:

It inherits the following problems from OpenID:

• You enter your master password every time. If you are on a less trusted PC, you might only want to log into low security accounts, and not into your email
• Your email provider notices every login

It adds disadvantages over OpenID:

• It's more work to login

Answer 3

This reminds me of 2-factor authentication schemes, like sites that text a pin number to a pre-registered cell phone for authentication.

One thing I didn't really see above is what is the upsides to this? It's certainly more work for the user. Even initial registration conformation emails annoy people. You're going to pollute my inbox every time I want to log in. I log into my online banking at least once a day every day (they log you out after 10 minutes). I'd have thousands of "login" emails from you. And sometimes, email delivery is slow. You want me to wait ~5 minutes to log into your site, because GMail happens to be taking a while. The uptime of your service is now tied to the uptime of mail services around the world.

The problem with this scheme is, it really doesn't get you anything. The vast majority of people use the same password for most services. So you force me to log into my email to get a link that takes me to a place I'd just have used the initial password to start. It also introduces a weakness, as it's a new place for eavesdropping. Right now, I can use our shared secret (the password), and connect over HTTPS. An attacker learns nothing of who I am, my password, etc. With your scheme, every log in requires this authentication link be transmitted in the clear.

There's been a number of high profile breaches as a result of password resets. I believe the biggest recently was to Sarah Palin (though hers was through security questions in all fairness). Password resets generally suck, and we shouldn't be encouraging more of their use.

Answer 4

Your initial point is spot on: most "forgot password" facilities are a weak link (or the weakest link) in the authentication process.

However, your idea of doing something like a "forgot password" protocol for every login is actually similar to the second factor in many 2-factor authentication schemes, e.g. an RSA token. You can already get "soft tokens" which generate login identifiers in software rather than in a dedicated piece of hardware. (So that you can run it on your iPhone, e.g., rather than carrying a hard token around in your pocket all day.)

I see only 2 conceptual differences between that scheme and yours:

1. You have the 2nd factor ("something you have") but not the 1st ("something you know"). So it's still a single-factor authentication scheme.
2. You're generating identifiers on demand and sending them to a user. In contrast, an RSA token generates identifiers constantly whether they are used or not, and there is no transmission to the user (except for the first physical handoff when the device is first given to the user).

Both of these differences weaken the security when compared to a typical 2-factor scheme.

You could make the scheme more secure by not using unencrypted e-mail. You could send S/MIME email or use some other protocol altogether (such Apple Push Notification System if the client has an iPhone) with encryption.

Overall, it's an interesting thought exercise, but I think you would be better served by beefing up the difficulty of the "forgot password" protocol. Or, depending on your use case, maybe you can remove the automated password reset altogether and use a strategy that will deter attackers, such as calling an 800 number to reset forgotten passwords.

I disagree with the poster who wrote, "from a security perspective, it is reasonable." I think your scheme is just exchanging one unsafe security protocol for another unsafe security protocol.

Answer 5

Email password reset systems are only as strong as DNS. While the system is cool, it does more to highlight how insecure password reset forms are rather than suggest that we can use email inboxes as single-signon tools.

These password reset forms should only allow you to change the password, and should alwasy show the equivalent to "your password was last changed on yyyy-mm-dd from a.b.c.d" and after login "you last logged in on yyyy-mm-dd from a.b.c.d" message. This way the user will at least have a clue that their account has been broken into because they'll 1. be forced to request a reset, and 2. they might notice the date.

Cache poisoning is only more difficult with the modern patches to resolvers, but it's not impossible and because of the distributed nature of DNS, and its reliance on UDP, you can hammer at its small randomization spaces all day over thousands of servers until your email account collects a successful login.

When we get DNSsec, then your system will work fine, provided that sniffing the login on the wire or reading it from the inbox isn't a concern...

Answer 6

Yes, from security side that is reasonable. (Though it does have some downsides others have pointed out, like user having to always use the master password.)

But no, from practical perspective that would mess up things. A lot - in ways that can't be downplayed as "user irritation".

For example, you're making the assumption that people are logged into their gmail or such all the time. True for some user, maybe even most, but not true for many. You're also assuming that people can easily open links from their email to the same environment than the browser is in - not true for many mobile scenarios.

The underlying point is this: Email and browsing are separate systems. They wouldn't have to be, sure, but they are. This means basically just that there is an underlying expectation that they are separate. Thus, things in the entire IT ecosystem are designed in a way that expects those systems to be separate. Even if what you're doing would be a nice hack, you can't just go design things ingoring the assumptions that the rest of the people have made. If you do, you'll run into all kinds of trouble you've not expected.

Answer 7

If I include a Forgot Password service, then what's the point of using a password?

Because if a user can log into their account with their known password they know that an attacker hasn't used a password reset link and changed their password.

Password resets create noise. In logs on the target system (which can sometimes be viewed by the user), and in the mailbox of the user for the password reset email, and ideally an email notification that a password was changed on the account.

An attacker who had access to your mailbox could delete these emails, as well as using the link to change the password and login. However, if you cannot log into the system using your password stored in your password manager it is an indication that your account has been compromised in this manner. If you simply used a password reset link each time you are never going to know this.

Of course it is just a red flag, not a definitive piece of evidence on its own - you should ask the administrators of the service to provide logs of when your password was reset (or look yourself if they have this functionality). You can compare these logs with your own in your password manager to find out when your password was last changed. If you didn't change your password at this time you will know something is amiss.

For this reason, securing access with a password can ensure the integrity of your account.

_{I wasn't sure whether this answer best fit that question or this one. However, I think it is relevant to both and I see the other one may be closed soon}

Answer 8

This sounds a lot like BrowserID, the point of which is to just guarantee that users own the email addresses they claim to.

It has the advantage of being mostly painless, (even for devs) but the disadvantage of low adoption and basically no federation partners. (Not that they actually need them in order for it to work, my understanding is that it is fully functional, with every email, already.)

Answer 9

Isn't it fairly easy to support both use cases?

Why not have the forgotten password link allow one to set a new password or to get a one time logon link without setting a new password?

The one time login link option would probably have to warn that it is going to invalidate the current password and invalidate the current password when used. This would cover situations like the following:

1. Kid gets access to parent's email briefly
2. Kid uses one time login to parent's account
3. Kid does nefarious/mischievous thing with parent's account

If the password is not invalidated, the parent may never know that this has happened. Invalidating the current password seems like the simplest mechanism to indicate that something has happened. The warning would, hopefully, make the kid think twice before using the one time logon.

It seems to me that any system that has a password reset mechanism already has the email weakness. Why not allow one-time logon access like this? This would be especially helpful for accounts that one uses very infrequently(like once a year).