Geeking out on 2-Step Verification

Recently, we launched the new 2-Step Verification feature to improve security for our customers. There’s some interesting security engineering details under the hood that we’d like to discuss.

Passwords == The Weakest Link

Traditionally, users sign in using a username and password. Passwords are commonly criticized for being an insecure method of authentication, due to the commonality of phishing attacks, massive password dumps, password reuse across sites, weak passwords, etc.

2-Step Verification

2-Step Verification increases the security of your Optimizely account by protecting your login with both a password and an identifier from your phone. The password authentication mechanism is strengthened by requiring a unique code from your phone in addition to your password in order to sign in. So even if your password is compromised through one of the attacks mentioned above, it will not be sufficient for an attacker to access your account because they won’t have the 2-Step code from your phone.

2-Step Verification, Two Factor Authentication, MultiFactor…

There are many different protocols for multifactor authentication:

• SMS / Phone call — a code is sent to your phone via SMS or an automated phone call. This predates smartphones with authenticator apps so it’s great when you need to support the lowest common denominator of phones, but you run the risk of your cell phone carrier being socially engineered so that the SMS codes are intercepted.
• Push-based — a code is sent to your smartphone via a push notification. Requires infrastructure to deliver push notifications.
• HMAC-based One Time Password Algorithm (HOTP) — codes are generated on your phone based on HMACs of a private key shared between client and server
• Time-based One Time Password Algorithm (TOTP) — like HOTP, but with time acting as the event counter. This increases security over HOTP because the OTP codes have a short lifetime.
• Universal 2nd Factor — a newer, promising standard for true two-factor authentication with flexibility on how the client works. However, it requires purchasing a small piece of hardware like a yubikey, which we didn’t want to impose on our customers.
• Fancy crypto protocols — exciting for a nerd and they help protect against attacks like this, but they involve maintaining complex state and crypto on both the client and server, leading to usability issues when you lose your phone.

We chose TOTP due to its simplicity — no reliance on third parties, no risk of third parties being compromised, the logic is concise, and many customers are already accustomed to signing into other systems via TOTP and already have an authenticator app on their phone.

Build vs. Buy

Several vendors offer two-factor- and 2-Step Verification as a service. While this would have freed up our engineering resources to build other parts of our security infrastructure, we were concerned with vendor lock-in. If we wanted to switch from vendor A’s to vendor B’s authentication service, all our our customers would have to re-enroll in the new service. We did not want to impose this inconvenience on people. The lock-in concern, combined with the simplicity of implementing TOTP using the OATH library, led us to decide to build.

Single Sign-On

Organizations that take their security to the next level use Single Sign-On (SSO). This eliminates the need for passwords on their Optimizely accounts. Instead, users log in to their SSO Identity Provider (often with multifactor authentication there) and then sign in to Optimizely via the SAML Single Sign-On protocol.

Optimizely Admin accounts still have the capability to sign in using a password, in case their identity provider is down. For Admin accounts, it makes sense to use 2-Step Verification due to their privileges and password authentication ability.

Does it get better than this?

For defense in depth, there are future opportunities to strengthen authentication further with additional factors, such as location, IP address, time of day, etc. We may also consider 2-Step Verification to authorize sensitive transactions, in addition to just signing in.

Want to build this?

2SV started out as a hack week project. Does this sound cool? We’re hiring.