Limitations of Two Factor Authentication

In an opinion piece in the New York Times, Professor Josephine Wolff of Rochester Institute of Technology describes a “phishing” attack in which two factor authentication might not protect you.  The bait asks you to click on it to go to an application that you are authorized to use.  Clicking on the link takes you to a site that mimics the application.  It mimics the prompts for the user ID, the password, and the one-time password, all three of which it uses to logon to the real application in your name.  Unfortunately, to some readers this may read like a general limitation of two factor authentication rather than a special case.  Some users might conclude that two factor authentication is not worth the inconvenience.  

Consider some of the conditions for the success of this attack.  First the bait must be for an application to which you actually have an account.  Second, the bait must be sufficiently well crafted to convince you that you want to respond.  Third, you must respond, not by going to the application the way you usually do but by clicking on the bait.  Of course, this is very bad practice.  

While if this man-in-the-middle attack is sufficiently well designed as to fool you, it has only stolen a session that you started. Unlike simple passwords it cannot be use to initiate a session on its own.  It has not exposed you to fraudulent reuse of your credentials.  It cannot be used to compromise other systems “laterally” within the enterprise.  

Well designed applications will not permit the attacker to turn off the two factor authentication without requiring a second one time password and will confirm any such change out of band.    

This is not the only possible successful attack against two factor, depending upon the implementation.  Consider Google’s implementation.   It offers the user five different choices of how to get the one-time password (OTP), in an SMS text message, in an e-mail message, in spoken language over the phone, from a software generator, or from a hardware token (Google Titan).  All of these must ensure that the OTP come from and get to the right place.

For example, SMS text and voice over the phone rely upon legitimate user’s control of the phone number.  E-mail requires that the OTP be sent to the legitimate user’s address.  Attackers have been successful in duping the carrier support personnel into pointing the the number to a new SIM or phone that they control.  They have also been successful in duping the application support personnel to change the number, or e-mail address to which they send the one time password.  Good practice requires that the change be confirmed out of band.  After compromise the user will not get one time passwords, or perhaps even phone calls, that they are expecting.   

Even software and hardware tokens rely upon the right token being associated with the legitimate user.  In order to compensate for lost or broken tokens, most applications provide for enrolling new tokens.  An attacker might succeed in duping support personnel into enrolling their token in place of the one heldby the legitimate user.  

Note that all of these attacks require work and special knowledge.  None of them guarantees success, none of them scales well.  Those that permit fraudulent reuse, also deny the legitimate user access and should be obvious.  

Two factor authentication using one time passwords is a special case of “strong authentication,” defined as multiple forms of evidence at least one of which (e.g., one time passwords) is resistant to replay.  Note that security can be increased by using more forms of evidence.  This at the expense of convenience.  

Strong authentication should be preferred for most applications.  Simple passwords must be used only for trivial applications.  All security mechanisms have limitations that we must understand and compensate for but that does not make them unuseable.  We must not permit the perfect to become the enemy of the good.