Mobile phones are often employed as the second factor in various two-factor authentication schemes. A widely used authentication scenario involves a text, call or other kind of notification sent to your mobile phone by the service you are accessing, and authenticating you by your ability to confirm its contents. The problem here is that despite claiming their support for two-factor authentication, a lot of Internet services actually design or set it up improperly, ending up with providing not the security, but a false sense of it.
Let’s recall what two-factor authentication (2FA) is. In contrast to traditional single-secret authentication schemes, such as password-based, with 2FA you combine two different pieces of evidence to prove your identity, so that an attacker gaining access to one of the evidences couldn’t take your identity over without having access to the other. This is supposed to significantly reduce the risk of your account being hacked, as the attacker now needs two different pieces of evidence (such as your password and your fingerprint) to gain access to your account.
A lot of people are confused by the terminology 2FA evangelists use to explain the nature of the scheme. They often classify the authentication compounds into something you have, something you know and something you are, and demand that the two pieces of evidence you present to authenticate yourself must fall into two different categories. This classification is not entirely correct and slightly mixes the things up. Strictly speaking, under certain conditions you can successfully use two something you know‘s as two authentication factors; conversely, simply the presence of something you have and something you know together doesn’t guarantee the security of the overall scheme.
A much more important (and correct) requirement for choosing the two authentication factors is their independence of each other. Neither of the factors, when cracked by the attacker, should give her a tiny bit of information about the second factor. If a 2FA scheme manages to satisfy this condition, it can be good (subject to the implementation details and exact authentication methods used), but if it doesn’t – it’s definitely not.
A very common problem with using 2FA on a mobile phone (in-app or in-browser) is that the two factors chosen by the services are not entirely independent from each other. A typical phone usage scenario involves an e-mail app which is always open and authenticated; a number of social network apps with the user signed in; an Internet browser with a bunch of opened sessions. In most cases, access to the e-mail app alone will be enough to gain access to any services you use that are bound to your e-mail address. If your phone gets stolen, the services which are set up to use your mobile phone number as a second authentication factor, as well as a ‘recovery’ password reset point, when requested, will text their one-time access codes… correct, straight into the hands of the thief.
This way, typical something you have and something you know factors, when used exclusively on one device, blur into one big something you have. Any ‘second’ factor employed by a mobile app or service, unless it works via a communication channel totally external to your mobile phone, just extends the first factor and doesn’t add up to the overall account security.
Notwithstanding the above, your phone still can be used as a proper 2FA factor. The main idea here is that you should not be able to authenticate yourself solely with your phone, whatever services and their combinations your phone offers you would use. There must be some other, external and independent factor involved. A variety of options are available here, from using your desktop computer or a different mobile phone for providing the second factor, up to sending in your fingerprints or retina sample. If the authentication can be performed with the sole use of your phone, it is never a 2FA.
