This article was co-written by Vika Basarab, technical program manager at Grammarly, and Igor Maxuk, system engineer at Grammarly.
You might have heard about how security researchers recently hacked companies that were using SMS for multi-factor authentication (MFA). But did you know that the same approach can be used to compromise most factors, not just SMS? For example, a phishing attack could use a web page that looks the same as an organization’s login page to steal the employee’s session.
We’re obsessed with security here at Grammarly, and we’re continuously finding ways to ensure we have industry-leading safeguards. We partner with security researchers to stress-test our systems, which brought us to FIDO2. We’ve adopted it as a best practice to protect against sophisticated phishing attacks.
Motivation: vulnerabilities exposed by traditional OTP authentication
To understand our vulnerabilities, our security team partners with researchers to conduct simulations of sophisticated cyberhacks. One of these hacks exposed issues with traditional OTP authentication, even though it is trusted by many companies, motivating us to switch to the FIDO2 standard. This hack was interesting, so we’ll walk you through how it worked in detail.
First, our white hat partner created a phishing web page that fully mimicked our SSO login page and address. Imagine this page as a magic window that forwards the information entered into its fields to our real SSO site and shows the answers—but saves all the data as it comes through. That way, this page’s creator can access your login, password, and, most valuable of all, your SSO session. From there, they can do almost anything they want with your credentials.
Obviously, the page’s address was slightly different than it should’ve been, and a free SSL service issued the certificate. But let’s be honest: How many users check the certificate if the browser says it’s safe?
To get users to go to this page, the white hat hacker sent emails asking users to follow a link to test a new product. The emails looked completely valid to our mail server and seemed to come from a real internal address, pretending to be an invitation to beta-test a feature. As always, good phishing relies on excellent social engineering—we had several internal initiatives for testing different product features at that time, making this request seem legitimate.
Many users went to Security and asked questions or reported spam/phishing (way to go, cautious colleagues!). But some followed the link and reached the fake SSO page—which looked just like the real one they saw every day. They entered their username and password, leaking their credentials. At this point, MFA kicks in—it’s supposed to stop the phishing attack from getting access to the SSO session. But instead, many users approved the MFA push notification.
Why didn’t MFA save the day? First, the phishing message was sophisticated and seemed legit. Second, team members had developed a fast reflex to answer “yes” to a mobile authentication request (they had been doing it for months, at least once a day). Team members told us that they realized the request was suspicious, but it was too late because they’d already reflexively pushed “yes.”
Why FIDO2 is more secure than OTP
Having seen firsthand how OTP is vulnerable to phishing attacks, we knew we needed a better solution. Fortunately, one exists: FIDO2.
This standard is more secure than OTP because it prevents man-in-the-middle attacks. An OTP is generated by one device and sent to another device; for example, with SMS it’s generated by the service provider and sent to the mobile network operator, which delivers the OTP via SMS to the user. While these two parties believe they are directly communicating, an attacker can secretly relay and possibly alter their communications.
On the other hand, FIDO2 uses public key cryptography techniques to ensure a secure system. In setup, each user is assigned a unique public/private key pair. Then, authentication requests are signed with the private key (which never leaves the user’s device) and verified by the service with the public key. You can find more details about how FIDO2 works here.
What happens is that the service keeps the public key for the user and sends a challenge when the user tries to authenticate. The user’s device selects the correct private key for the service, signs the challenge, and sends it back. The service looks up the user’s public key and verifies the signature to complete the authentication.
FIDO2 authenticator selection
Our goal was to require FIDO2 authentication for all Grammarly team members on all devices. After evaluating our options, we decided to support FIDO2 using a combination of Yubico security keys (YubiKeys) and biometrics devices (Windows Hello and macOS TouchID), which would address both security and user experience.
We initially looked into just using biometrics, but we discovered the limitations during an initial test run. Biometrics don’t work in these cases:
- Enrolling new devices. Biometrics are device-specific because they store crypto keys inside the device, so before using a new device, the user has to authenticate using some other FIDO2 method.
- From a Firefox browser
- When there are physical limitations or readability issues
A YubiKey is a separate piece of hardware you can attach to your laptop or mobile device and physically press to authenticate. Unfortunately, it can be a bit annoying to need to connect it to your computer for every single authentication.
Knowing that the user experience would be key to a successful rollout, we did two things. First, with helpful guidance from our friends at Yubico, we implemented the “blessing” flow: With a new device, team members can log in once using their physical key and then enroll in biometric FIDO2 authentication from there. Second, we chose to send every team member a YubiKey Nano that’s designed to remain permanently connected to a work laptop.
From decision to rollout
To implement FIDO2 at Grammarly, we just needed to figure out how to switch all our MFA systems to support FIDO2 and provide a stable, secure, user-friendly rollout for all team members around the globe. Easy, right? 😉
In Part 2 of this series, coming soon, we’ll describe our rollout, explain the challenges we faced, and share lessons that might help other companies implement FIDO2 via biometrics and YubiKeys. Stay tuned! And in the meantime, check out our open roles if you’re interested in joining Grammarly to do exciting engineering work in an environment that prioritizes security for our data, users, and team members.
