I have run across many "MFA" implementations that are only providing a false sense of security because they aren't actually MFA at all. After the most recent one, which had to do with income and financial documents I decided to write up a blog post so that I can share it with people to help them understand. Even though I am writing this to help people fix bad MFA implementation, hopefully at least a few readers will find this useful to set up MFA properly in the first place.
First, what is MFA? MFA stands for multi-factor authentication. The consensus is that there are only three possible factors that you can work with, so you MFA means that you MUST use at least two of these factors to access whatever it is that you are attempting to access. The three possible factors are:
- Something you know (like a password)
- Something you have (a physical item like a security key card, a company laptop, a specific cell phone, etc)
- Something you are (biometrics like fingerprints, voiceprint, retinal scan, etc)
We've all seen in movies where someone has to use both a key card and a hand scanner to enter an area... that's MFA. A password followed by a voiceprint, also MFA. A password then authentication using an app on your phone, that's MFA.
The problem, where most people mess it up, is the "MUST" in the definition. Often "MFA" (when I put that in quotes it is the false sense of security and not truly MFA)... often "MFA" is set up to require a password and then has an option for the second factor to be an email, a text, or an authenticator app. Seems fine on the surface but let's look closer at how people actually use email, texts, and cell phones (authenticator apps)... Here's an example scenario:
- A bad actor lifts a cell phone off the table at a local coffee shop while its owner is up getting their latte. The owner didn't bother to lock the phone (which is why it was an ideal target for this bad actor) so as long as the thief keeps touching the screen every couple minutes it will never lock.
- The thief scrolls through the email on the cell phone and finds a link to an financial website (that is supposedly protected by MFA).
- The thief goes to the portal and finds that the username is an email address, so they use the email address of the account on the phone and select the "forgot password" link.
- Ding! The phone gets a reset password email from the portal website. The thief resets the password and attempts to log in.
- The thief is now presented with the "MFA" prompt, would they like to authenticate with:
- An Email message
- A text message
- An authenticator app
- The thief chooses "an email message" because they know that they have the email account, though likely a text message would come right to this phone and also likely the authenticator would as well.
- Ding! The thief gets the email for "MFA" and logs into the financial site.
- The thief proceeds to buy a bunch of cryptocurrency with the victims money and the disperse that into their laundering crypto-wallets.
This scenario works no matter how the victim's email account is compromised. The scenario shows that there is only 1 factor, the user's email account. Everything else is window dressing to give a false sense of security. I see this repeated over, and over, and over.
In this scenario, simply having the user's logon name not be the email address AND blocking storage of that logon name in the browser might have prevented the theft. I say "might" because the major underlying problem is using the primary email account as a recovery method. If the attacker were able to click a "forgot username" link and get the username sent to that primary email address, they are still able to pull off the attack.
The fix is pretty simple... allow the option for a "recovery email address" that is separate from the email address used for normal correspondence. Sure, many users will not avail themselves of the option, but that is on the user and not on you as the provider of the MFA system.
Also, not all authenticator apps are equal. Only allow ones that require a second factor (preferably biometric, like fingerprint scan on the smartphone) before it will present the code/authentication item.
As of the time of this writing:
- Apple Passwords has an option to require a fingerprint, PIN or password when you open the app or approve a notification and it is on by default on iDevices.
- Google Authenticator has an option to require a fingerprint, PIN or password when you open the app or approve a notification and it is on by default on Android devices.
- Microsoft Authenticator has an option to require a fingerprint, PIN or password when you open the app or approve a notification.
- Okta Verify does not have an option to require a fingerprint, PIN or password before displaying the authentication code. So, the scenario above would work just fine for the attacker if the authenticator app was SecurID.
- SecurID does not have an option to require a fingerprint, PIN or password before displaying the authentication code. So, the scenario above would work just fine for the attacker if the authenticator app was SecurID.
- Symantec VIP Access does not have an option to require a fingerprint, PIN or password before displaying the authentication code. So, the scenario above would work just fine for the attacker if the authenticator app was SecurID.
So, yeah, the scenario could have been thwarted if an authenticator were required, provided it was one of the big three providers, AND, big and here... the account recovery email address was different than the correspondence email address. If the account recovery (not just password recovery. but account recovery) is on that primary email address then the attacker clicks the "recover my account", gets the email, and resets the MFA to either turn it off or uses their own phone to create a new one. So again, the major underlying problem is using the primary email account as a recovery method. In order to provide security to your clients you must give them the option to set a different email account as the recovery account.
So... what should your secure MFA solution look like?
- The user should be able to set up a second email account for any/all recovery options. This is the most common mistake that I see made across "MFA" solutions.
- The user should choose an MFA solution (text/email/app/etc) at the time of their account setup and the other options should not be available during normal logon. Either use the one that was set up or use a recovery option. This is the second most common mistake that I see; what is the point of me setting up an authenticator app if you are still going to offer the would-be attacker the option of getting an SMS text or an email?
- A secure authenticator app (one that allows for that 2 factor on the phone) should be highly recommended during account setup.
- Email address should not be used as a username (not precisely an MFA item, but a basic security principle).
- Changing both the correspondence and recovery email addresses should be possible by the user. Yes, I have actually seen quite a few sites that do not allow you to change your email address. Usually the same ones that are using that email address as the logon.
- Require re-validation of the MFA (check their credentials again) to display/change the recovery address.
If you get those six things right then I'm pretty sure everything else will fall into place and you will have an actual MFA solution, not a "email is the only factor" solution.
