14

Given that security is only as secure as its weakest link, suppose I have website with additional authentication enabled in any of these ways: (example, multiple conditions may be required)

  1. SMS/Voice HOTP message to a phone
  2. Alternate email address
  3. Question & Answer
  4. HOTP soft token (Google Authenticator)
  5. Printed out list of one time passwords
  6. YubiKey
  7. RSA Token
  8. "Known/Trusted" computer (linked by an evercookie or similar)
  9. Client Certificate
  10. Trusted IP

Suppose a user forgets their password, most websites will allow them to reset their password if a combination of #2, or #3 is answered correctly.

Question

  1. Assuming the user has a multifactor device and forgets their password, how should that affect the "forgot password" workflow?

  2. What if the user loses the multi-factor device, or the soft token is corrupted, how should that be re-provisioned?

  3. What if the user forgets the password, and loses the token... what should the re-provisioning workflow look like then?

makerofthings7
  • 50,488
  • 54
  • 253
  • 542

3 Answers3

10

Assuming the user has a multifactor device and forgets their password, how should that affect the "forgot password" workflow?

If the user is initiating password reset from an unrecognized device/browser then a second factor of authentication should be required to perform a password reset. Best practice is to require the second factor consistently across all scenarios: Normal authentication (after verifying password) or Password reset (after verifying access to email link).

If the device/browser requesting the password reset is recognized, then two-factor authentication could be skipped after clicking an email password reset link.

What if the user loses the multi-factor device, or the soft token is corrupted, how should that be re-provisioned?

If the device/browser is recognized or if the user already has an authenticated session on the device then the user should be able to de-provision the lost second-factor device and provision a replacement second factor device.

If the device/browser is not recognized and/or the user does not have an authenticated session on that device then a backup two-factor authentication method must be validated before re-provisioning the second factor device.

What if the user forgets the password, and loses the token... what should the re-provisioning workflow look like then?

Emailing a reset link is sufficient to recover the password from a device/browser that is recognized as trusted*. After the user resets the password the user can go through the re-provisioning of second factor as described above.

If the user's device/browser is not trusted then the user must verify a backup method if the second-factor device is no longer available. This could be a SMS sent to a backup phone number, or a backup string that was provided when the two-factor authentication device was enrolled. Omitting this verification of a backup code negates that two-factor authentication was ever enabled. It must be performed.

See Google's help docs on 2-step verification for more information about how Google handles these scenarios. They've definitely thought this through and have a lot of good information available online.

* Where 'trusted' means that the user previously authenticated using two-factor authentication and indicated that the device/browser should be trusted for subsequent authentications (and to not require two-factor authentication again from this device).

Brian Kelly
  • 201
  • 1
  • 4
  • The emailed reset link could additionally be PGP or S/MIME encrypted – Tobias Kienzler Feb 09 '13 at 08:38
  • If only S/MIME or PGP was useful to normals. :-) Unfortunately, it doesn't look like it will be anytime soon, so we'll have to trust our email clients and servers to make sure the link came from the right source. As far as encrypting the reset link to the correct recipient using S/MIME or PGP... That's an even further stretch. Not gonna happen at scale. – Brian Kelly Feb 20 '13 at 03:41
  • Unfortunately true... One could still add an "Paste your public PGP key here if you want the reset link to be encrypted" field to the reset request dialogue (though I recommend against trying to automagically guess one from the keyservers; what if your service hosts the only copy of the private key etc.) – Tobias Kienzler Feb 20 '13 at 08:23
4

For a proper answer to this, many things need to be taken into consideration which are beyond the scope of this forum. Conditions like how critical it is for users to have immediate access to your application, how easy (or not) it is for users to come visit for in-person authentication, etc., will need to be weighed along with your organization's other business needs to decide how you will handle this.

Ideally, any sort of authenticator reset or recovery process you have in place should be at least as strong as your normal authentication process. If you normally require multi-factor authentication for your application, then you should also require some form of multi-factor authentication for resets or recovery of those authenticators.

To answer your questions:

  1. The user should still be required to use the multifactor device as part of the authentication process for the password reset function.

  2. For best security, require an in-person pickup of a new device. Otherwise, you need to decide what other acceptable forms of identification & authentication will be required for remote re-issuance of the device.

  3. This person needs a stern talking to - use in-person verification only.

Iszi
  • 27,027
  • 18
  • 99
  • 163
4

Multi-factor authentication means that you require several authentication "factors" to grant access. When the user forgets his password, or loses his token, or both, then he ceases to be able to comply to all the factors. Any method used to recover access is thus a breach in the security model. Such breaches may be tolerable if sufficiently constrained and audited.

As a generic answer: in the beginning, the user was not registered, and he had neither password or token. Yet, through some process which we will call registration, the user obtained both a password and a token. At worst, a user who lost his password or token or both could simply register again through the same process.

"Re-provisioning workflows" are a search for a middle-ground, which would ensure decent security but be less expensive than doing full registration again. A common method is to keep a third backup authentication factor (that's what so-called "security questions" are about). Among other "backup factors", you could have him use his credit card for a minute payment (or a big wad of cash, that's your choice), thus piggybacking on the authentication framework painfully maintained by banks. "Activation" phone calls, FedEx/UPS delivery with signature,... there are many possibilities which offer various price/security combinations. What is a good idea depends on the context.

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955