This article flies in the face of general consensus. As you're here, you either share this view or you're questioning my sanity and/or logic.

Adoption Rates

Ultimately, the success of any new technology hinges on the end-user.

Trouble is, 2FA isn't new... we've used it in various contexts since the 1960s. An ATM machine for example, requires your PIN (something you know) and your card (something you have).

When it comes to web-based authentication however, I'd argue it's actually an unmitigated failure. Although an increasing number of service providers offer 2FA support, the end-user adoption rate is still woefully low. Google (who by the way, use 2SV or "two step verification") are tight-lipped about how many users have actually enabled 2SV, but estimates range from 2-5%.

In other words, roughly 95% of end-users are either unaware of 2FA or actively choose not to use it.

The Risks

The often-overlooked and crucial risk, is that it actually weakens security for the 95% that either opt-out, or don't opt-in.

But how?

Hackers use 2FA to prevent you accessing your own accounts!

Ironic isn't it; designed with the sole intention of ensuring your accounts remain private, only to be leveraged by the very people we're trying to defeat.

Convenience, but at what cost?

Put simply, it's just too easy to switch 2FA on!

Sounds counter-intuitive, right? I mean, why would any firm make it difficult to enable a feature which increases your security? It's already difficult enough to convince users of the benefits, without making it tricky to enable too!

If they want to offer true "out-of-band" 2FA, they'll also need a phone number and/or hardware token (which you're likely charged for). The user needs to either hand over a telephone number which they otherwise wouldn't, or buy something to proactively slow-down the process of signing in. That's a tough sell; probably why companies see an average 40% drop in new clients if 2FA is mandatory!

Let's test the theory...

  1. Open a new tab.
  2. Pick a site you use frequently and see if they support 2FA.
  3. If they do, pretend you've forgotten your password and reset it.
  4. After you've changed your password, try enabling 2FA by which ever method is available.

See how easy that was? Therein lies the problem.

How does the site know you enabled 2FA? It could have been anyone in possession of your password. More importantly, the site's willing to enable it immediately after a password change!

Inconvenience, but at what cost?

Once it's on, it's a pain to switch off without access to the account! But that's the point ;)

Imagine this scenario...

  1. An attacker gains access to your email account; itself tied to every other account you have online. Your bank, shopping sites, Paypal, Twitter, Facebook, cloud storage etc.
  2. They change the password, preventing you signing in.
  3. They enable 2FA, entering their own mobile number which of course, you don't know.

Without 2FA, a password, security question & alternative email reset should restore security/access to the account. With 2FA, you can reset the password until you're blue in the face... you still can't bypass that second factor.

So now you have to contact the provider directly, and you'd better hope they're reachable by phone. Many firms only allow support by email and do not provide a contact number, so you're left waiting for a support ticket which could take hours, if not days.

In a final dose of irony, most companies will often disable 2FA to allow you to log back in!

When 2FA is actually 1+1FA!

The vast majority of sites prompt for a 2FA token after you've provided a correct password, yet I've never had a site email me when the subsequent 2FA token is entered incorrectly.

To reach that point, the attacker already has your password... so that's 1 factor already gone.

Although the 2FA step remains, it's rarely scrutinised to the same extent (if at all) as a regular password, and it really should be! There's often no rate/attempt limiting and worse, despite being an almost cast-iron guarantee that the account has been breached, it's often not used as an indicator to warn the user of the breach!

2FA vs 2SV - There's a BIG difference!


I've moved this section to a new article here:

Possible Fixes

  1. Make 2FA a mandatory option.
    I touched on this in a previous article and it caused considerable confusion.
    If a company offers 2FA during registration, it should be a mandatory step in the process... not buried in settings/profile pages which the user may never see.
    Most important however, if the user chooses not to use 2FA, the option should be:
    a) removed from the account entirely, so it cannot be enabled later.
    b) inaccessible to the user until another form of ID check is performed.
    c) unavailable until the user calls (where possible) and passes a DPA check.

  2. Don't allow the user to enable 2FA for x days after a password change/opt-out request.
    If the account is breached, the 2FA option is disabled to allow time for the user to detect the breach and take mitigative action.

  3. Allow 2FA to be enabled, but don't action it for x days.
    Almost a reversal of No 2, but proactively contact the user until such time that 2FA becomes active.

  4. Make 2SV mandatory and only allow machines with prior consent to request 2FA, which is later confirmed with a call.
    If requests to enable 2FA come from a PC without 2SV consent, inform the user. If the user (who presumably has 2SV consent) requests 2FA, it's "soft-enabled" until the user calls to confirm it. In essence, a second factor of verification to enable a second factor of authentication.

Should I use 2FA?

I hate 2FA in its current form, but I use it everywhere; often ignoring the inherent and occasionally substantial risks involved with using each companies interpretation of it. Why?

It's almost certainly safer than leaving it disabled for an attacker to enable later.

I use a Yubikey NEO & TOTP (akin to and compatible with Google Authenticator) along with Yubico's Authenticator client. It differs from the traditional Google Authenticator route, as the cryptographic seed is stored on the Yubikey itself, not the device upon which the app is installed.


Using 2FA will almost certainly increase security. Not using it however, exposes you to much greater risk and arguably weakens security.

Like passwords, this is a failing in the methodology, not the method itself.