My hope is that by now all companies are using multifactor (MFA for short) authentication to protect all critical assets. MFA authentication simply means that a user must validate their identity through at least two independent mechanisms. Two-factor authentication or 2FA for short just means two independent mechanisms are utilized. However many companies that are implementing 2FA are not implementing true 2FA because the mechanisms are not totally independent. Unless there is no way that one of the mechanisms in a 2FA scheme can be leveraged to gain access to the other mechanism, the mechanisms cannot be considered independent.

Two common 2FA schemes that are subject to compromise because of lack of independence are the use of a dial-back number that goes to a smart phone and hosting a 2FA on a corporate laptop. This post focuses on the risk with a smart phone that is on the receiving end of a dial-back number.

Here is a typically sequence of events for 2FA involving a dial-back number:

1) Logon to a web site or remote desktop or some other resource

2) User is prompted for credentials

3) User enters credentials

4) Upon successful entry of the credentials, the system prompts for an access code that is communicated on the dial-back number.

5) User then receives a phone or in the case of a cell, perhaps a text message or there may be an app configured to acknowledge the call.

6) At this point, the authentication generally occurs in either of the below fashions:

a. User enters the code communicated via text message or voice call to the primary authentication interface. This is commonly used for web site scenarios. For example, my GoDaddy account is setup in that manner.

b. User answers the phone or runs an app which causes a notification to be sent automatically back to the application. This scenario is utilized commonly for remote desktop scenarios such as the solution provided by Duo security.

So, what can go wrong with the dial-back scenario when it involves a smart phone – A lot:

Suppose the phone doesn’t have an auto-lock device on the phone or has a long interval for the lock to kick in (i.e. 1 minute), and also hosts Email. Consider what happens if a person steals the cell phone.

1) The user of the phone may not immediately realize the cell phone is gone or may be slow to report it.

2) The thief is able to access the phone before the auto-lock kicks in.

3) Even if the auto-lock does kick in:

4) The notification default on the iPhone for example seems to show notifications even in lock mode. So, in that case, the thief can actually see the notification code. Worse, yet, the thief can do a “forget password” if the site does not utilize a security question and then receive an Email with a new password or a link to reset the password which also displays on the screen.

The bottom line for a smart phone scenario for 2FA with a smart phone is that the user needs to configure the phone to be secure, particularly if the user’s Email is on the phone. In reality, a smart cell phone is not a true secondary authentication method for 2FA if it is has Email on it unless it is very tightly secured through the use of biometric method such as a thumb print along with a very short lockout period. A land line or a dumb cell phone provides a much higher level of security in that there is no Email or web access that the thief can leverage to determine the password for the logon authentication. Organizations that are relying on a dial-back number may wish to rethink allowing a cell phone to be used for 2FA or at least utilize group policy to lock down the phone and never send passwords over Email for a forgotten password. Another approach is to utilize a completely separate device such as a token-oriented or smart-card security device that does not have other application capabilities.

In my next post, I will describe the risks with 2FA associated with a corporate laptop, where the token is sent to some application installed for a VPN connection. This is potentially almost as bad as relying on a cell phone.

Note – If you do not have multifactor authentication implemented or have the type of risk discussed in this article, please contact us at sales@authintel.com and we can help you get robust multifactor authentication implemented quickly and inexpensively. Controlling any access with just a username and password or any other single mechanism is a huge risk.