The purpose of 2-factor authentication—also known as multi-factor authentication—is to simply devalue a password itself. If a user’s password becomes compromised, the impact of the password’s compromise is diminished when a second factor is required.

At Dwolla, we encourage our employees and our customers to use 2-factor authentication. In a previous blog post, Ben Schmitt, Dwolla’s Vice President of Information Security, discussed how we leverage immediate user feedback on password strength to encourage the right behavior.

In Ben’s post, he briefly touched on the use of 2-factor authentication and its importance in addition to using strong passwords.

This blog post explains the significance of strong 2-factor authentication and why businesses need to develop a strategy to make it simple and easy.

Developing a strategy to evaluate, prioritize and implement secure 2-factor authentication methods is necessary for strong authentication. Cost, user experience and availability are important factors to consider when implementing a multi-factor strategy for an organization.

Why Implement 2-Factor Authentication?

Authentication is the process of proving you are who you claim to be. Typically this is completed by providing something you know, such as a password.

Relying on users or password complexity requirements to create strong passwords is not enough. Let’s face it, humans are terrible at creating them. “[email protected]” and “Winter2018!” could bypass most password requirements while being easily determined by an adversary.

Why? Because people still use them.

The goal of an adversary is to impersonate a user to gain the same privileges and access to information that the user has. If an application only requires a username and password, the adversary can gain access via several methods, including:

  • Password guessing by using a dictionary of the most common passwords
  • Phishing users into sharing their password
  • Searching password dumps from previous data breaches (users tend to use the same password for multiple accounts)

This is where second-factor authentication comes in.

Rather than relying only on something you know to prove who you are—which adversaries can learn—second-factor requires you to prove something you have. This can be a phone to receive SMS messages or a hardware token that generates a one-time password. If an adversary were to obtain a user’s password, they would also need to prove that they have access to the second-factor device.

This makes it exponentially more difficult for adversaries to impersonate users.

For applications that do not inherently have a 2-factor authentication option—or only support weaker second-factor options—Single Sign-on (SSO) permits a user to use one set of 2-factor authenticated login credentials to access multiple applications. Having one strongly authenticated identity for multiple applications is increasingly better than having multiple, weaker, authenticated identities across applications.

Services that integrate with on-premises or web applications to add 2-factor authentication in the authentication flow—such as Duo—can be implemented as well.

Universal Second Factor Gains Support

Using public and private key pairs for the authentication process, Universal Second Factor (U2F) strengthens the authentication process by validating the requesting site before authorizing access. This public/private key pairing prevents MITM (man-in-the-middle) attacks, where an adversary secretly relays and possibly alters the communication between two parties who believe they are communicating directly with each other. The FIDO Alliance, a non-profit organization that works to reduce the reliance on passwords for authentication while improving user experience, created the U2F specification and published an API specification for web applications—called WebAuthn—to leverage strong authenticators.

Hardware tokens, such as a Yubikey, integrate directly with supported browsers and services to generate a unique public key for each account, signed by the hardware token’s private key. The token-generated public key is sent to the application server to be stored for validation.

When signing into the application, the server sends a challenge message to the user’s browser. The user then responds by signing the message with the private key—usually by physically tapping or pressing a button on the hardware token—which the server validates with the public key.

It is important to note that the origin of the challenge is included in the response. Meaning, if someone were to phish as gooogle.com (google.com with three “o’s’), an adversary that captures the signed U2F message, would not be able to pass the message to google.com, as Google would reject the message because the origin in the signed message does not match.

As outlined by Google in their whitepaper “Security Keys: Practical Cryptographic Second Factors for the Modern Web,” their implementation of U2F authentication driven by hardware keys not only reduces sign-in time by greater than 50%, but also reduces support costs of supporting other 2-factor authentication methods. As of this post, U2F is fully supported in Chrome, with other browsers providing support in emerging releases such as Firefox Quantum.

Dwolla is a strong believer in the strength of U2F and requires hardware token-based authentication for employees. We found that implementing hardware key authentication has driven down support costs and made authentication stronger and faster.

Finding a strong second-factor

While many foundational authentication mechanisms exist (strong passwords, device fingerprinting, account lockout/rate limiting, CAPTCHAs, etc.), if your threat model requires strong authentication, you will need an adequate second-factor.

One-time email codes and security questions are not valid forms of 2-factor authentication as they break the expected combination of something you know (password) and something you have (hardware token or similar).

For one-time email codes, if an adversary has control of an email account, that message (containing a one-time code) would be easily obtained and used as a bypass. Security questions are often publicly available, easily researched or phishable (eg high school mascot, mother’s maiden name, childhood street address).

SMS as a second factor is quickly falling out of favor and should be deemed a last option or exception-based second-factor method. The strength of SMS is dependent on the threat model of the call center of your mobile carrier. An adversary could port the number over to their own device by calling support and pretending to be the user (known as pretexting).

This vulnerability is also known as SIM-swapping and is—unfortunately—increasing in occurrence. Even though this attack may be mitigated with a PIN and account security measures with your mobile carrier, it is no longer advisable to use SMS as a second factor.

Although better than single-factor authentication, the strength of this second factor is waning and should be used with caution.

Based on our security posture at Dwolla, here is a list of 2-factor authentication methods ordered from strongest to weakest:

U2F (Universal Second Factor)

Requirements: Hardware Key with U2F support (USB, Bluetooth, NFC)

Advantages: Currently one of the strongest 2-factor options, requires little user interaction.  Origin server domains are part of the signed response, rendering Man-in-the-Middle (MITM) attacks extremely difficult and/or thwarted. The required hardware key and its capacitive sensor is quick and easy to engage. Over time, this method of authentication provides savings and overall lower support costs.

Disadvantages: Cost of hardware, limited browser and application support.

Push Notifications

Requirements: Android or iOS device

Advantages: More difficult to phish, time effective for authentication. Users have a strong location affinity with their mobile devices. The strengths of push notifications are based in strong services: TLS, HSTS, RSA 2048 or greater and prioritized AEAD ciphers. Mobile devices leverage key pairs and secure enclaves.

Disadvantages: Requires internet access on device, more time consuming for configuration.

OTP (One-time Password)

Requirements: An authenticator app or hardware token

Advantages: Short-lived codes, no need for internet or cellular access

Disadvantages: Phishable and time consuming. If device is lost or stolen, the token will need to be reset. Hash-based OTP (HOTP) codes may become out of sync and difficult to resync.

SMS (Simple Messaging Service)

Requirements: A personal device that can receive SMS messages

Advantages: Ease of use, ubiquity of delivery

Disadvantages: Phishable and time consuming. Requires cellular reception/service and prone to SIM swapping/phone porting.

Editor’s Note: The featured image is of a Spider chart that represents Dwolla’s opinion on the strengths and weakness of each second factor authentication method discussed above.

Talk With Our Integration Experts

Contact Sales