A number of years ago, as the Internet became more and more mainstream, websites and web services began to push to the forefront of online business and society.  This generally required allowing users to create accounts with these increasingly complex sites and services, and thus, the entities providing them had to then manage those accounts.  In these early days, such user accounts began to be compromised due to their easily guessable or brute-forceable passwords, so nowadays most sites require users to use relatively complex passwords.  Humans are simply not good at remembering such things, and customer service expenses soon skyrocketed under the flood of users constantly requesting password resets to regain access to their accounts.  The business solution to this?  Let the users reset the passwords themselves!

Sounds like a great idea, right?  Unfortunately the most widely adopted scheme to allow users to do this is to ask the user a number of easy to remember “security” questions, which the user must provide the correct answer(s) to in order to initiate a password reset.  If the user answered the question(s) correctly, they are then allowed to choose a new password for the account.  It just so happens that in most cases, easy to remember questions like which are commonly used for these mechanisms are also easily guessable, or easily researched.  I briefly touched on this topic in my Mnemonic Password Formulas paper.  As we recently saw with Republican Vice Presidential nominee Sara Palin’s email being “hacked”, among countless other similar incidents, this is a fairly significant and prevalent problem.

Essentially, what Yahoo Mail’s and other similar password reset mechanisms boil down to is a significant reduction of the security of the account from the security of a complex password authentication to the security of an easy to answer question or two.  If you stop to consider this, it’s fairly obvious what an attacker who wanted to gain access to your account would do.  What’s the easiest attack vector given those two options?  Obviously, the easy to answer question.

Now, a password reset mechanism is not necessarily an inherently bad thing.  As mentioned before, it can drastically cut an operation’s customer support costs.  But how can this type of mechanism be made more secure?

First, the reset mechanism should never be entirely reliant upon just the “security” questions.  One or more of these questions is fine to initiate the process, but they should not be the entire process.  If the web site or service in question allows you to actively reset the account password right there through the web interface after answering the question(s), this is bad.  Very, very bad.  A better way to do this is to have the reset mechanism generate a temporary password for the account, and then provide that to the user.

Second, the reset mechanism should utilize some previously verified communications channel other than the web interface that the password reset was requested from.  For most websites or services, a verified email address would suffice.  By sending a temporary password to the user’s validated email address rather than allowing them to actively change it, this requires an attacker to also have previously compromised the user’s email account, or at least be able to observe the email traffic.  Now obviously this poses a problem if the web service in question is the user’s email service.  So how about sending it to the user’s cellular phone via SMS?  The user’s IM account?  In drastic circumstances, the temporary password could be sent to the user’s home address via postal mail.

Now obvioulsy many of these communications channels are less than secure, but at least you have a reasonable expectation that the intended recipient will recieve the information.  But what happens if an attacker can observe the information as it traverses one of these communications channels?  One method to limit this type of exposure is to send part of the password over one channel, and the other part over another.  This splits the temporary password into multiple pieces, adding additional challenge to the attacker who must now be observing all of the potential ways that the temporary password, or various parts of it, could be sent to the user.  If you’ve noticed, in this section I’ve been explicitly referring to the password sent as a temporary password.  Setting a new password upon regaining access to the account should always be required, in case the password sent falls victim to the threat discussed here and was somehow observed in transit.

Third, authentication systems should ideally require some form of two-factor authentication.  Note, this does not mean two different passwords, such as a password and a PIN number, as many in the financial industry seem to think it means.  No, this means two different kinds of authentication credentials, such as something the user knows, like a password, and something the user has, like a crypto-token generated from a smartcard.  When dealing with multi-factor authentication systems, whether or not one of the factors such as the password becomes compromised is relatively moot, as an attacker cannot authenticate using only that piece of information.