arthur-bellore

I’m a tech content creator. I enjoy breaking up seemingly complicated topics into easy-to-understand pieces for people to read. When I’m not in front of a computer, you’ll usually find me reading books.

Cybersec Writer

Arthur Bellore

Why hardware-based Two-Factor Authentication makes the user much more secure over other multi-factor alternatives

When I wrote about how software 2FA is a step-up from SMS 2FA, I also mentioned how there’s one attack vector that software 2FA is still vulnerable to phishing. It’s the **user** who must verify they are entering the passcode into the legitimate website, and bad actors exploit that.

Phishing is a hard problem to solve because the bad actor exploits human behavior that has been ingrained in all of us for the last couple hundred thousand years and will probably continue to be for a long time in the future.

Everybody is prone to fall for phishing campaigns, even security-conscious people, because these attacks are never head-on, explicit attacks, but sneaky ones and when you aren’t expecting them.

And if we look at types of attacks over the years, there is a clear trend: the number of websites containing malware has been declining, while the number of phishing websites skyrocketed in the last few years. You can see that in the chart below:

![01_bleeping_computer](https://images.ctfassets.net/23aumh6u8s0i/5Z7X9Z3Dm07lEvbjtubPO1/6c57ba7fc4b4458c6a995463e6a39ee6/01_bleeping_computer.jpg)
Source: <a href="https://www.bleepingcomputer.com/news/security/google-chrome-uses-safe-browsing-to-improve-phishing-protection/">Bleeping Computer</a> via <a href="https://transparencyreport.google.com/safe-browsing/overview">Google Transparency Report</a> (archive)


Attackers are becoming more **proactive** and trying to **force errors**. With more devices connected to the Internet, these attacks become more profitable (we’ve seen a [surge during the last few years](https://www.f5.com/company/news/features/phishing-attacks-soar-220--during-covid-19-peak-as-cybercriminal)), and now more companies are starting to pay attention to phishing attacks.

Taking the human element out of security is not an easy task, but that is what Universal 2nd Factor, or U2F, tries to do — it’s an open protocol for second-factor hardware keys that doesn’t rely on the user to make sure he’s on the right website; there is a built-in mechanism on the key itself to verify that.

## How The U2F Protocol Was Created

In 2011, the founders of Stockholm-based Yubico would relocate to Silicon Valley to be in close contact with tech companies to further develop the protocol used by the YubiKey into a universal standard. 

> Note: many hardware tokens, such as the YubiKey 5, support more types of authentications on top of U2F (e.g., TOTP), but references to hardware tokens throughout this article refer specifically to U2F.

In that same year, they started discussions with Google’s internal security team and together identified YubiKey as the best solution to solve the employee phishing problem Google was having at the time.

One year later, in 2012, Google and Yubico signed a partnership to co-create the U2F — an open standard for two-factor authentication based on public-key cryptography that would remove the need for the user to verify that they were, in fact, at the intended website. 

They tested the USB token Yubico had created with Google employees, and one year later, they joined the FIDO Alliance board and brought along with them the technical specifications to the protocol. The protocol continued to be improved over the years, being released publicly for Chrome and Gmail, along with many other products.

In 2019, the World Wide Web Consortium (W3C) announced Web Authentication API (WebAuthn), the new global standard comprising the implementation of FIDO U2F security keys in most modern browsers. By that time, [Google already eliminated phishing attacks by having its 85,000 employees use hardware tokens](https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/). 

## How Hardware 2FA (or U2F) Works

When you think of a real-world key, you probably imagine that the same key you use to _lock_ something is also used to _unlock it_. If you have a chest with all of your passwords stored inside, this setup works because you’re the only one who needs to access it.

But what would happen if you wanted to share a password securely with me (and only me)?

Well, here’s an option. I could get a chest and put it outside my door. Then I could leave the key on a key holder outside, and you would come over, put the password inside the chest, lock it, and put the key back on the key holder. As soon as I get back home, I would take the keys, open the chest, and pick up the password you put in there.

This approach is far less than ideal because we can’t be sure who else used the key to open the chest and read the password. I also can’t be sure that you, or anyone else, didn’t make copies of my key to open my chest.

The solution to this problem is **public-key cryptography**, and it’s the principle used by U2F tokens to authenticate users. In public-key cryptography, instead of using just one key, we use a pair of keys — if you lock the chest with a certain key, only the other key can unlock it.

![02_How_hardware_2fa_works](https://images.ctfassets.net/23aumh6u8s0i/1DZ5lxj8zLE6vu3vluVADj/1f79e96a559d9b0eecdce2603be22efa/02_How_hardware_2fa_works.jpg)

Now I can keep one key — my private key — and put the other one outside for you to use — the public key. And since only my private key can unlock the chest, once you lock it, no one else can use the key I left outside to peek inside the chest.

In cryptography, these keys are called a **key pair** and are mathematically linked. I could create as many public keys from a private key as I wanted, but you can’t recreate my private key from a public key.

Key pairs can be created using software, but in the case of U2F, the private key is **generated using a unique secret that is embedded during the manufacturing process and can never leave your U2F token**, which is what makes it so secure.

The process to start using U2F in an account is simple and happens in two steps: registration and authentication.

## Registration

This step involves four parties:

- the user, 
- the hardware token, 
- the client (e.g., a browser), 
- and the remote server. 

To register a security token, the user needs first to authenticate through another method, e.g., with username and password, or while he’s creating the account for the first time. After the user signals they want to register a U2F token, the server sends a challenge — a random number — and an AppID to the user’s device.

The AppID is a unique identifier for the app — on a browser, the AppID is the URL, like `auth0.com`. On Android, it’s going to look something like `android:apk-key-hash:<hash-of-apk-signing-cert>` and on iOS, something like `ios:bundle-id:<ios-bundle-id-of-app>`.

Once this information is received, the user will be prompted to press a button on the hardware token to confirm the request. This will prevent remote attacks even if the key is inserted into the user’s device.

![03_registration](https://images.ctfassets.net/23aumh6u8s0i/2mGwrM5SqnQ6Jz8S5EQXCo/d1ae6f4bfae43541bae86596dfa8fe43/03_registration.jpg)
Source: <a href="https://www.yubico.com">Yubico</a>


The hardware token will generate a [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce) and hash it together with the AppID and the secret key on the token using HMAC-SHA256 to create a private key. From this private key, a public key is derived, along with a checksum. Check the diagram below:

The nonce and public key are sent back to the server to be stored for later when the user comes back to authenticate.

## Authentication

The user will normally authenticate with their login and password. The server will remember that this user has a security token registered and will generate a new challenge to send back along with the AppID and nonce created on the registration phase.

The browser will once again ask the user to press a button on their physical token, and the token will use the received information to re-create the same key pair is created during the registration phase.

If the information was sent from a legitimate server, it should result in the same public key since the secret inside the device didn’t change. The device will then encrypt the challenge sent by the server with the private key and send it back to the server.

However, because the domain is hashed together with the device secret, if you’re on a phishing website, the token will generate a different key, and the checksum will fail.

The challenge can only be decrypted by the public key created with that same private key, which the server already should have stored from the previous phase. The server will try to decrypt it using the public key it already has, and if the challenge matches with the one the server sent, the user is authenticated.

## What Makes Hardware 2FA Better than Software 2FA?

Hardware 2FA brings several security benefits over software 2FA. The most obvious one is phishing resistance. By using the website domain in the key generation process, the token assumes what normally would be a user responsibility — that of verifying that the website they are logging in to is legitimate.

It’s also more leak-resistant than software 2FA. We’ve seen that software 2FA works on the basis of a shared secret between user and server ahead of time, from which the passcode is derived. But if the shared secret is leaked from the server, anyone can use it to generate the correct passcodes.

If the user has secured their account with U2F, however, and the public keys and key handle on the server get leaked, the attacker still won’t be able to take over the account because he’d still need the private key to sign the payload and authenticate themselves.

Not only that, a U2F token can’t be exploited remotely by automated bots. Most keys require a physical touch on the device to sign the payload, so they aren’t vulnerable to the [brute-force attacks that can occur in improperly implemented TOTP systems](https://www.miknet.net/security/the-trouble-with-totp/) (e.g., not taking into consideration user behavior, geolocation, number of bad attempts before locking down the account for a determined amount of time).

In a scenario where the attacker has acquired a list of compromised passwords, brute-forcing any individual account by going over all possible 1,000,000 passcode possibilities is increasingly trivial with a big enough list:

![04_what_makes_hardware_2fa](https://images.ctfassets.net/23aumh6u8s0i/6ovPCcvrlpLnrKCviq4Ukw/8ed6038cb3408a799f5fa6cb54f1ac04/04_what_makes_hardware_2fa.jpg)
Source: <a href="https://www.miknet.net/security/the-trouble-with-totp/">The trouble with TOTP</a>.
 
An automated attack like that can’t happen on U2F-enabled accounts. Also, all cryptographic operations happen inside the token. By the time the private key leaves the token, it already has been hashed using SHA-256, so even if the user doesn’t know that the client is compromised, it’s still safe to use the token.

In terms of usability, in an [internal study at Google](https://research.google/pubs/pub45409/), they found that U2F allowed employees to authenticate as much as four times as fast as using an authenticator app.

And as with software 2FA, users can assign multiple tokens as backups in case they lose one — the only problem here is that each key additional key will cost money (presuming the user already had multiple devices in where to store the TOTP seeds), and considering the already low 2FA adoption rates, it’s something to be considered carefully.

In some cases, though, there might be a decrease in costs by mandating hardware tokens.

It’s what the study above found: initially, Google tested the YubiKey internally with 50,000 employees, and they found that not only internal accounts protected with YubiKey were much more likely to be secure, they also saw a 92% reduction in support incidents.

In the end, this allowed Google to _save money_ in support hours and costs related to compromised accounts by issuing multiple backups per employee.

In fact, requiring backups may also be one of the downsides of hardware 2FA: having no backups can be _extremely problematic_ if you lose your token. You’ll be at the mercy of the admins to let you in again — and in some cases, like in that of password managers where your vault is end-to-end encrypted, not even they can help you recover your account.

## Driving Up The Adoption Of U2F

The biggest problem with U2F right now is adoption — it’s low even among users who use any 2FA (according to [this 2018 report](https://www.theregister.com/2018/01/17/no_one_uses_two_factor_authentication), less than 10% of Gmail users enabled any kind of 2FA), and 2FA adoption overall is already low. In this case, it’s a two-sided adoption problem:

1. Users need to buy a hardware token to use U2F.
2. Applications need to implement the protocol to allow users to use them in the first place.

And as you can see [here](https://2fa.directory), U2F is not nearly as well-supported as SMS and software 2FA. Surprisingly, even applications you would expect to support U2F still don’t, such as some of the password managers.

If you want to incentivize your users to use U2F, Auth0 now supports WebAuthn with FIDO (U2F) security keys, so you can easily offer it as an option for your users. For more information, visit [Auth0 Docs](https://auth0.com/docs/mfa/configure-webauthn-security-keys-for-mfa).

The Working Principles of 2FA (2-Factor Authentication) Hardware

With modern computers capable of testing millions of password combinations per second, securing your online accounts with only a password may not be sufficient anymore.

The Working Principles of 2FA (2-Factor Authentication) Software

diegopoza

System Engineer, geek, foodie, technology lover, speaker.

Sr Manager, Developer Advocacy

Diego Poza

Use penetration testing and 2FA and educate citizens and employees to better anticipate and avoid cyber threats.

On April 7, 2017, at a quarter to midnight, the city of Dallas was hacked.

The perpetrators accessed the City of Dallas's emergency management system and set off 156 blaring alarms—alarms intended to warn people in case of a tornado or hurricane.

It took over an hour and a half for city administrators to understand what had gone wrong and shut the sirens down.

Amid the ongoing digitization of our urban areas, the Dallas incident highlights one of the main dangers that a smart city—for all the good it can do—brings.

Without the right precautions, and without the right security, our smart cities can be just as vulnerable to hacking as our computers and mobile devices.

What happened in Dallas may have been the first high-profile incident of “city hacking,” but it certainly won't be the last.

## Why Security Is a Problem For Smart Cities

The rise of smart cities is intimately linked to the rise in production of Internet of Things (IoT) devices—as are its inherent security problems.

Your average IoT device is relatively cheaply produced. It's not built with the kind of security features you get on a Mac or Windows laptop or tablet or in a mobile phone. It is, however, connected to the internet.

These three factors have made IoT devices incredibly fertile cybercrime targets over the last decade or so.

In 2015, millions of children's names, genders, ages, photos, and parents' records (including home addresses) were compromised through a device known as the InnoTab—a kind of WiFi-enabled tablet for kids.

IoT devices are often trivially easy to access remotely because they're already connected to the internet and not built with cybersecurity in mind. Hackers don't even need to pull information from them. They can simply sit on the device and wait for it to gather information, or even requisition it for use in a distributed denial of service (DDoS) attack or botnet.

Cybersecurity researchers have found vulnerabilities in IoT devices in smart cities, too. Aside from the Dallas incident, significant issues have occurred in smart traffic signals and smart electricity meters. The number of attacks on infrastructure in the U.S. alone went from not even 200 in 2012 to 300 in 2015.

Today, advocates of smart cities are looking much more closely into the security of smart cities and how to build devices that can ensure our cities stay safe and protected—even as they get smarter. According to Gartner, 2.3 billion connected items were used in U.S cities throughout 2017. That number is only going to get bigger and bigger.

## Ensure Security For Critical Facilities

The most vulnerable locations in any smart city are the centers of utilities and power—power plants, water processing plants, and so on.

In Kiev in 2016, hackers shut down 20% of the city's power by hacking into an electrical substation.

Penetration testing is a common method that cities and municipalities use to test for vulnerabilities with their utilities. A security firm is hired to attempt to break in and gain access to the system. Afterward, they produce a report with their findings and give [recommendations for how to avoid the a real attack](https://www.redteamsecure.com/business-insider-rides-shotgun-as-redteam-security-hacks-the-power-grid/).

![Smart city - crime of person gaining access to a facility](https://images.ctfassets.net/23aumh6u8s0i/1n7pLxG3VH1QfPNkEFt9TX/44b26808a6ffb50c7d924a0e3d40ad18/gaining-physical-access-to-facility)

Pen testing isn't just about lurking around a facility late at night and trying to gain physical access. It might also mean dropping a USB key, loaded with a virus, in the parking lot to see whether an employee happens to pick it up and stick it in their laptop; if they do, the key can be formatted to sit on the device as a keylogger, attempt to gain remote access, or send out phishing emails.

It's about social engineering—still one of the most effective ways of gaining access anywhere.

And it means, of course, more straightforward network and application penetration testing—trying to get in by remotely compromising the system itself.

## Two-Factor Authentication

Facilities that provide critical utilities, such as power and water, need to be made absolutely secure, but so does other essential infrastructure in smart cities—like subway transportation, street lights, and security cameras.

The essential technology of any smart city must employ cryptography to protect data. Otherwise, video feeds of your citizenry can wind up being streamed on the internet, or your street lights can end up flashing on and off for hours on end.

Data should be encrypted both at rest and in transit. Any systems that allow access from any parties must accept a username and a password and should go a step forward and enable two-factor authentication. Two-factor authentication is the easiest and most effective step you can take to prevent unauthorized access because it immediately cuts out the most obvious and available attack vectors.

![Two-factor authentication example using phone device auth to grant access](https://images.ctfassets.net/23aumh6u8s0i/HWYrg3Jdj6NOgoKwz1AgN/69deef407a90c08422882ec34e06392f/two-factor-authentication-using-smartphone)

[Two-factor authentication](https://auth0.com/learn/two-factor-authentication/), at root, is about ensuring that anyone accessing your systems has two methods of proving their identity. That might mean a username, password, and something like a biometric key or a one-time password delivered through an app on their phone, like [Auth0 Guardian](https://auth0.com/docs/multifactor-authentication/guardian) or Google Authenticator.

## Education For Citizens and Leaders

Ultimately, the best way to prevent most cyberattacks (on cities or anything else) from succeeding, or at least to mitigate the damages, is education.

Emails that look like they're from a C-suite executive at your company but have an odd-looking From: address, or USB drives that look like they've been forgotten in your office's parking lot: These are highly visible red flags that indicate that some person or group has gotten access to your systems or is trying to. They're also some of the most commonly successful attacks out there because many people don't recognize the signs for what they are.

When one person falls for a phishing email, it can cause huge ripple effects down the line as their contacts are emailed en masse and compromised as well.

Educating denizens about the common forms of cyberattacks and the ways to prevent falling victim to them is the number one way that cities—if they cannot prevent attacks from happening—can ensure that the effects of malicious acts do not ripple out and cause wider damage.

## The Future of Urban Cybersecurity

The cybersecurity challenges of the future are going to look bigger and much different than many of those we have today.

As smart devices proliferate and security vulnerabilities loom larger and larger, it's on all of us to make sure that the cities we are building—no matter how smart—are secure as well.

<include src="asides/AboutAuth0" />

How Do Smart Cities Tackle Cybersecurity?

df6c864847fba9687d962cb80b482764?size=200 avatar

df6c864847fba9687d962cb80b482764?size=200

Martin Gontovnikas, a.k.a Gonto, is a software engineer at heart who moved to the ‘dark side’ and became VP of Marketing at Auth0. He considers himself lucky to have found a way to combine his two passions and apply his engineering thinking model to marketing. Gonto’s analytical thinking is a huge driver of his data-driven approach to marketing strategy and experimental design. He is based in the Bay area, and in his spare time, can be found eating gourmet food at the best new restaurants, visiting every local brewery he can find, or traveling the globe in search of new experiences.

Former SVP of Marketing and Growth at Auth0

Martin Gontovnikas

Financial institutions are under intense scrutiny by regulators as well as customers to be sure that their user data is secure. Legal pressures are mounting, and customers are increasingly [vocal and demanding](https://auth0.com/blog/cambridge-analytica-and-facebook/) that companies are more transparent and responsible with their information. Finance, over and above other industries, demands a higher level of protection. Behemoth institutions like [J.P. Morgan](https://dealbook.nytimes.com/2014/12/22/entry-point-of-jpmorgan-data-breach-is-identified/?mtrref=www.google.com&gwh=7D07D481AE355F1F8949A1C514F4B11C&gwt=pay&assetType=nyt_now) and [Equifax](https://finance.yahoo.com/news/equifax-reveals-many-ssns-credit-cards-passports-hacked-182355107.html) continue to be top targets for cybercriminals.

One concrete step that these institutions, along with smaller firms, can take is to secure their consumer apps. Traditionally, apps with authentication systems require users to provide a single identifier, such as an email address, username, or phone number, along with a correct password or pin to gain access; however, with financial apps, this isn't always enough.

**Two-factor authentication** or ***2FA*** adds an additional step to the process. Like a double security door — if a thief unlocks the first one, he's blocked by another.

## Breaking Down Common 2FA Approaches

In general, there are [three factors](https://preview.pcmag.com/feature/358289/two-factor-authentication-who-has-it-and-how-to-set-it-up) in authentication:

1. Something you know (such as a password you created)
2. Something you have (such as a cell phone or other piece of hardware)
3. Something you are (such as your fingerprint, gait, or facial features)

Two-factor authentication requires that you have two of these options. In addition to a password that you “know,” 2FA can request you “have” a cell phone or other device handy for a TOTP (a time-based one-time password algorithm) or that you present a biometric, such as a thumbprint.

### Time-based one-time password algorithm (TOTP)

A time-based one-time password algorithm or TOTP generates one short-lived (~30 seconds or less) password from a secret key in combination with a current timestamp. A [cryptographic hash function](https://www.lifewire.com/cryptographic-hash-function-2625832) connects these two.

The [Microsoft Authenticator](https://docs.microsoft.com/en-us/azure/multi-factor-authentication/end-user/microsoft-authenticator-app-how-to) is a common option that generates a TOTP:

![Microsoft Authenticator generates a time-based one-time password (TOTP)](https://images.ctfassets.net/23aumh6u8s0i/77LXTM6VFF3ZAkPcn7hvn/8e09b57c1939e64b314c6f96d16fd214/microsoft-authenticator-generates-a-totp.png)

Prior to logging into an app, users will go to Microsoft Authenticator, generate their code, and, before it expires, use it to log into the app. Other leaders in the space include the Google Authenticator, along with smaller providers like Twilio, Authy, Duo Mobile, and the LastPass Authenticator. These providers offer 2FA solutions for both mobile and desktop platforms.

### Biometrics

Biometrics have made big strides in recent years, including the launch of Apple’s iPhone X facial recognition feature. Widely used biometrics for identity verification include iris or retina recognition, facial, fingerprint, hand, and even DNA usage.

Many consumer financial apps, like TD Bank's app for basic checking, savings, and transfer options, employ the thumbprint as a second authenticator:

![TD Bank employs the thumbprint as a second authenticator.](https://images.ctfassets.net/23aumh6u8s0i/GPD4cX5JIXBjbCmuyhpzX/c66fe2fe191fdbc53cda4080eb774a18/td-bank-employs-thumbprint-for-2fa)

[Source: PhoneArena News](https://www.phonearena.com/news/How-to-use-your-fingerprint-scanner-to-log-in-websites-on-a-Samsung-smartphone_id73835)

Users are prompted to place their thumb on the home button for identification prior to entering the app. Several established firms, including [Vanguard](https://personal.vanguard.com/us/insights/article/mobile-touch-id-062016?lang=en) and other asset managers, have incorporated Touch ID as well as [voice verification](https://investor.vanguard.com/account-conveniences/voice-verification) for certain transactions.

<include src="TweetQuote" quoteText="Despite the proven ability of 2FA to reduce the threat of a security breach, the trick is getting users to opt in."/>

## The Challenge: Get Users to Opt In

Despite the proven ability of 2FA to reduce the threat of a security breach along with the ease of setup (no advanced security or developer skills are [required](https://auth0.com/learn/two-factor-authentication/)), 2FA has yet to become mainstream. It can be unclear for many users how to set up 2FA. For example, with services like [PayPal](https://www.paypal.com/us/selfhelp/article/how-do-i-enable-2fa-(two-factor-authentication)-for-my-paypal-powered-by-braintree-user-faq3500), users have to log into their control panel, navigate to their account, and enable 2FA with a QR code or another supported app:

![PayPal supports 2FA with mobile or security key cards](https://images.ctfassets.net/23aumh6u8s0i/wwNSq8sW8ky2GQE9uopOw/7b1d58cba76d2a661b1610ea4062d05b/paypal-supports-2fa-with-mobile-or-security-keys)

It can be difficult for a user without 2FA knowledge to know which option to choose — after already puzzling out how to get to this stage without clear directions in the first place. While some may opt for SMS (first option), the second option (TOTP) doesn't rely on incoming text messages and has proven to be more secure.

For financial firms looking to gain customer trust, making the 2FA setup simple (or figuring out a way to integrate it into their app's UX in a seamless way) will go a long way toward distinguishing themselves from the pack. Customers are particularly looking for a high level of security with their financial information. If you can clearly communicate your enhanced strategy, you will gain a competitive advantage.

<include src="TweetQuote" quoteText="Customer happiness and high engagement are the biggest determinants of its success."/>

### Discourage Password Use

One way to help users understand the importance of 2FA is to discourage the use of passwords alone. Passwords are historically vulnerable due to human error (we're often lazy about re-creating lengthy, secure, and unique passwords and instead recycle the same or iterations of the same password for the majority of accounts) and the ease with which hackers can access this first level of authentication. Explaining that breaches of personal information happen daily — due to phishing and additional criminal tactics that get the user to unknowingly reveal their password — can prompt your customers to consider an alternative. While a [password manager](https://www.pcmag.com/article2/0,2817,2407168,00.asp) is one option, 2FA brings another dimension to the security game altogether. If one or multiple passwords are compromised, a hacker still cannot access the account without acquiring the second factor.

### Balance UX and Practicality

In many cases, customer happiness with a new feature and a [high level of engagement](https://www.youtube.com/watch?v=30f_lVQBzYs) with it are the most important determinants of its success. With cybersecurity features, however, where do you draw the line between ease and enjoyment of use and practicality? Should something so critical be fun? Do users want to see the same types of design for 2FA integrations that they see with, say, e-commerce apps? You don't necessarily have to sacrifice a pleasant user experience due to the serious nature of a 2FA feature; at the same time, you should be conscious that 2FA is distinct in its functionality. Consider a design that is utilitarian, clear, and makes the user understand the power behind the tool.

The Google Authenticator, for example, balances clarity, capability, and a splash of color:

![Google Authenticator balances clarity, capability, and design](https://images.ctfassets.net/23aumh6u8s0i/7mg1gsfPl51QE6co76WWfv/80258abc625c467ee0ec0567048b85fa/google-authenticator-balances-clarity-capability-design)

[Source: GeekyGadgets blog](https://www.geeky-gadgets.com/google-authenticator-ios-app-update-removes-user-accounts-04-09-2013/)

Whichever authenticator tool you offer your users it should reflect your brand and focus. Further reading on the topic that we've found helpful includes:

1. [UX vs. Cybersecurity](https://medium.com/@4Barel/ux-vs-cybersecurity-3eedf77ed6e7)
2. [Cyber Security Requires an Important Ingredient: Strong UX](https://hackernoon.com/cyber-security-requires-an-important-ingredient-strong-ux-d0727a0c076)
3. [What is two-factor authentication, and which 2FA apps are best?](https://www.pcworld.com/article/3225913/security/what-is-two-factor-authentication-and-which-2fa-apps-are-best.html)

## Conclusion: Be There for Your Customers

Figuring out how to integrate 2FA into your consumer financial apps in ways that will make your customers opt-in and enjoy the process will give them peace of mind, help ensure your firm is [compliant](https://auth0.com/gdpr), and even allow you a competitive advantage in the race to gain user support and trust.

<include src="asides/AboutAuth0" />

How Two-Factor Authentication (2FA) Can Help Financial Institutions Reduce Data Breaches

685342d5e7f42c3ab8d251d7d4a53308?s=100&d=mm&r=g avatar

685342d5e7f42c3ab8d251d7d4a53308?s=100&d=mm&r=g

Former Auth0 Employee

Robin Percy

Using Ruby on Rails to combine Auth0 Login with Iris Recognition for Two Factor Authentication

Iris Recognition for Two Factor Authentication with Ruby on Rails

7747f8f5b58076f7bc52cc1bcc54bec5?s=200 avatar

7747f8f5b58076f7bc52cc1bcc54bec5?s=200

João is a software developer at heart that traded his IDE for the possibility to help fellow developers with their authentication and authorization challenges. When not at the computer you'll likely find him exercising his creativity in the kitchen.

Developer Support Engineer

João Angelo

Learn how to integrate voice recognition into your 2FA solution.

<div class="alert alert-info alert-icon">
 
 Forrester Consulting analysis determines that using Auth0 can yield a 548% ROI and $3.7M in identity-related savings. Read the full report: <a href="https://resources.auth0.com/forrester-tei-research-case-study/">Total Economic Impact of Auth0</a>.
</div>

---

**TL;DR** You can replace the use of traditional multifactor possession factors (phone codes, special-purpose hardware) in 2FA implementations with the use of inherence factors (voice biometrics) by leveraging [Auth0](https://auth0.com/) extensibility points and voice recognition services (VoiceIt). Additionally, by integrating a communications platform (Twilio) you can let your users complete the voice authentication step through their own phones.

___

## Traditional Two-Factor Authentication

The majority of existing [two-factor or multifactor authentication](https://auth0.com/multifactor-authentication) implementations rely on the users mobile phone to perform ownership-based checks.

These checks range from the use of codes delivered over SMS to push notifications or time-based one-time password (TOTP) applications. All the methods are a significant improvement over just username and password credentials and they are available to everyone that already has a phone; which is a huge audience.

Nonetheless, you can argue that these approaches are closer to a two-step authentication process rather than two-factor authentication because a users phone isn't really a possession factor at all. The ability to intercept SMS or knowledge of the cryptography keys used in association with TOTP or push notifications could allow an attacker to complete an authentication process without having to have the users phone.

Real possession factors like hardware-based tokens would increase security, but they are not as generally available or as a simple to use as a phone.

## Going Beyond Possession Factors

Inherence factors, usually referred to as biometrics, including fingerprint readers, retina scanners, or voice recognition can be used together with a knowledge factor like username and password credentials as suitable means to provide an effective 2FA solution.

Within the biometrics options, fingerprint readers and retina scanners are even less broadly available than the special purpose hardware-based tokens used as a possession factor. However, requirements for the voice recognition alternative are much less demanding. These requirements can be met with what's available right now to the majority of users, more specifically, audio capture and transmission services.

The support for audio capturing with the increased availability of voice recognition services available over HTTP-based APIs makes it really simple to implement a scenario like the one shown in the following demonstration.

The users provide their username and password credentials and then are asked to speak an authentication phrase that is processed for voice recognition in order to grant access to the client application that initiated the authentication process.

![Two-Factor Authentication Demonstration](https://images.ctfassets.net/23aumh6u8s0i/7mFEpBLBXR0CyaBSiYG5t7/afdfbf6ccde7e2cc607f4407d978ec95/authenticate-browser)

## Theory

Before going into the technicalities of the implementation lets take a look at the requirements for a user to complete voice-based authentication.

A user must first complete a voice enrollment process before being able to authenticate using their voice. This is a one-time process where the user repeatedly records an authentication phrase until the voice recognition service has enough information to later process authentication requests with the required amount of confidence.

Having completed the enrollment process the user's voice can now be used during authentication requests. The authentication process is similar to the enrollment, the users says the authentication phrase they used for enrollment and the voice recognition service will use the available data to verify it.

The following diagram illustrates the flow taken during the enrollment and authentication processes.

![Enrollment and Authentication Flows](https://images.ctfassets.net/23aumh6u8s0i/1YMjmDG1IBizW2BPrkIVl/ab634dc5994c048318d4cddef072e48b/enroll_authenticate_diagram)

## Putting Theory to Practice

Now that we know, at a high-level, what it takes to have a voice authentication system, lets see how can we integrate this into the authentication process of an existing application that uses username and password credentials.

We're going to leverage two Auth0 extensibility points in order to streamline the process. Specifically, we'll configure a redirect rule, that after the successful completion of the first authentication factor will send the user to another web application responsible for the second authentication factor; voice authentication.

The second extensibility point used will be the implementation of a web application as an Auth0 extension which will enable the following:

* Automatic provisioning of the configuration required to call the Auth0 Management API from within the web application.
* Automatic creation of the redirect rule upon extension installation.
* Remove the need for a separate infrastructure to run the web application.

The last piece of the puzzle is the integration with a voice recognition service, which as long as the service exposes an HTTP-based API is also rather simple to accomplish. This happens to be the case for [VoiceIt](https://www.voiceit-tech.com/), the service used in this demo. VoiceIt requires the concept of a user, for which a voice enrollment has to be completed before voice authentication requests can be made.

Finally, it's a matter of putting the pieces together. Most of the code is boilerplate for integration of all the players. The most noteworthy parts that warrant a dedicated look are the ones referring to the transition between the different trust domains and how to ensure the security of these transitions, more specifically:

* Transitioning from the Auth0 authentication transaction to the voice application.
* Transitioning from the voice application back to the corresponding Auth0 authentication transaction.

Both transitions require the secure transmission of information between the two parties. A possible approach to accomplishing this is to use a signed JWT token, as this will provide both a way to encode information that can be easily included in a URL while at the same time ensuring that a malicious user cannot tamper with the information.

Given the reliance on a redirect rule and the fact that the token will need to be included in the URL itself, it's probably for the best if that token has a short expiry time and is also of single-use. The following implementation facilitates the single-use check by including a `jti` claim that can be used by the receiving application as means to ensure that it only accepts a given instance of the token once. Values of the `jti` claim for already used tokens are stored and validation of received tokens include a check against the already used identifiers.

```javascript
user.user_metadata = user.user_metadata || {};
var phoneNumber = user.phone_number || user.user_metadata.phone_number;

// Redirect the user to the extension
var claims = {
 sub: user.user_id,
 name: user.name,
 phone_number: phoneNumber,
 jti: crypto.randomBytes(16).toString("hex"),
 vit_id: user.app_metadata.vit_enrollment.id,
 vit_secret: user.app_metadata.vit_enrollment.secret,
 vit_lang: user.app_metadata.vit_enrollment.language,
 vit_enrolled: user.app_metadata.vit_enrollment.completed
};

var token = jwt.sign(claims, config.signingKey, { expiresIn: 60 });

context.redirect = { url: config.extensionUrl + "?token=" + token };

callback(null, user, context);
```

When the user completes voice authentication, either successfully or not, the second transition occurs and the information is returned back to Auth0. Transmission of this information relies again on a signed JWT token so that tampering can be prevented, however, token replay mitigation is now handled a bit differently.

During the first transmission, besides the token that the rule manualy included in the URL, Auth0 will automatically include a state parameter with a value that uniquely identifies the authentication transaction that is in progress; this same value needs to be returned to Auth0 when continuing the transaction. It's then possible to use the value of the state parameter as the value of a `nonce` claim within the token used during the second transaction as a way to ensure that a given token can only be used to continue a single authentication transaction.

```javascript
var token = context.request.query.token;
var state = context.request.query.state;

try {
 var payload = jwt.verify(token, config.signingKey, {
 algorithms: ["HS256"]
 });

 if (payload.sub !== user.user_id) {
 return callback(new UnauthorizedError("User mismatch."));
 }

 if (!payload.vit_authenticated) {
 return callback(new UnauthorizedError("User failed authentication."));
 }

 if (payload.nonce !== state) {
 return callback(new UnauthorizedError("Session and token mismatch."));
 }

 return callback(null, user, context);
} catch (error) {
 console.log(error);

 return callback(new UnauthorizedError("Unexpected failure."));
}
```

## Improving the UX

Authenticating the user using the computer's microphone is adequate for demonstration purposes or in enterprise environments.

For consumer facing services considering voice authentication, it's more difficult to make assumptions about what's available to the end-user. Adopting alternatives that impose fewer requirements and are overall simpler to use gives them a clear advantage. This is where [Twilio](https://www.twilio.com/) shines as it allows us to implement a full-blown voice authentication solution over the phone in no time.

### Leveraging Twilio for Phone-Based Voice Authentication

Much in the same way that current 2FA methods gained adoption by leveraging the broad availability of mobile phones you can do the same to streamline a voice authentication process.

By integrating the [Twilio](https://www.twilio.com/) communications platform, it's possible to automatically call the user when an authentication request comes in, ask them to provide their associated authentication phrase, record it and send it for verification.

For the user, the similarity to existing solutions that use the phone as a possession factor simplifies the users' transition from one approach to the other. Despite the reliance on phones, there is no strict association to a specific device. This allows the user to switch devices without having to worry about resetting existing multifactor authentication enrollments. The phone is only used as a way to obtain the actual authentication factor; the user's voice.

When the outgoing call is established, you need to associate it with the existing authentication session from the web application. You achieve this by including a token that maps to the correct session within the URL used to initiate the call. Mapping this to the Twilio API, you would use the following code:

```javascript
var client = twilio(accountSid, authToken);

client.calls.create({
 url: `/api/phone/receive-call/${token}`,
 to: userPhoneNumber,
 from: twilioOutgoingPhoneNumber
}, function (error, call) { /* (...) */ });
```

Then, on the handler for the `/api/phone/receive-call/:token` route you take advantage of the fact that you can set a single cookie in the HTTP response to a Twilio initiated request and then this cookie will be sent by Twilio on subsequent requests associated with the same combination of *To* and *From* numbers. Check the Twilio documentation to learn more about [how cookies work](https://support.twilio.com/hc/en-us/articles/223136287-How-do-Twilio-cookies-work-).

```javascript
// (...) Validate the received token

var twiml = new twilio.TwimlResponse();

twiml.say("You have initiated a Voice Authentication process.");

// Set a cookie to link the authentication session with the call
res.cookie("tw_cid", cid, { httpOnly: true, secure: true });

res.send(twiml.toString());
```

The end result, as shown next, is that the user interaction moves from the web application to the phone and the user can complete the request simply by answering a call and following the instructions.

![Two-Factor Authentication by Phone Demonstration](https://images.ctfassets.net/23aumh6u8s0i/66p7DVAsRzVJEEPlbOABjv/1a0ca393c4ab88c2de837e14fd5b3610/authenticate-phone)

## Real-Time Call Progress Updates

Even though the authentication process now transitions from the web application into a call delivered to the users phone, the browser window for the application will need to stay open because the actual completion of the authentication process will have to be completed using it.

The continuation of the process in the web application can and should be done automatically when the call completes. A simple mechanism to accomplish this would be for the client browser-based application to poll the server-side backend that is managing the call. However, this would be inefficient and at the same time introduce artificial delays in the process.

A better alternative is for the server-side to continuously push state changes to the client application in real-time. Even though it sounds more complex than the previous alternative you can easily achieve this by integrating a service like [Pusher](https://pusher.com/).

![Two-Factor Authentication by Phone with Real-Time Progress Updates Demonstration](https://images.ctfassets.net/23aumh6u8s0i/5GIVB97hJza6FyJOMuWy0y/69cb1e65644ae89d744cb8653a011261/authenticate-phone-with-progress)

In order to accomplish the previously illustrated functionality, on the server-side, you initialize a Pusher instance and then continuously push updates when certain call-related events occur:

```javascript
var pusher = new Pusher({
 appId: appId,
 cluster: cluster,
 key: key,
 secret: secret,
 encrypted: true
});

// (...)
pusher.trigger(`callprogress-${call.cpid}`, "update", { "step": 2, "seq": seq++ });

// (...)
pusher.trigger(`callprogress-${call.cpid}`, "update", { "step": 3, "seq": seq++ });
```

On the client-side you subscribe to the event stream and react accordingly. The only thing worth mentioning is that the server sends a sequence number with each update in order to allow the client to correctly process the progress updates even if the network fails to deliver them in order.

```javascript
var pusher = new Pusher(key, {
 cluster: cluster,
 encrypted: true
});

var channel = pusher.subscribe("callprogress-" + cpid);

channel.bind("update", function() { /* (...) */ });
```

## Test-Drive

All of the source code used as the basis for this article is available at: [Auth0 Voice Factor Extension](https://github.com/auth0/auth0-extension-voice-factor) repository. The easiest way for you to get started with it is to install it as an extension within your own [Auth0 account](https://auth0.com/); just follow the instructions contained in the repository [*README*](https://github.com/auth0/auth0-extension-voice-factor#install-as-auth0-extension) file.

If you don't yet have an Auth0 account don't worry, **you can <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up</a> for a free account today**. Besides the Auth0 account, a fully functional deployment also requires a [VoiceIt](https://www.voiceit-tech.com/) account used for processing all the voice enrollment and authentication requests.

> [Auth0 offers a generous **free tier**](https://auth0.com/pricing) to get started with modern authentication.

Additionally, you can provide a [Twilio](https://www.twilio.com/) account if you want to enable the completion of the voice authentication requests through phone calls and a [Pusher](https://pusher.com/) account if you want to receive real-time progress information for those same calls.

# Conclusion

Biometric authentication may still be far from mainstream adoption and may even be overkill for most applications out there. However, this article shows that by leveraging Auth0 extensibility points coupled with a third-party voice authentication service, it's very simple to add an additional layer of security for applications that demand an additional level of security.

Another benefit of biometrics as second authentication factor is that it's less of a burden for end-users. No one likes the hassle of buying a new phone and getting locked out of online accounts due to multifactor authentication enrollments associated with the old phone that you may or may not have anymore.

## Aside: Securing Applications with Auth0

Are you building a [B2C](https://auth0.com/b2c-customer-identity-management), [B2B](https://auth0.com/b2b-enterprise-identity-management), or [B2E](https://auth0.com/b2e-identity-management-for-employees) tool? Auth0, can help you focus on what matters the most to you, the special features of your product. [Auth0](https://auth0.com/) can improve your product's security with state-of-the-art features like [passwordless](https://auth0.com/passwordless), [breached password surveillance](https://auth0.com/breached-passwords), and [multifactor authentication](https://auth0.com/multifactor-authentication).

[We offer a generous **free tier**](https://auth0.com/pricing) so you can get started with modern authentication.

Two-Factor Authentication Using Biometrics

001c9ddc5ceb9829b6aaf24f5d28502a

I am software developer with a keen interest in open-source technologies, Linux, and native development. I've worked on many different platforms Android, iOS, Win32, Linux, FreeRTOS, the Web, and others. I've gone through the whole stack and I enjoy learning and using the latest technologies. I now work as a full-stack developer at Auth0.

Senior Engineer

Sebastian Peyrott

Learn how to easily add 2FA/MFA to your Node.js + Express.js apps using TOTP

-----

Authentication has increasingly become an important part of all web applications and sites. Long gone are the days of applications that simply performed an action without getting any details about the identity of the user who performed the actions. In this post, we will explore one of the most powerful (and easiest) ways of improving the security of your authentication process: two-factor authentication (2FA / MFA).

-----

## Two-factor authentication
2FA has become quite popular. As you may have guessed, it works by providing an additional layer of authentication that is independent of the main layer. Most applications make use of the usual username + password combination, though any two independent authentication methods may be combined. In the following paragraphs, we will explore one authentication method that has become popular for use as the second step in 2FA: the time-based one-time password algorithm (TOTP).

## Time-based one-time password algorithm
TOTP is defined in [RFC 6238](https://tools.ietf.org/html/rfc6238). It is free and simple. There are many open-source implementations for both the client-side and server-side components. In particular, Google has developed an application that is freely available for Android, iOS and the web: Google Authenticator. This application allows us to integrate TOTP easily into our developments. We will explore how to do so in the following sections, but first I'll give you a quick summary of TOTP and how it usually works in two steps:

1. **Enrollment:** enabling 2FA for a specific user.
2. **Login:** using 2FA to log in.

![Typical 2FA flowchart](https://images.ctfassets.net/23aumh6u8s0i/33T9WITUHdahRvXb4ynlQq/69bb42ab3847e6f6fcc9396d9eee5359/Flowchart.png "Typical 2FA flowchart")

As you may have gathered from the chart above, the main requirement for TOTP to work is a **shared secret**. This shared secret needs to be generated and then stored by both the client- and the server-side components of the system. This usually means that an "enrollment" step is necessary before making TOTP available in an application.

Another important thing to keep in mind, as the name of the algorithm implies, the generated codes are time-dependent. The **client and the server need to synchronize their clocks**, and the codes become invalid after a certain amount of time.

## Adding TOTP to your Node.js application
As you have seen in the previous chart, adding 2FA with TOTP to an application requires two independent steps. In our example, the second step (the actual authentication) will be handled by passport-totp, a passport.js strategy that validates the user-entered TOTP code and requires access to the user-specific key. We will also require users to install Google Authenticator (or a similar app) to generate codes with their cellphone. A user may also choose to use the Google Authenticator Chrome app.

You can find all the code from the following snippets here: [app.js](https://github.com/sebadoom/auth0/blob/master/twofa/backend/app.js)

### Step one: enrollment
In our example, the first step will be handled manually by us. We will add code to generate a new random key and store it along with other user authentication information.

After the usual passport.js and express.js setup, we add the necessary TotpStrategy:

```javascript
passport.use(new TotpStrategy(
 function(user, done) {
 // The user object carries all user related information, including
 // the shared-secret (key) and password.
 var key = user.key;
 if(!key) {
 return done(new Error('No key'));
 } else {
 return done(null, base32.decode(key), 30); //30 = valid key period
 }
 })
);
```

As usual, passport will call this callback with the actual 'user' object as deserialized from the request. The 'user' object contains a 'key' string that may be null. If the key is null, we will consider TOTP disabled and allow logins with just a username and password. If the key is present, we will require an additional input from the user before proceeding with the login. The key must be provided to passport as a byte array, but for convenience (and because Google Authenticator requires so), we store it as a BASE32 encoded string. The 'period' is the amount of time a single TOTP code is valid from the moment it is requested to the moment it is entered.

The enrollment step requires the user to be already logged in (as this is necessary to enable or disable TOTP in the server for each specific account). If the user chooses to enable TOTP, we present the shared secret as a QR code ready to scan and save in Google Authenticator:

```javascript
app.get('/totp-setup',
 isLoggedIn,
 ensureTotp,
 function(req, res) {
 var url = null;
 if(req.user.key) {
 var qrData = sprintf('otpauth://totp/%s?secret=%s',
 req.user.username, req.user.key);
 url = "https://chart.googleapis.com/chart?chs=166x166&chld=L|0&cht=qr&chl=" +
 qrData;
 }

 res.render('totp-setup', {
 strings: strings,
 user: req.user,
 qrUrl: url
 });
 }
);

app.post('/totp-setup',
 isLoggedIn,
 ensureTotp,
 function(req, res) {
 if(req.body.totp) {
 req.session.method = 'totp';

 var secret = base32.encode(crypto.randomBytes(16));
 //Discard equal signs (part of base32,
 //not required by Google Authenticator)
 //Base32 encoding is required by Google Authenticator.
 //Other applications
 //may place other restrictions on the shared key format.
 secret = secret.toString().replace(/=/g, '');
 req.user.key = secret;
 } else {
 req.session.method = 'plain';

 req.user.key = null;
 }

 res.redirect('/totp-setup');
 }
);
```

If the user chooses to enable TOTP, we generate a new secret key randomly. Then we encode it in BASE32 format for easy storage and to show it to the user. The 'ensureTotp' middleware makes sure that if 2FA is enabled, then the user has logged in using a TOTP code (see below for the implementation).

### Step two: a new authentication step
Once 2FA is enabled, logins will now have two steps: a username and password will be required as usual, and then, a six-digit code will be input, which the user will need to get from Google Authenticator every time he or she wants to login. So, we will add the necessary code to perform the login and allow the user to enter the code after the first step is complete.

#### Logins are now performed in two steps if the user has 2FA enabled

```javascript
app.post('/login',
 passport.authenticate('local', { failureRedirect: '/login' }),
 function(req, res) {
 if(req.user.key) {
 req.session.method = 'totp';
 res.redirect('/totp-input');
 } else {
 req.session.method = 'plain';
 res.redirect('/totp-setup');
 }
 }
);
```

After the usual username + password authentication, we check whether a TOTP code is required. If so, we redirect the user to the "totp-input" page. Otherwise we send him or her to the usual place after logging in (in this case, for simplicity, we just keep a totp-setup page as the landing page after a successful login). Keep in mind that all places that require authentication need to check for both the standard login and the TOTP login (which is optional) for this to be secure. For instance:

```javascript
app.get('/totp-setup',
 isLoggedIn,
 ensureTotp,
 function(req, res) {
 var url = null;
 if(req.user.key) {
 var qrData = sprintf('otpauth://totp/%s?secret=%s',
 req.user.username, req.user.key);
 url = "https://chart.googleapis.com/chart?chs=166x166&chld=L|0&cht=qr&chl=" +
 qrData;
 }

 res.render('totp-setup', {
 strings: strings,
 user: req.user,
 qrUrl: url
 });
 }
);
```

And here are the implementations of the middleware elements that perform the check:

```javascript
function isLoggedIn(req, res, next) {
 if(req.isAuthenticated()) {
 next();
 } else {
 res.redirect('/login');
 }
}

function ensureTotp(req, res, next) {
 if((req.user.key && req.session.method == 'totp') ||
 (!req.user.key && req.session.method == 'plain')) {
 next();
 } else {
 res.redirect('/login');
 }
}
```

As you can see, for the TOTP check, we make use of a helper variable ('method') inside the session. Session information is stored on the server, so this is safe to do. The client just keeps a session ID. This extra session variable is set in the login handler (POST), which we have shown above.

## Is this production ready?
In the previous paragraphs we covered the basics of 2FA. Here's what you need to keep in mind when going into production:

- **Phone or device unavailable:** Consider what happens when users lose access to their code-generating device or application (or shared-secret). Provide a means for users to recover access to their account without compromising security (email links, SMS messages, etc.).
- **Reset 2FA from backend:** Depending on your use case, it may be necessary to add the means to disable or reset 2FA data directly from the backend. Usually, this is accomplished by requiring the user to perform the enrollment step one more time after login.
- **Fallback for people who don't have smartphones:** If a user chooses not to use a smartphone, any of the recovery methods may be enabled indefinitely.
- **Audit and notify users of changes:** Provide convenient ways for users to see if the authentication details (or methods) have been changed or enabled in their accounts. This allows for early detection of suspicious activity. Automated emails are a good choice.
- **Encrypt shared secrets**: Per [RFC 6238](https://tools.ietf.org/html/rfc6238#section-5), you should store shared-secrets using a cryptographically secure reversible algorithm and keep the keys in memory only as long as necessary. Do not reinvent the wheel; use existing and well-tested libraries for this.

<include src="TweetQuote" quoteText="Shared secrets should be stored using a cryptographically secure reversible algorithm"/>

## Conclusion
We showed in this blog post how easy it is to get started with 2FA using TOTP. It does not require a lot of infrastructure. Google Authenticator, Microsoft Authenticator, Authy and other TOTP applications are available in multiple platforms which makes adoption easy. But don't forget to take into account the non-happy-path: people reset their phone, it gets lost or stolen, or sometimes they don't even have one.

For simplicity, the code in our example uses a simple JSON file as storage. In production you would normally keep user data in a proper (and secure) database. Get the code: [app.js](https://github.com/sebadoom/auth0/blob/master/twofa/backend/app.js).

## Aside: How it works in Auth0
Auth0 provides convenient [2FA](https://auth0.com/learn/multifactor-authentication) methods that can easily be enabled. Check this out:

![Auth0 2FA](https://images.ctfassets.net/23aumh6u8s0i/wahzDruzjVuI0zcaeFPEq/d40a1eee5aec4843c87524ce82ea5d97/mfa.png "Easy 2FA with Auth0")

- **A Switch Away:** 2FA is enabled with just a toggle. No changes are required to your application.
- **Multiple TOTP Clients:** Auth0 works with various client-side TOTP-generating apps: Google Authenticator, Microsoft Authenticator, Authy, etc.
- **Contextual and Programmable 2FA:** Contextual 2FA: enforce 2FA for users according to your own scripted rules.

Check the [docs](https://auth0.com/docs/mfa) and the [multi factor authentication page](https://auth0.com/learn/multifactor-authentication).

"2FA"