Your digital security is as strong as your weakest recovery email

Veeral Patel
4 min readAug 11, 2020

--

Update (Aug 11, 2020): This post has been the #1 post on /r/netsec for the last 15 hours or so. Follow the discussion in /r/netsec here and in /r/cybersecurity here.

A couple weeks ago, I read Martin Casado’s blog post about a16z funding a new startup called Material Security.

Reading his post led me to reflect on how direly personal digital security needs improvement.

Popular vs real mental model

You see, most people have a mental model of their digital security like this:

  • I have many separate digital accounts
  • Each account has a unique, long password and maybe 2FA

But here’s reality:

  • I have many separate digital accounts
  • I also have one supreme account (my email)
  • If my email is hacked, an attacker can reset the passwords for most of my other accounts

What does this mean?

This means your level of digital security is only as high as the level of your primary email account’s security.

Think about that. You’ve bought a password manager, you religiously generate 15+ digit passwords, you’ve enabled 2FA wherever you can, maybe you’ve even bought a hardware security key.

But it doesn’t matter. Not if your email is hacked.

Second order password resets

Now, you may be thinking: “I have many accounts where I don’t provide my email address. I log in with a third party identity provider, like Facebook or GitHub.”

That’s fair. Unfortunately, if an attacker hacks your email, they can reset your Facebook password. Then they can log into any apps you log in using Facebook.

Weakest recovery email

Any system is only as secure as its most vulnerable path. In the case of email, you may think that “I have 2FA enabled on my email account, so I am secure.”

But keep in mind that your email account’s password, too, can be reset — if the attacker hacks your recovery email.

  • Do you have 2FA enabled on your recovery email?
  • Do you have 2FA enabled on the recovery email of your recovery email?
  • Do you know what the recovery email of your recovery email is?

Your level of digital security is only as strong as the level of your weakest recovery email account’s security.

And how secure is your weakest recovery email, really?

  • Do you know that it exists?
  • Do you check it? If Google sends you an email notifying you that someone tried to log into your weakest recovery email from a suspicious location, will you see that email?
  • Have you ever, in your life, written down the email and password on a piece of paper?
  • Have you ever texted yourself the password in plaintext? Emailed it? Jotted it down in iNotes or a Google Doc?
  • Do you have the password saved in any web browser in any computer? Are you even just logged into that email account? If so, have you ever left your computer unlocked?
  • Are you logged into the account on an old smartphone or tablet that could be stolen and broken into?

What can be done?

The core problem is that online services need to let users reset their passwords self-serve.

But do you verify a user’s identity if they don’t have the thing you were using to verify them with (their password)?

So, online services assume that only you can access your email account, and send a reset code or URL to your email account.

Two ways we can tackle this:

  • Online services stop relying on your email account for verification
  • If an attacker hacks your email, prevent him from accessing password reset emails

Online services stop relying on your email account

Online services could give you a setting to disable password resets.

Or what if we supplemented email with another layer of verification? What if online services had a setting where the user must authenticate with a TOTP code, a MFA push, a hardware security key, or a special password before requesting a password reset?

Or what if we didn’t use email at all as a verification method? Could we design a long set of hard-to-guess security questions to fill this role? What if we let users present a electronic notary seal to an online service as proof of identity?

Prevent an attacker from accessing password reset emails

“Password Resets” Gmail tab

Just as Gmail divides your email into Social, Promotions, Updates, and Forums, it could add another tab for “Password Resets”.

To access this tab, the user must authenticate with a TOTP code, a MFA push, a hardware security key, or a special password.

If you’re really paranoid, you’d set this up so your two factors for authentication and your one factor for accessing your password reset emails are all unique.

For example, you might do password (what you know) and phone (what you have) for authentication and a special password — which you write down on paper and store in a safe — for accessing your password reset emails (also what you have).

Replacing password reset emails in inbox

Just based on reading their website, Material Security seems to take the approach of automatically identifying password reset emails in your inbox and forcing you to accept a MFA push before viewing a password reset email.

I’d be interested in learning how they replace emails in your inbox, and whether they mask password reset emails’ subject lines. After all, many sites (including Facebook) include your recovery code in the subject line.

Crowdsourced thoughts

After I published this post, a few people offered their thoughts on me on this problem, which I thought I’d share.

  • have a dedicated recovery email, with a hard-to-guess username, that you don’t use anywhere else. set this to be the recovery email for all your email accounts (Dino Dai Zovi)
  • also, use Google’s Advanced Protection Program for this recovery email account (Dino Dai Zovi)
  • several services do require 2FA before triggering a password reset (Abhishek Agrawal, co-founder and CTO of Material Security)
  • all identity verification emails (such as account verification, domain verification, etc), not just email verification, should require 2FA to access (Abhishek Agrawal)
  • use a dedicated phone number just for 2FA, if a service doesn’t support an any app options for 2FA (Caleb Sima)

--

--

Veeral Patel

software engineer at OpsRamp, ex-incident response consultant at Mandiant