We won! 2021 FIDO Developer Challenge: FIDO2 WebAuthn for Passwordless MFA on Amazon Cognito
As much as I love putting out these articles, it feels impossible sometimes to find the time. I’m writing this from an Air Canada jet flying from Toronto to Seattle. Why you ask? Turns out one of my companies — Lockdrop, just placed first in the 2021 FIDO Alliance Developer Challenge and the FIDO Alliance has been kind enough to invite me to their Authenticate 2021 conference. We’ve just reached cruising altitude over Michigan and the flight display claims I’ve got 4 hours of undisturbed writing time ahead of me.
I was hoping to write this from Medium’s author interface, but it seems gedit will have to do until Elon can on-board these airlines onto Starlink.
Let’s begin.
Solving the password problem with “passwordless”
To give you some background. When Lockdrop was built, we wanted to focus on making the platform ridiculously easy to use. The reality of any security product is that if you add friction to an end-users experience, they’re going to find ways around that friction often undermining the security product all-together. To this end, we wanted to make sure that our users didn’t have to deal with passwords. There’s an infamous XKCD sketch and a John Oliver interview with Edward Snowden that sums up the real world problems with passwords.
The password problem has improved in recent years, with NIST now recommending passphrases instead of passwords, but if you can avoid passwords altogether, why not?
We built Lockdrop’s user authentication system to be “passwordless” from the start. We initially opted for a method that would introduce the least amount of friction for our users — OTP (one-time passcodes) via SMS or Email. When a user logs into Lockdrop, they are asked for the email address or mobile number associated with their account. Lockdrop then sends a time-limited one-time passcode to their email address or mobile number via SMS. The user is prompted to enter this code to complete the login process. The user doesn’t have to remember anything, and we’ve authenticated them using “something they have” (possession-based factor) — a phone or email account as opposed to “something they know” (knowledge-based factor) such as a password. Admittedly this process is not perfect, but it’s arguably better than passwords for the vast majority of users.
What are some weaknesses of OTP over SMS/Email?
Well for one, it’s a single factor. MFA (multi-factor authentication) is an important aspect of operational security today both for professionals and regular people, for good reason. It’s increasingly easy to compromise single factors.
Possession-based factors
While authenticating someone by way of possession of a device associated with them for most people is better than knowledge based factors this isn’t always enough. Thankfully, attacks on this factor typically require nation-state abilities and/or a focus on specific victims. For those with a higher risk profile, SMS messages and emails can be intercepted at telecom companies (or through their partners it seems). Scarier still, is the ease at which SIM swapping attacks can occur.
Knowledge-based factors
Knowledge based factors while sounding incredibly secure (people can’t steal your thoughts, yet..?) in practice are horrible. People choose horrible passwords (easy to guess), password databases are leaked constantly, opening up the door for automated hacks targeting large groups of people.
Biometric-based factors
Biometric factors (or “something you are”) are even harder to compromise. Most threat actors aren’t going to steal your fingers 😬, face or eye-balls, but they might be able to replicate them if they can gain direct access to you and have the knowledge and resources to manufacture facsimiles. Until recently, biometrics have been fraught with adoption issues (needing expensive, sometimes custom hardware) and privacy concerns about how you store and use the biometric data.
Typically multi-factor authentication combines knowledge-based factors (password) with possession-based factors (a mobile phone or security key).
For Lockdrop, with the traditional adoption complexities of biometrics, it’s been frustrating knowing that moving to a “passwordless” (possession-based) login system prevented us from supporting MFA.
Until now.
Leveraging FIDO2 WebAuthn to implement multi-factor passwordless authentication
Flight update: There sure is a lot of small lakes or ponds down there, hello Minneapolis.
Security keys (roaming authenticators)
Years ago, I saw an article explaining how Google managed to eliminate phishing attacks on their employees by using security keys. Ever since, I’ve been using Yubikey’s myself whenever an authentication system supports them. These keys have worked great as a second-factor for knowledge-based first and less commonly passwordless possession-based authentication systems.
In 2019, Yubico announced the Yubikey Bio. For the past two years, I’ve been pestering Yubico for news on it’s release, and let me tell you… they are fort knox when it comes to getting information about product releases. Spoiler: they finally released it a few weeks ago.
Now Yubikey Bio isn’t the first security key to offer biometric authentication, but at the time it was announced, it would have been the the first to do actual biometric authentication on the security key itself (as far as I know, it looks like TrustKey beat them to it). The existing biometric keys at the time offloaded that responsibility to the computer systems they ended up plugged into, leaving a portability (drivers/software) and privacy issue lingering. As great as this product would (or will) become, it wouldn’t be mass-adopted by the general public, most likely adoption would be in portions of the business world.
Mobile phones (platform authenticators)
For the past few years I’ve been watching with excitement as smart phone manufacturers have been adding security chips to their phones. While biometrics have sometimes been integrated into platform devices for decades, these security chips are a game changer.
What are these security chips? If you’ve worked with point-of-sale tech or security-focused computing infrastructure you might be familiar with terms like TPMs, HSMs (Hardware Security Modules), or more recently Enclaves. The depth that one could go into explaining these is far beyond my knowledge, or the purpose of this article. These chips essentially provide a secondary dedicated processor, memory, and storage for cryptographic operations ensuring that a platform compromise doesn’t effect cryptographic integrity and confidentiality. Importantly for the purposes of authentication, and specifically biometric authentication, it opens the possibility of building a delegated trust relationship between an end-user’s devices and a service provider. But what does that mean?
It means that most of those adoption issues around biometrics that I was mentioning, are finally starting to disappear. Phone manufacturers like Apple with their T2 security chip, Google with their Titan Security Module, and Samsung, are storing and running the biometric verification processes on the chips themselves. This does a couple things.
First it provides strong protection for the confidentiality of biometric data stored and verified within these security chips.
More importantly though, it provides the technical foundations for service providers to trust the biometric verification assertions made by these platform authenticators. This trust relationship is critical for a service provider to have confidence that biometric authentication occurred without having to actually handle the biometric data themselves. This is where standards set out by the FIDO Alliance and W3C on how this dance happens is making possible a near-term revolution in authentication, identity verification, and hopefully starting the timer on the eventual death of passwords and similarly plagued knowledge-based factors.
The FIDO Developer Challenge
Flight update: Looks like were flying past Minot, North Dakota
Earlier this year I had seen one of my connections post on LinkedIn about the 2021 FIDO Developer Challenge with context of going “passwordless”. It caught my eye, because I’ve wanted to implement support for security keys in Lockdrop for a while now as a better passwordless option, and this challenge was the perfect motivator.
As mentioned, I had been watching with excitement as device manufacturers were adding biometrics and security chips to devices, but it was unclear to me how they’d build that trust relationship between service providers and the security chips in these devices.
Very quickly I realized that the FIDO Alliance along with the W3C and the smartphone manufacturers were already pretty far along getting this dance between security chips, biometrics, and server-side platforms standardized and implemented. Had I been living under a rock? Why hadn’t I seen someone mention this before? I applied to the challenge with a plan to incorporate passwordless MFA as an alternative to the existing OTP over SMS/Email passwordless log in process for Lockdrop.
In July, I found out my application was accepted and I had a welcome call with the challenge organizer and one of the judges. The organizer was actually located in South Korea. Until now I hadn’t realized how much of a footprint FIDO has in that country. I suppose it makes sense though, big institutions (such as banks) in Asia have been farther ahead than North America when it comes to strong authentication for quite a while now. Anyhow, I was delighted to have been accepted into the challenge, and had a little more than a month to implement and submit a presentation.
Implementing passwordless MFA using FIDO2/WebAuthn
Flight update: We seem to be approaching Yellowstone according to the flight status screen in-front of me, thanks BBC for giving me one more natural disaster to fear.
FIDO2 WebAuthn terms
Terminology within the specifications are purposefully generic, and can make it sometimes confusing to have a conversation with the uninitiated using it. Hence why I’ve tried to avoid it thus far in this post. Let’s define a few of them though.
“ FIDO2 is the overarching term for FIDO Alliance’s newest set of specifications. FIDO2 enables users to leverage common devices to easily authenticate to online services in both mobile and desktop environments. The FIDO2 specifications are the World Wide Web Consortium’s (W3C) and FIDO Alliance’s corresponding. ” — https://fidoalliance.org/fido2/
“ Web Authentication (WebAuthn), a core component of FIDO Alliance’s FIDO2 set of specifications, is a web-based API that allows websites to update their login pages to add FIDO-based authentication on supported browsers and platforms. FIDO2 enables users to leverage common devices to easily authenticate to online services in both mobile and desktop environments. ” — https://fidoalliance.org/fido2/fido2-web-authentication-webauthn/
“We refer to authenticators that are part of the client device as platform authenticators, while those that are reachable via cross-platform transport protocols are referred to as roaming authenticators.” — https://www.w3.org/TR/webauthn-2/#sctn-authenticator-attachment-modality
Lockdrop’s existing authentication system
Lockdrop was built as a serverless application on AWS. We decided to use Amazon Cognito for authentication early on. We leveraged a feature of Amazon Cognito called Custom Auth Flows to extend the built-in functionality and implement the existing OTP over SMS/Email solution. Custom Auth Flows allow you to write what I like to call “escape hatch” code using AWS Lambda functions, allowing you to run custom logic at different parts of Cognito’s authentication process. We were leveraging AWS Lambda’s Node.JS runtime.
Ideally, we’d like to augment this existing system with support for FIDO2 WebAuthn. Can it be done?
As with anything in software, and especially security software, you’re better off leveraging the work of others as opposed to trying to reinvent the wheel yourself. With that in mind, are there any existing JavaScript libraries we can leverage as part of our implementation?
Open-source FIDO2 Libraries (FIDO Servers)
It turns out there are many libraries out there implementing what is called a “FIDO server”. However, as I discovered along the way, the quality varies greatly.
Eventually it came down to two libraries: fido2-lib and SimpleWebAuthn
While fido2-lib seemed to come up more often in my searches, it didn’t appear to be as actively maintained as SimpleWebAuthn and when I tried using it in a Lambda function it actually bombed because it depended on what I believe was a Node.JS c++ addon that is compiled when you run “npm install”. This is problematic for our use case because the Lambda function as part of a development workflow will be packaged in your local dev environment (laptop/workstation) but ran in an AWS Lambda environment container, which may not be compatible with where the Node.JS c++ add-on was initially compiled.
SimpleWebAuthn on the other hand, had a minimal, very clean, clearly principled code base, written in TypeScript, and actively maintained. In-fact they released a new major version of their library on the day I was due to submit Lockdrop’s implementation for the challenge.
SimpleWebAuthn it was.
FIDO2 in Amazon Cognito using Custom Authentication Flows
Before integrating this into the existing Lockdrop authentication system, I wanted to trial it without the added complexity of the existing logic. I also figured this would be helpful for others that are using Amazon Cognito to store and authenticate their users and may want to leverage Cognito to implement FIDO2 authentication into their own applications.
The SimpleWebAuthn library includes a sample web application with a Node.JS server, and I figured the easiest way to quickly POC this library in Amazon Cognito was to re-implement the sample Node.JS server using Cognito Custom Auth Flows, tweaking the sample web application to talk to Cognito instead.
I was able to implement the entire POC in just a matter of hours thanks to the incredible effort of the developers behind SimpleWebAuthn, AWS CDK, and the AWS serverless services.
Here’s a diagram of what this looks like deployed to AWS:
The sample web app is served up statically using S3 + CloudFront. One of the nice things about this serverless implementation over the SimpleWebAuthn provided Node.JS sample web app is that browser implementations of WebAuthn require a valid SSL certificate and the common name needs to match the server’s configured relying party ID. This would be a non-trivial process (imo) for some developers using the original sample web app, but is entirely automated away by the AWS services used and CDK in our POC. Making use of SimpleWebAuthn on AWS even simpler!
You’ll also notice in the diagram the Cognito escape hatches I mentioned (custom auth flows) responsible for registering and authenticating the users.
At Lockdrop we’ve made this code available to everyone for free through the cdk-serverless-fido2-webauthn repo:
For those that really just want to quickly try it, here’s a live demo of that code deployed on AWS: https://delzs89prk9ue.cloudfront.net/
What about Lockdrop’s implementation?
Flight update: We just flew over Spokane, Washington, which means we’re about to start our landing descent, guess I’ll stop here and continue this at the hotel.
The actual implementation in Lockdrop is largely based-off of the above sample implementation with minor modifications to support the existing (dare I say it) “legacy” OTP over SMS/Email passwordless login flow.
During sign-up to Lockdrop users now have an option to enroll in Strong Authentication (with MFA) using a biometric-enabled authenticator:
Sponsors of the 2021 FIDO Developer Challenge
The challenge had an impressive set of sponsors, and some of them were able to actually provide us with authenticators to develop and trial as part of the process.
TrustKey, I briefly mentioned earlier, they were kind enough to send us their G320H and G310H biometric security keys. Octatco also sent us their EzFinger2+ biometric security key. We were able to successfully utilize these as part of our implementation when testing with roaming authenticators.
Unfortunately Yubikey Bio wasn’t available to demo with during the challenge, but we look forward to testing it out soon.
Final thoughts
The 2021 FIDO Developer Challenge was a great experience. I’ve learned lots about the state of FIDO2 WebAuthn today, and it’s super exciting seeing technologies and organizations coming together to transform authentication and identity for really, every human on this planet (or nearly everyone, those that use technology).
Being at the Authenticate 2021 conference here in Seattle, it’s clear that the member organizations have their thumb(print?) on the pulse of authentication. The presentations have been full of statistics and metrics collected by these huge organizations and were starting to see the first steps of a drastic shift in how businesses and the general public as a whole authenticate and identify themselves to the companies and systems they interact with daily.
Is there more to be done? Definitely. There are still important issues around account recovery (avoiding fallback to older forms of authentication) and migration of credentials (that are typically not supposed to leave a security chip) from one platform authenticator to another. These are issues that most definitey have solutions, and it’s the focus of the next step in this transition to a future of strong authentication, leaving the password behind.
