Codepath

Handling Forgotten Passwords

It is an inevitable fact that users will occasionally forget their passwords. A web application using password authentication needs a way to allow these users access and the ability to reset their password. Ideally, the process should be possible without labor-intensive involvement from customer service staff. The process must be done securely or else password resetting becomes the weak link which subverts all other security measures. This presents a security challenge and is an easy area to make security mistakes so it is worth careful consideration.

How can the user be authenticated? What proves the user's identity reliably? These are fundamental questions of user authentication generally. Password authentication is only one of many possible authentication factors. Authentication factors fall into three categories.

  • Knowledge: Something only the user knows
  • Ownership: Something only the user has
  • Inherence: Something only the user is

If password authentication ("something only the user knows") is no longer an option, then another reliable authentication factor needs to be chosen instead. Most websites use one of four factors as a replacement when password authentication is no longer possible.

  • Knowledge: Privileged information
  • Knowledge: Security challenge questions
  • Ownership: Access to a user's email account
  • Ownership: Access to a user's mobile phone

Privileged Information

Asking a user to provide privileged information or to answer security challenge questions correctly can be an effective authentication factor, provided that the information is privileged enough. Their flaw is that the questions asked are often not well-designed, too simple, or easily researched.

"Mother's maiden name" was once a common security question, but became too easy to determine as more information became publicly accessible online. Confirming a user's Social Security number might seem like information that only a user would know, but it is routinely required for financial forms (which could be found in a dumpster) and exists in hundreds of third-party databases which could be stolen. Even questions like "What is the name of your best friend?" are weak if an attacker knows the user or can view their friends on social media.

In 2008, vice presidential candidate Sarah Palin's Yahoo! email account was hacked because the answers to the account recovery security questions where too easily researched or guessed.

"The Palin hack didn't require any real skill. Instead, the hacker simply reset Palin's password using her birthdate, ZIP code and information about where she met her spouse—the security question on her Yahoo account, which was answered (Wasilla High) by a simple Google search."

from Wired: "Palin E-Mail Hacker Says It Was Easy"

In 2013, Apple had an embarrassing mistake where the process of asking security questions was flawed. With some inspection of the web server's requests, the security questions could be bypassed altogether by using a faked form. ("Anatomy of the Apple ID password reset exploit")

There is nothing inherently insecure about using privileged information as a security factor. However, it can be challenging to implement securely.


Email Account or Mobile Phone

Confirming a user's access to the email account or mobile phone on file is another common factor used for user authentication. It is the most common additional factor used for Multi-Factor Authentication so it is not surprising that it also serves as a secondary factor when password authentication is not possible.

A user who has forgotten their password can request that a "reset email" be sent to the account already on file. The "reset email" will contain a link which grants the user special one-time access so that they can reset their password. Only a user who has account access can receive and respond to the email. If a user has possession of their mobile phone, they can receive a text message with a link or a security code to provide one-time access.

The problem with this factor is that mobile phones get lost or stolen, and email accounts can be hacked. Imagine that an attacker is able to gain access to a user's email account. The attacker can now also gain access to any site which trusts the user's possession of the email account as a reliable authentication factor. Many hacks have been performed by using a hacked email account to reset account passwords on other sites and services.

As a secondary factors, these are excellent forms of authentication. But when used as the only factor, the possession of a phone or email account becomes too valuable. Swiping someone's mobile phone becomes a master key.


Multi-Factor Authentication

A more secure solution is to use Multi-Factor Authentication anytime a password has been forgotten, even if MFA was not being used for the primary form of authentication.

Send an email or text message to the user and also require the user to answer multiple, difficult security questions. This prevents email accounts and mobile phones from acting as a "master key". It prevents an attacker from merely researching security questions. To gain access, a user must be able to do both which is much a higher standard to meet.

If Biometric Authentication is possible it can provide a very strong factor for verifying user authentication, either on its own as as a factor in MFA.


Account Recovery Implementation

An account recovery page, also commonly referred to as a "forgot my password" page, should provide a form for the user to submit a username, email address, or other account identifier. This information is rarely confidential and it should be assumed that anyone could submit this page with someone else's information.

It is important to always respond with same result to this form submission, even if no account exists for the information provided. The success message and the page content should be absolutely identical. If they are not, then an attacker can use the difference to know whether an account exists in the database or not. This is referred to as user enumeration.

The reset message should only be sent to the email account or phone number which is already on file. An attacker should not be given the chance to re-route the email to a different account which they may control. The message text should never include a new password sent in plain text. The email could be intercepted or, at best, filed away where it might be discovered later.

The act of sending a reset request should not lock out account access using the password. If it did, an attacker could use the reset feature to deny access to legitimate users.

One of the most common techniques for resetting a password is to use a reset token. The token is included in a URL and acts as a one-time pass. Because a secondary login procedure is being enabled, the original password authentication still works in the meantime.

  1. Store a unique token with the user's record
  2. Email the user a link which includes the token
  3. If user has access to their email, they click link
  4. Link takes user to a "Set New Password" page
  5. Form can require privileged information
  6. Password is reset, token is removed from user's record

In addition the token creation time could be stored to limit the time period in which a token can be used.

Fork me on GitHub