MFA v2.0: Using Context to Improve Multi-Factor Authentication
Tags: security
Published: 2020-07-07 23:27:00

The need for improved MFA and two-step verification has been on my mind since January 2020. On June 17, 2020, Google sent me an email notifying me they are improving their two-step verification process. To me, this emphasizes my initial concerns about MFA and the need for improvement when it comes to multi-factor authentication.

Google, in their email, stated the following:

> Google is improving 2-Step Verification so you can use Google prompts to sign in securely and better protect your account.

> Prompts are push notifications that are sent securely to your phone. Because they don’t use SMS, they’re safe from emerging SMS-based threats.

> Google sign-in prompts will be able to reach every eligible phone where you’re signed in after July 7, 2020. In most cases, other 2-Step Verification options will continue to work as backup second steps.

I was excited to see this email.

In this post, I will share my thoughts on why the entire software industry should consider improving their two-factor/two-step/multi-factor authentication.

## What is 2FA, Two-Step & Multi-Factor Authentication (MFA)?

All these terms are related. They encompass the idea of not solely relying on usernames and passwords to prove that the authentication is valid. With so many data breaches and passwords being sold in the Dark Web, we can no longer rely on usernames and passwords as secure. We, therefore, need another mechanism to prove the authenticity of the authentication.

We can use one of three items: what you know, what you are, and what you have. For example, after you successfully enter the correct username and password, you must then enter a unique numeric code. This code is valid only for a short time window. You get it by using either a physical device, a virtual device or an SMS that is registered to your account. Having a time-based, unique, and additional verification step is meant to secure your login because (in theory) only you should have access to that code.

As we have seen with SMS-based attacks and other spoofing attacks, the current state of MFA needs improvement.

## What Is Wrong With The Current State of MFA?

The current state of MFA has provided a lot of protection since it was first introduced., but malicious actors have gotten smarter and have found deficiencies in MFA.

Here are some ways MFA can fail:

- A malicious actor can intercept SMS with SIM swapping attacks.
- A malicious actor can spoof a security alert push notification.
- A machine can try a million codes within seconds for a six-digit code.

There are many others, but I wanted to list a few to illustrate the point.

I argue that current MFA is missing a context, i.e., why has the request been made?

## Why does MFA need a context (i.e., “why”)?

Have you ever received an unsolicited Google two-step code? Or found an unread SMS with one of these codes?

```
G-313234 is your Google verification code.
```

I think, “Why did I get this?” or, “What is someone trying to do with my account?”

My natural response has to be, “I guess I need to change all my passwords just to be safe?”

What if the SMS/push message provided context.

```
You are trying to login. Your Google verification code is G-313234.
```

Or.

```
You're trying to change your password. Your Google verification code is G-313234.
```

Or an even scarier situation.

```
You're trying to recover your password. Your Google verification code is G-313234.
```

Now we know exactly why we received the message.

Some providers, like Okta, do an outstanding job of providing context in MFA. The rest of the industry should start doing the same.

If you are like me, you probably have multiple Google-based email accounts. We should consider adding more context like the target account.

```
some.email@example.com is trying to login. Your Google verification code is G-313234.
```

What if the context told you the location?

```
some.email@example.com is trying to login from Neverland. Your Google verification code is G-313234.
```

Wait! I don’t live near Neverland, nor does my ISP. I better take some action!

What if the MFA context gave us a follow-up about what happened?

```
some.email@example.com failed to login with Google two-step verification.
```

We will know if it failed or was successful if we look at an unsolicited push/SMS MFA request. If it was successful, we should immediately take some corrective actions. What if the MFA prompt allowed us to undo the request.

```
some.email@example.com succesfully changed the password on Google.com. Click/text "lock account" if you did not make this change.
```

The MFA request should also include these options before the action is taken. MFA is excellent but, to better secure it, we should consider adding some context to the equation.

## What Type Of Context Should We Consider Adding?

I propose we follow the great examples that providers, like Okta and Google, are doing in their MFA.

- Codes should be at least 12 characters and be alphanumeric.
- MFA should include email or username, the purpose for the request, IP address or physical location, number of attempts, and any other context information relevant to the account.
- The ability to approve and deny the request before it is taken.
- Follow-up on the result of the MFA request and the ability to deny the action or lock the account after the request was successful.

Here is an example workflow for a popular brokerage trading site like Robinhood.

1. The user enrolls in two-step verification.
1. The user opts into context-based verification.
1. The user tries to buy a stock.
1. The user is asked to enter a username and password.
1. The user receives an MFA code via SMS/push that includes the username, location, the purpose “buying AAPL stock,” and a reply with STOP or click STOP to cancel the request.
1. The successfully enters the code or clicks “Allow” in the push notification.
1. The user clicks buy.
1. The user receives an SMS/push that includes the username, location, the purpose “bought 4 shares of AAPL,” and a reply with UNDO or clicking UNDO to cancel the request. (Optionally, include a reply with LOCK ACCOUNT or click LOCK ACCOUNT response.)

The user is kept informed about the request and the outcome with context, which is crucial if that person did not initiate those actions.

## Conclusion

The introduction of multi-factor authentication (MFA) and two-step verification has significantly improved our online accounts’ security. Unfortunately, malicious actors are crafty and found ways to circumvent them. The software industry should take measures to improve the current state of MFA by adding context to the prompts and stay one step ahead of the bad guys before they figure out something craftier.

### A Note from the Author

Join my mailing list to receive updates about my writing.

Visit  [**miguelacallesmba.com/subscribe**](https://miguelacallesmba.com/subscribe) and sign up.

Stay secure,<br>Miguel

#### About the Author

Miguel is a Principal Security Engineer and is the author of the " [Serverless Security](https://ServerlessSecurityBook.com) " book. He has worked on multiple serverless projects as a developer and security engineer, contributed to open-source serverless projects, and worked on large military systems in various engineering roles.

<hr>

I originally published this article at [Secjuice.com](https://www.secjuice.com/mfa-v2-0-improving-the-state-of-multifactor-authentication/).