Highly publicized breaches of password systems are bringing attention to the need for better authentication. Many online sites, including Google, Facebook and Twitter, have responded by implementing some form of multifactor authentication (MFA), where in addition to a password, authentication requires an additional factor. The second factor can be anything from a hardware token to an email message to an SMS sent to a phone.
One issue with password systems has always been the ‘reset' problem: What to do when a user forgets their password. Multifactor authentication makes each authentication stronger, but it often adds to the reset problem, because in addition to forgetting a password, the user can lose or forget the second factor. A hardware token can be lost. A phone number may change. Getting new authentication factors to the user must be simple and inexpensive, but if it isn't secure, it undermines the whole reason for MFA.
A popular reset mechanism has been knowledge-based authentication (KBA), sometimes called ‘questions and answers.' KBA is all about the choice of questions: The tricky thing is for the answers to be easily remembered by the user, but not easily available to an attacker. There are services provided by data aggregators (such as credit bureaus) that can access many data sources and do a reliable job of identity verification, but at a cost. However, many public data sources are accessible by attackers as well, and the growing popularity of social media is making public personal information that was previously private, or at least known only to a limited circle of friends.
Cultural and lifestyle differences between individuals complicate matters. A question like “spouse's mother's name” might be difficult for a person who has had multiple spouses. Questions about private life and relationships might be considered overly personal and offensive. So many sites provide a set of questions in the hopes that each user will find at least two or three that apply to them. The result for the end-user can be confusing and hard to remember – especially when repeating the same process at many different sites.
One interesting KBA option is to use shared history between the user and the site, and ask the user about previous interactions. Ideally the result is something the user easily remembers, but is not readily available to an attacker because it represents some action that isn't widely reported or publicly known. If not easily remembered, it can be something easily discovered. For example, a financial site asking the user the amount of a certain transaction. If the user can't remember it, he can find a monthly statement.
A second approach to reset is to use a long-term shared secret or recovery code. A random string or number is given to the user when an account is created. The user is asked to keep it in a secure place and find it if reset is ever required. Users unfortunately are poor at storing (and subsequently finding) such secrets. Also, reset is difficult if the user happens to be away from home.
Alternate channels are often used for reset, for example by sending the user an email or a text message. For this to work well the site must collect the target email address or phone number during enrollment, and verify at that time that it belongs to the user. It has a limitation if, for MFA, the second factor already is the phone or email account – in which case the very thing lost may be the reset mechanism.
The above mechanisms all share the same advantage: They can be automated and used for self-service reset. If no automated approach is possible, last-resort fallback usually involves human intervention, such as through a contact center (phone, email or chat). Call-centers often don't add security, however, because the agent still has to verify the identity of the caller, likely by using the same questions an automated site would have. So costs are higher without necessarily any increase in security or convenience. Sites that have a physical presence (such as a bank branch) can also ask the user to come in person. That's expensive, user-unfriendly and requires branch personnel to be trained in online site support.
When thinking about MFA, also stop and think hard about your reset mechanisms, and pay attention to a number of considerations. Try to give your users choices by supporting multiple ways to reset, so they can find something that fits them well. Keep reset mechanisms up to date. Periodically ask users to review and verify their reset data. When establishing a reset mechanism (such as during account enrollment), verify it actually works, and always notify the user when it is changed.
Just after an account reset, consider limiting user access – for example, limiting transaction size or allowed operations – until enough time has passed for a notification to be received. That can help control damage in the event the reset was by an attacker. Also, consider risk analysis systems that allow you to look for unusual activity, such as attack patterns on reset mechanisms, or suspicious transactions on recently reset accounts.
Remember, it's not just what authentication technology you choose, but also how you add users and manage their credentials over time, that impact the security and usability of your site.
