How We Roll – Chapter 3: Multifactor

Welcome to How We Roll! This series is meant to help product owners, developers, and security professionals understand exactly how we implement (or, roll) authentication at Clerk.

Multifactor authentication, or MFA, is the process of authenticating users in multiple different ways before granting access to their account.

It goes by many names. Technologists seem to have settled on multifactor authentication because, well, why limit ourselves to two? But two factor authentication is still common and the phrase is used interchangeably.

Within consumer products, though, we've seen the rise of two-step verification:

Both word substitutions make the concept a little easier to digest, so Clerk has also adopted this language for <UserProfile/> component.

Enough about names, though... How We Roll is for technical details, and naming is the easy part! (Hah.)

Just like passwords, best practices for multifactor authentication have been learned through a history trial-and-error. Let's see how Clerk handles it all!

Clerk provides multifactor authentication out of the box, which means it requires zero additional work. How so? The <UserProfile/> component includes a self-serve flow for users to configure multifactor authentication:

Users can choose between one-time passwords sent by SMS (SMS OTP) or time-based one-time passwords (TOTP). Once configured, they also receive backup codes in the event that access to their other factor is lost.

And <UserProfile/> works in tandem with <SignIn/>, so the next time a user signs in, they will be prompted to authenticate with their second factor. No custom code required!

If preferred, Clerk also provides useUser() and useSignIn() hooks, which enable developers to build custom flows for configuring multifactor authentication.

For multifactor authentication, Clerk mandates that each step satisfies a different factor, or type of evidence, for authentication. The two factors we offer are:

It is critical for Clerk to use one example from each bucket. A one-time password sent by email (email OTP) can be a replacement for a password, but a SMS OTP cannot.

Similarly, if a user with multifactor authentication forgets their password, the "forgot password" flow cannot be used to bypass the second factor. Instead, after the user verifies their email, they will still be asked to provide a possession factor.

If a user with multifactor authentication completely loses access to either factor, Clerk cannot directly help that user regain access to their account. Instead, an application administrator can help facilitate account recovery through the Clerk dashboard.

SMS OTP is a controversial topic among security professions, and rightfully so. SMS is susceptible to a social engineering attack called a "SIM swap," where a telephone company is persuaded to issue a SIM card to an attacker for a victim's phone number.

The general consensus is that SMS OTPs add some degree of security, but a targeted attack has a high chance of success. Jack Dorsey infamously fell victim to a SIM swap which helped an attacker gain access to his Twitter account.

Many argue that SMS OTP should be discontinued entirely. The challenge is that SMS is ubiquitous and convenient, so users are more likely to configure multifactor when SMS can be used.

At Clerk, we don't believe the answer is not one-size-fits all, so our solution is two-fold:

Multifactor authentication is an essential security feature that every application should offer, but it is essential that best practices are followed for knowledge and possession factors. Clerk's components and hooks provide those best practices for multifactor authentication out of the box.