So you wanna FIDO2?

(record scratch) You must be wondering how we got here…

The Jan 26th OMB memo is historic in directing the US Federal agencies to adopt Zero Trust. Goes without saying that if the US government is adopting the ZT cybersecurity principles, any organization that directly or indirectly deals with the government must follow suite. And everybody else might as well jump on the boat, if not for good cybersecurity, then for good business. The memo is surprisingly specific and refreshingly objective. One of the key directives in the memo is regarding the mandatory use of “phishing-resistant MFA” for staff, contractors and partners.

Ok, what about passphrases and MFA?

The need for phishing-resistant MFA arises from the fact that phishing is still the most prevalent form of compromise and both passphrases and MFA are prone to it, albeit the techniques vary. Let’s start with passwords. There are three problems about passwords that make them fundamentally flawed for authentication:

1. Passwords are created by humans: This makes them easy to guess, easy to crack, and humans have bad habits when selecting compliant passwords.
2. Passwords need to be shared for authentication: This means the password has to travel over to the entity on the other side to authenticate. Thus, a MitM can intercept that password as it travels.
3. Passwords need to have copies: The authenticating party needs a copy of the password to match with what has been sent over. This means passwords can be stolen not just from the user, but also the service provider *cough(Lastpass)cough*.

Over the years there were several controls put in place to help reduce the likelihood of these three vulnerabilities. Controls like password complexity, minimum length, preventing reuse, rotaion etc. were meant to curb the risk. And over the years humans adapted to these controls and now passwords are repeatedly featured in the top 100 worst passwords every year. Passphrases were designed to overcome years of such controls that fostered poor habits. Yet they only address the first issue, which deals with password strength.

Unfortunately, bad actors have been two steps ahead and organizations have been two steps behind. While the collection of leaked passwords has grown from a few hundred megabytes to multi-GB password lists available freely for research, organizations have struggled to do away with complexity rules and frequent password changes that created the mess in the first place.

Though MFA is stronger and far superior to using passwords, most MFA methods still rely on passwords as the first method. This means all the weaknesses of passwords can still exist with MFA, and bad actors only need to breach the second factor. Organizations that managed to move to MFA and strong 2FA have been dismayed to watch bad actors to pivot to novel techniques to gain access to their systems. MFA fatigue is trending up again and there have been several high-profile incidents that have resulted from bad actors exploiting MFA fatigue by targeting employees.

To make matters worse, freely available certificates like those by LetsEncrypt help get that green lock symbol on the browser to fool users while phishing toolkits like Evilnginx make it trivial to copy legitimate sites and host Man-in-the-Middle attacks. And thus arises the need for phishing-resistant MFA.

It’s time for True Passwordless

If we turn the vulnerabilities of passwords around, we can define strong authentication requirements for the password, or the secret as we shall call it now.

While the first criteria is a common requirement, the second and third are satisfied by what is known as True Passwordless (as opposed to caching passwords and replaying it on demand). Leaving aside PIV which may not be as universal, there are few options available to achieve this. The W3C devised WebAuthn to bring passwordless authentication to the masses. By adopting WebAuthn, modern browsers are able to meet the requirements for FIDO2 compliant methods of authentication, while the Client to Authenticator Protocol (CTAP2) works with WebAuthn to enable external devices like security keys and mobile devices to provide authentication capabilities.

The secret sauce for phishing-resistant

There are two flows to enabling the passwordless mechanism. The first flow is always required the first time and deals with registering the identity, while the second flow deals with authentication using this registration info from the first flow.

Registration flow

1. The first time a user wants to authenticate to an Identity Provider (IdP), the IdP asks the user to register with their security key. This is done via a Webauthn request that contains the request for registration, the user id and a nonce
2. The browser calls the security key to complete the registration. These modern devices hold the capability to generate complex mathematical artifacts within their chips, a feature that was missing in traditional implementations of PKI.
3. The security key requires the user to attest they are physically present via PIN or touch or biometric input.
4. The user authenticates to the key as requested
5. The security key generates a private/public cert pair unique to this registration request
6. The security key stores this along with the website certificate. This entry will always map to the IdP that requested the registration with a given id.
7. The security key signs the provided nonce with its private key for the site and sends it to the browser.
8. The browser simply forwards what it gets to the IdP.
9. The IdP validates it received back the nonce it had sent, and thus validates the public key.
10. The IdP stores this public key as they credential for the user id.

Authentication flow

1. This time the IdP sends an authentication Webauthn request with a new nonce
2. The browser calls the security key to complete the authentication
3. Same as above, the security key requires user authentication
4. Same as above, the user authenticates to the security key
5. The security key validates the site cert as one that has been previously registered
6. The security key signs the received nonce with the priv key tied to the site registration
7. Security key sends signed nonce to the browser
8. The browser forwards the signed nonce to the IdP
9. The IdP validates that the signed nonce can be decrypted with the public key attached to the user id

As can be seen, the private key never leaves the device. Thus the secret cannot be intercepted as part of either of the flows. The keys generated are complex enough to defy decryption or guessing. What about the MitM scenario? Lets play it out by adding a MitM to the flow

MitM Attack scenario

1. The MitM makers an authentication request to the IdP on users behalf and receives the nonce
2. MitM forwards this to the browser. However, the certificate presented will be of the MitM, not the original site.
3. Browser forwards this to the security key. We will skip the user attestation parts.
4. The security looks for the site certificate to sign the nonce with the associates private key
5. Since there was no registration done with the MitM, it will not find a priv key to sign the nonce.
6. Authentication fails as no registration was found.
7. MitM cannot send a valid signed nonce back to IdP. Even if MitM had a registration, and received a signed nonce, the signed nonce cannot be decrypted by the public key provided to the IdP since the Idp and MitM have different associated private keys.

In conclusion

The passwordless methods offered by FIDO2 compliant tech are a huge improvement and the next logical evolution for identities. However, the adoption of security keys remains a big challenge. What may also not be apparent in these flows is that there is no “backup” method. Since the keys are unique and singular, they cannot be copied over to a backup hardware token. This means users can either maintain two sets of security keys in case one is lost (each key will hold its own registration info for the user id), or else there has to a backdoor method such as OTP and temporary MFA disable process. Thus it is suggested to enable this for all users, but mandate it for high value users such as executives and administrators.

An excellent and more detailed walkthrough of the Webauthn flow is provided in the Microsoft Ignite video below. Fun starts at the 3:40 mark https://youtu.be/3wtwUh6iyxY?t=221