We're all doing MFA wrong

Multi-factor authentication, or MFA, was introduced sometime in the mid-late 1980s, and was initially aimed at the defense industry. It was originally referred to as 2FA, or two factor authentication.

Over the past 20 years, we’ve seen adoption pick up, and many popular applications and web-based services now support, or even mandate, use of a second factor when logging in, or accessing sensitive data. Also over the past many years, we’ve seen methods for authentication evolve.

Who remembers these things? That’s right, the SecurID!

The original security tokens functioned very similarly to how authenticator apps work today. There’s a predetermined “seed” that’s shared between the client token and the server. This seed is used in conjunction with the time, to produce a number (commonly six digits) that rotates approximately every 60 seconds.

That’s simple enough. But as the need for two factor authentication grew, companies, especially B2C companies, couldn’t afford to buy and support these expensive and physical security tokens. They needed something that everyone could get themselves, or ideally, something everyone already had.

Cell phones!

Ah yes, cell phones were popular, and everyone wanted to text instead of talk anyway. Why not just hookup your authentication server to the cell network? Well, in the mid-late 2000s, this wasn’t the worst idea. Smartphones weren’t nearly as ubiquitous then as they are today. But over the next several years, society started to learn the hard way just how easy it was to intercept or redirect text messages. SS7’s security issues, and stories of retail phone shops being able to “sim swap” without any authentication hadn’t made it to the mainstream news yet.

As time went on, the public started to realize that SMS MFA wasn’t overly secure. Conveniently, smartphones started to land in everyone’s pockets, and “apps” became popular. Naturally, 2FA codes had to evolve, and we started to see apps with push notifications enter the market. Services, like Duo, didn’t even require that users receive a code and type it back into the login system. All you had to do was log in normally, and then tap the “approve” button that popped up on your phone’s screen. How easy is that!

But these systems, too, had issues. Aside from an external party hosting your user authentication service, “MFA bombing” started to become common. If a user gets flooded with MFA notifications in the middle of a legitimate login attempt, it’s difficult to know which one of the notifications to approve. Sure, there are ways to counter this, but essentially that didn’t happen.

There’s more to cover, but I’d like to point out that for many companies, this is where the MFA evolution has stopped. Organizations of all sizes still occasionally have to deal with MFA bombs. But thankfully, many managed to keep up with more modern trends.

All that’s old is new again…

In more recent years, the pendulum has swung back. We’ve started to see things that resemble those old SecurIDs. Apps like Authy have taken the algorithm (seed, time) functionality of the SecurID, and moved it to an app on your phone. Hardware keys, like Yubikey, have taken an approach that closely resembles that of a smartcard. Either way, both work in an offline fashion. There’s no SMS that can be intercepted, and there’s no MFA bombing. Sounds great, right?

While the math on these generally looks good, many are still struggling with sound implementation practices.

Think about how you login to your favorite MFA protected services today. If you’re like many, you probably enter your username and password first. If those pass, then you’re prompted for your MFA.

You had a valid username, password, and MFA. So what’s the problem?

It has to do with the order in which your credentials were verified. Usernames and passwords both tend to be fairly static. (Yes, you can change your password, but it’s not practical to do so often enough to counter an active brute force attack with modern hardware.) Picture a scenario where your username is known – maybe it’s your email address, and your password eventually gets brute forced successfully. Attackers now have two of three components that make up your credentials, and they’re validated to be correct. The only thing standing in their way from accessing your account, and any associated data, is guessing a six digit number that rotates every 30-90 seconds. How fast do you think a modern computer can guess that? It’s certainly less than 30 seconds!

This type of attack happened just last year. And of anyone that attackers could go after, they tried breaking into Apple accounts.

How do we make this better?

At a minimum, authentication owners should reverse the login process, putting the username and TOTP (rotating number from your authentication app, or security key) first, and if both of those pass, then prompt for the user’s static password. The TOTP will still likely be crackable, but by putting this first, it will reduce the amount of contiguous time for attackers to attempt to brute force the static password, before the TOTP expires. This gives system owners, and their users, more time to detect the anomalous authentication attempts, and hopefully respond.

How do we make this better than better?

It’s simple, ask the user for everything at once. Even if a username is known, an attacker would have to successfully guess both the correct password, and the correct TOTP, and do so all on the same attempt. The likelihood of this being successful is quite low, especially when you remember that the TOTP rotates frequently.

Let’s top this off!

There are a few extremely mature organizations that are already asking for all three components of a user’s credential at once. But there is one additional thing you can do, if you really want to make your login systems secure. Configure a “cool down period”. Only allow a user’s account to attempt one login every so many seconds. Hypothetically, if you made your cool down period 90 seconds (which feels long), any TOTP would expire by the next time the attacker attempts to brute force the credentials. This makes the odds of an attacker fraudulently accessing an account nearly zero! (And if you want to take it too far, you could also require a CAPTCHA to be completed for each login attempt, but that’s just rude.)

Ultimately, if you follow this advice, attackers may still be able to find a way into your systems, but it won’t be through the front door!