Last Updated: 2016-10-04 04:25:33 UTC
by Johannes Ullrich (Version: 1)
Implementing password resets is hard. The problem comes down to how we authenticate a user who forgot the common secret(s) we shared. We all know, that "password reset questions" are often just weak "password bypass questions," and can not be used to authenticate a user reliably.
[OK OK OK... I see the comments already: "But I don't answer them correctly." Sure: you do. but you are also reading a blog about password reset questions. ...]
Let's talk about resetting passwords. In my opinion, password reset questions should never be considered as an authentication mechanism. Let's call them a rate-limiting tool: They prevent an attacker from flooding a victim with password reset e-mails. But this is about all they are good for.
So what else can we do? SMS or automated phone calls can be a reasonable option for some sites, but NIST in recent guidance regarding two-factor authentication pointed out that it is certainly possible for an attacker to obtain access to someone's SMS traffic. To do so, an attacker has to convince a phone company to add a new phone to the account. The process usually involves answering some questions similar to password reset questions, or some social engineering. The phone/SMS authentication isn't any better than the weak password reset questions we try to get rid off.
There is another method I have seen implemented a couple of times. I call it "password buddy". When you set up an account, you select a few individuals that may approve password resets on your behalf. In a corporate environment, these may be coworkers or your boss. But it could also be a family member. For this to work, both parties need to have an account at the same site.
Here is a quick workflow how this works:
- User starts the password reset process
- The user will answer a password reset question (quality of the question isn't all that important in that case)
- Answering the question will trigger an email or SMS to the user with a one-time code. The purpose of the code is to prevent a DoS attack where someone starts the password reset but doesn't complete it, in effect locking out the user.
- The user uses the one-time password select a new password. At this point, the account is locked
- The user now notifies the "password buddy" and asks them to approve the reset
- The password buddy logs in and will be presented with an option to approve the password reset
- This will unlock the account. The user can now log in using the new password. (maybe send an e-mail to the user to notify them)
So this is the rough outline of the process. There are some possible problems with it:
- A password buddy may use their access to reset your password. This is why we still send an e-mail to the account holder, and we still ask password reset questions. At least we are not worse off than before.
- Same as above, but instead of your buddy turning against you, an attacker is taking over the buddy's account.
- An attacker could social engineer your buddy into approving the password reset. To do so, the attacker needs to know who the person is. It should also be more difficult to impersonate you to a person you know very well as compared to some anonymous help desk.
- What if your password buddies aren't available? This is why you pick a couple. Let's hope one of them is available in time.
If there is something else that doesn't work in security, then it is central "anonymous" help desks. They can almost always be social engineered. The idea behind this system is that you authenticate to someone who you work with daily, maybe you can even just walk over to them and ask them for help in person. Or a family member that knows you very well.
The "buddy" will never see your password. They just approve the fact that you changed it. They will also not know your password reset questions and any other details about your account. How they authenticate you is up to them, but in a corporate environment, you may want to set up some rules around how the authentication should happen (in person, over the phone...)