There are a lot of Chicken Littles in information security discussions and reporting. We know this, yet the trend continues. One sky that consistently seems to be falling is two-factor authentication (2FA) methods. Between compromises, such as banking fraud via SS7 compromise and access to Reddit cloud and source code hosting providers via SMS compromise, and marketing tactics, like Google saying their employees have not been phished in over a year due to use of Universal 2nd Factor (U2F) tokens, aligned with the launch of Google Titan U2F tokens, there is a mass of discussion about the best second factor, deprecating SMS 2FA, deprecate all but U2F etc. While yes, there are some stronger solutions than others, does that mean we should throw out all the weaker options?

Factors and steps

Let’s take a quick step back to Infosec 101 before looking at the main available two-factor options. 

Identification: A user claims an identity when attempting to access a secured resource. 

Authentication: Evidence (Authentication Factors) that the user is the claimed identity is submitted and verified.

Authentication Factors: There are three authentication factor types:

  1. Something you know (e.g. Password, PIN)
  2. Something you have (e.g. Smartcard, Physical Token)
  3. Something you are/do (e.g. Fingerprint, Keystroke Dynamics)

Multi-Factor Authentication (MFA): Ideally, every secure connection uses multiple factors from the list above. In theory, with more unique factors added to the authentication scheme, you increase security. Two-Factor Authentication or 2FA is a type of MFA, distinctly calling out that it leverages two distinct factors. Example:

  1. User Provides Identity
  2. User Provides Password
  3. User Provides Hardware Token Code
  4. System Authenticates and Authorizes Access

Two-Step Authentication: While frequently used as a synonym to 2FA, its relationship is closer to that of squares and rectangles. 2FA is by definition Two-Step, but Two-Step is not always 2FA. This is because Two-Step Authentication does not require a second authentication factor type. Example:

  1. User Provides Identity
  2. User Provides Password1
  3. System Authenticates, Moves to Challenge2
  4. User Provides Password2
  5. System Authenticates and Authorizes Access

OTP: One-Time Password. Any code that is randomly generated and intended to be used once as a method of identification (e.g. scratch off code on prepaid card, code from authenticator app).

Public-Key Cryptography: Asymmetric encryption; Encryption/Non-repudiation system built on pairs of keys, public and private. The private key is securely held to decrypt and digitally sign data. The public key is freely distributed for signature verification and to encrypt data. 

Everyone up to speed on the basics of authentication terminology? Good.

What are the main options?


This is the most ubiquitous out-of-band authentication method out right now. Once SMS-2FA is enabled, a phone number must be associated with the account. Upon the next login, a text message will arrive with a short, often numeric code to be entered in the sign-in portal, completing authentication. This can be incorporated in almost any web application or program with relative ease. 

The positives:

  • Easy server-side implementation
  • Many/Most have access to SMS
  • No app installation required
  • No additional physical token required

The drawbacks:

  • Providing phone number
  • Phone must be on, active, and available
  • Compromised in a variety of ways (e.g. SIM-swapping, MitM, SS7 compromise, Phishing)
  • Potential SMS cost


Examples: RSA SecurID, Google Authenticator, LastPass Authenticator, Duo Mobile, SAASPASS

These are more likely to be known as Authenticator Apps and Hardware Tokens. Built on a foundation of HMAC-based One-Time Password or Time-based One-Time Password algorithms, they function largely the same: Use a shared secret to automatically generate one-time passwords on a physical device in the user’s possession.

In the instance of physical tokens, they must go through a registration process and physically be distributed to users. Having individual tokens for each user and application is becoming less common at this point. If you are reading this and have a keyring full of single-use key-generating tokens clacking around, it is probably time to push for an alternate system. That said, disconnected token systems like RSA SecureID hardware tokens can provide significant capabilities in a highly secure manner.

Authenticator apps are easier to pass around though! Simply download the application of choice or as required by the application. An authenticator app enabled source provides a QR code containing the secret key as part of a registration page. Scan the code with the authenticator app to connect the two. Voila! 30-second code cycles for all your applications in one place.

The positives:

  • Established framework and workflows
  • Potential for highly secure implementation
  • Potential tamper/hazard resistance
  • No network required

The drawbacks:

  • Cost of hardware tokens
  • Distribution of hardware tokens
  • Codes can be phished
  • Codes manually entered
  • Hardware token can be lost/stolen

