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:

User goes to login page, clicks on "Forgot password?"
User is presented with a form that asks for their email address.
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)
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?

User goes to login page, fills out email address (or maybe a username to be more secure?)
Email is sent with link. Link has very short time limit (< 5 mins) validity.
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.

I've been staring at this page for the last 8 minutes trying to decide how I feel about it. I think in theory it sounds like a good idea, but in reality if I had to check my email every time I wanted to login to a website, I would be annoyed. Also, the email idea would expose security problems of its own. This idea could be interesting if provided as an option, not a requirement though. (Or perhaps combined with a system like SO has where you can choose various methods of authentication -- well really same method, different sources, but you get the idea) — Corbin, Mar 17 '12 at 03:36
I could even see some users giving up because in their mind it's too many steps. — , Mar 17 '12 at 03:38
This takes longer than the normal login process. Having it as a backup might make sense, though--in addition to the usual login button put a login-via-email button that behaves as you indicate. — Loren Pechtel, Mar 17 '12 at 03:43
It is hard to think of a strong downside, perhaps without trying it I'll never know? I like the idea for having it as an option, that could work. @Corbin I think I stared at it for longer than 8 minutes wondering whether to post it! :) — , Mar 17 '12 at 04:19
The better part of the 8 minutes was spent thinking "Wait, how has no one realized this before?!" :) — Corbin, Mar 17 '12 at 04:22
Well, one problem that I could see is that some people still use desktop based email clients (Eg: Evolution, Outlook), that aren't constantly in sync like GMail, or use work based servers with GMail that update every thirty minutes or so. So, a real problem might be that the 5 minute expiration is too short. Also, this might be too complicated. Sometimes you just want to type in a password and be done with it. — , Mar 17 '12 at 15:23
@GrahamLee thanks, I didn't realise there was a security site (or I'd forgotten), there are so many now! I'll flag it and see if I can get a moderator to either move it or say no. — , Mar 17 '12 at 16:12
Some folks I know do use this for websites they use infrequently, deliberately setting their password to a very long random string, and relying on password reset if they want to log in. — Rory Alsop, Mar 17 '12 at 18:08
One drawback is, that emails of this type sometimes end up in the spam folder, and unexperienced people would not know, why they cannot log in. — martinstoeckli, Mar 17 '12 at 22:08
I worked on a system very similar to what you are proposing as an undergrad (http://www.itr-rescue.org/pubs/upload/836_van%20der%20Horst2008.pdf). We had a plugin for firefox and IE that would automate the process. We even started on an IM version of the system to deal with a few issues in email latency. — mikeazo, Mar 22 '12 at 11:26
You should have logic like some security questions needs to be answered and capt-ca code before sending the Email. We can't built 100% secured system in real world. But we can secure our self by updating the application with current standards. — , Feb 12 '14 at 05:16
This is exactly what the excellent-but-mysteriously-discontinued [Staticloud](https://twitter.com/staticloudapp) used for its login scheme. It was a dream to use, thanks to the help of persistent cookies as described by D.W. above. Granted, this was a few years ago when things like two-factor authentication were pretty rare but I often hope I'll stumble upon another service using this system. — JacobEvelyn, Oct 21 '14 at 23:28

score 35 · Accepted Answer · answered Mar 17 '12 at 18:48

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.

Thanks for the detailed answer, and the linked paper is very interesting. — ian, Mar 21 '12 at 23:53
Nice answer! We now recommend our students to use authentication link sending as a preferred mechanism for sites that require infrequent authentication (e.g. every other month). The extra interaction cost is quickly compensated by not having to remember yet another password. — Steve Dodier-Lazaro, May 06 '15 at 10:43
I would not implement a persistent cookie without first asking the user if they *want* the password/login to be remembered. I usually don't. — mbomb007, Jul 30 '18 at 16:09

score 10 · Answer 2 · answered Mar 17 '12 at 15:24

10

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

answered Mar 17 '12 at 15:24

CodesInChaos

11,854
2
40
50

Thanks for responding. I think they're valid points, depending on the context (as always). Taking your point about OpenID, on the other hand, the user may trust me more than an OpenID provider (I might be known to them personally, perhaps I work with them etc) and another would be that they'd also believe that getting an OpenID account would be more work than benefit to them. – Mar 17 '12 at 16:18
2

Needing to trust both you and my chosen email server is not very different from needing to trust both you and my chosen openID provider...and in many cases a user's openID provider and email server are identical. – Brian Feb 10 '14 at 16:50
It may be more secure. But practically everybody have an email address, not everybody have an OpenID account. Users expect this to work without an OpenID account. And if they have an OpenID account, they expect to be able to reset the password for that using email. Finally one major provider decided to drop OpenID support and instead switch to a different system which requires bilateral agreements between each service provider and each identify provider, which completely undermines the purpose of single sign on. – kasperd Apr 30 '15 at 10:39

score 2 · Answer 3 · answered Mar 17 '12 at 16:56

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.

I think you've made some really valid points, and certainly, I wouldn't use this in every context. The privacy concern wasn't something I'd considered (+1 for just that alone). — ian, Mar 21 '12 at 23:56

score 2 · Answer 4 · answered Mar 18 '12 at 18:36

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:

You have the 2nd factor ("something you have") but not the 1st ("something you know"). So it's still a single-factor authentication scheme.
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.

That's interesting about the two factor auth. Something to think about. In this particular case, the site audience is small enough and the security needs high enough that requesting a reset via a phone call is a really good idea. Sometimes it's the really obvious answer that is forgotten because of being too used to convenience. I do think, however, that it's reasonable, just because it's a kind of standard way to do things; but I agree it's not that strong. — ian, Mar 22 '12 at 21:01

score 2 · Answer 5 · answered Mar 22 '12 at 09:58

2

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

answered Mar 22 '12 at 09:58

mgjk

7,535
2
20
34

When you write "These password reset forms should only allow you to change the password", what are the other options are you saying they can't/shouldn't have access to? – ian Mar 22 '12 at 21:12
1

Just that the URL shouldn't log you in. I.e., it should take you straight to a password change form. The reason for this is because if you provide direct access by URL, it makes it possible for somebody who's e.g. poisoned the DNS cache, to access the target service with very little risk of detection. If the attacker is forced to change the password, yes they still get access, but they've also left a giant footprint on the account. Leaving these giant footprints makes it less valuable to launch sustained attacks on the service. – mgjk Mar 23 '12 at 00:47
1

Ok, thanks for clarifying. So it authorises you enough to change the password but nothing else until the password is changed. That is very sensible, and a level above what I've done, thanks for pointing out this possible attack. +1 – ian Mar 23 '12 at 03:09
1

I've changed things so that on authentication via a reset link, the user is downgraded to a role of "password_reset", which only authorises them to change the password and do nothing else until that is done. That way only those using links will be downgraded and not those who've only requested resets (which isn't necessarily the user). I've also added the time of the last password update so the user's can see that info. Thanks for the advice. – ian Mar 23 '12 at 03:26

score 1 · Answer 6 · answered Mar 22 '12 at 07:51

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.

score 1 · Answer 7 · edited Mar 17 '17 at 13:21

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}

score 0 · Answer 8 · answered Mar 21 '12 at 17:59

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

score 0 · Answer 9 · edited Dec 07 '21 at 08:22

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:

Kid gets access to parent's email briefly
Kid uses one time login to parent's account
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).

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

9 Answers9

Linked

Related