The positives:

  • Straightforward server-side implementation
  • Ease of distribution
  • Ease of enrollment
  • Multiple 2FA keys together
  • Increased security – Codes are local
  • Phone doesn’t have to be active on network

The drawbacks:

  • Codes can still be phished
  • If attacker obtains Secret Key, they can generate new codes
  • Must unlock phone, unlock app, and type codes
  • Phone must be on and available

Push-Based 2FA

Examples: RSA SecurID, DUO Push, Twilio Authy, Apple Trusted Device, LastPass Authenticator

The easiest way to look at push-based 2FA is as an evolution of technologies. With both of the previous instances, login is attempted, and a code must be manually entered by the user, whether from a hard token, phone authenticator, or text message. This must be done with enough speed and accuracy to stay in sync with the authenticating service.

Push-based, on the other hand, has a significantly easier user interaction once registration is complete. As login is attempted, a notification is pushed to the linked device (i.e. phone, computer) for user approval. Depending on the program leveraged, this may contain the OTP to be used and/or information on the host attempting access (e.g. IP, geolocation, timestamp). All the user needs to do is approve the login request if they are attempting to login; or deny the request and report/investigate potential compromise attempts if they did not.

The positives:

  • User convenience
  • Geolocation of login may increase security
  • Increased phishing resistance

The drawbacks:

  • Device must be on, active internet, and available
  • Not standardized
  • Doesn’t consolidate logins

Universal 2nd Factor (U2F)

Examples: Yubikey, Google Titan

Representing an open authentication standard, originally created by Google, Yubico and NXP, Universal 2nd Factor (U2F) is the newest player in the mix. Both leveraging public-key cryptography, this standard aligned with a passwordless (authentication protocol (UAF) being developed by the FIDO Alliance. The projects were merged with the intent of developing “the world’s largest ecosystem for standards-based, interoperable authentication”. A lofty goal, but what does it actually mean for those using it?

For developers, having a standardized protocol with which to interact means implementation is easier, faster, and can be applied to almost any application. For users, the ability to leverage one device to uniquely, independently, and securely authenticate to a wide variety of sources is a huge advancement in our password bound status quo. Password length and complexity could also be reduced, given the increased security provided by adding a “something you have” factor that cannot be duplicated; essentially, your second factor is the strong piece, not the password.

During registration, the user taps or inserts their U2F dongle into the device. At this point, a new public/private key pair is generated. The private key is stored, while the public key is stored with the service the user is registering with. When the user attempts to login, the service sends a challenge encrypted with the user’s public key. The user taps/inserts their dongle, which handles the challenge response, granting access.

The positives:

  • Strong public-key crypto framework
  • Easy to use for end-users
  • Straightforward API implementation
  • Privacy (online identities are not linked or tracked)
  • Flexible implementation
  • Attack Resistant (e.g. phishing, malware, MitM)
  • Reduced password requirements
  • Independent of cellular networks

The drawbacks:

  • Physical token to carry
  • Physical token to purchase
  • Increased price for NFC/Bluetooth support
  • Support, while growing, is somewhat limited
  • Physical token can be lost/stolen

With people freaking out, what should we use?

While there is an updated focus, SMS second-factor has had documented risks and exploits for years. Each new type of authentication method released will have some flaw or weakness to be exploited, as proven by history, or will restrict to the point of inaccessibility. The key is that ANY second factor is better than NO second factor.

If you are securing personal accounts, it’s relatively straightforward. Take the time to implement some form of modern 2FA on any accounts you are able to. Smartphone-based authenticator apps are free, easy to use, and put a significant blocker in the path of potential attackers. A U2F key can be purchased for $10-50, depending on features, such as NFC and Bluetooth support. Even SMS 2FA is better than a password alone; there is an extra step and skillset in the way of the attacker.

From an enterprise perspective, I have to agree with GTIC peer Jon Heimerl: The “right” security is better than the “best”. Maybe Joe’s Hat, Boot and Shoe Factory doesn’t need the $400k biometric retinal scanner. Perhaps not even U2F (Joe’s not big on buying dongles that get lost in the hats). It could probably add TOTP to developer and administration platforms through an app without expense and significantly increase its security posture.

There are lists of sites and services that work with one or many types of 2FA, commonly through the various vendors. Two Factor Auth is the best I have found, being platform agnostic, providing detailed information, and ease of use. Unfortunately, despite all the years of documented risks, many systems do not provide any form of two-factor authentication and users frequently choose not to leverage the options available. While users and organizations should consistently ask for “better” security, don’t skip the “good” options in place.