# Securing Your Account Recovery Chain

I like to think of myself as a pretty secure computer user. I use a password manager and have unique passwords everywhere. I use two factor authentication wherever it's offered. My passwords are long to the point of ridiculousness. But even with all that, I still spent a week of my life earlier this year dealing with a dedicated attacker.&#x20;

They didn't use an old password or hijack an account, instead they used my publicly-facing email addresses and posed as me to customer-service representatives at a handful of popular services. In a handful of cases, they were able to convince the CSRs to cancel my subscriptions or delete my accounts. Once I figured out what was going on, I was able to roll back the damage, but this whole experience showed me that there were a few threat surfaces I hadn't considered and I needed to fix.&#x20;

My big concern was account recovery--specifically, what would have happened if they'd managed to socially engineer their way into my main email account. From that, they would have had access to all of my major accounts--my bank info, my phone, my business records, my server hosting, and more. With that, I looked at how account recovery works on Gmail and realized I had to lock that account down, but it was a more complicated challenge than it seemed at first glance. &#x20;

My main account is a Gmail, which was easy to find, even though I haven't publicized it. I've been using two-factor on that account since it was an option, but I remained concerned that someone who SIMjacked me would be able to recover the account and cause me a whole host of problems. To lock that Google account down, I saw two options:&#x20;

1. Lock down my main Google account using [Google Advanced Account Protection](https://landing.google.com/advancedprotection/)--a Google service for high-profile targets who are likely to face serious hacking and phishing attempts. Google advertises that no AAP accounts have been phished because access requires attackers have the hardware tokens.&#x20;
2. Move all of the account recovery options for all of my services--including that primary Google account--to a new, AAP-protected address that I intend to keep as secret as possible.&#x20;

Unfortunately, Google's AAP prohibits anyone but Google and vetted third-parties from accessing your account, which meant that many of the tools I use in my day-to-day workflow would stop working if I enabled it on my primary account. After looking at the level of chaos that would add to my life, I decided it was easier to just go with the second option. Luckily for me, that was pretty straightforward, although it has required a lot of busywork, logging into infrequently used accounts.&#x20;

## 1. Create a New Google AAP Account

Maybe it's overkill, but the first thing I did was create a new Google account using a randomly selected phrase as the username. Then I grabbed a pair of [Yubikeys](https://amzn.to/2ZaJTFF) that will work with my phone and computers (the NFC/USB option linked here is a safe bet for most phones made in the last few years) and flipped on APP for that account.&#x20;

## 2. Collect Recovery Codes From Your Accounts

Before you make any major changes, it's a good idea to collect the recovery codes for all of your major accounts. It's also a good opportunity to reset the existing codes, if you haven't done a good job keeping track of them.&#x20;

Most providers treat these as the gold standard for account recovery--if you have one of these codes, these will trump any other request for account recovery, including phone number, email, etc.&#x20;

> **You need to keep these recovery codes safe at all costs.**&#x20;

I'm sure there are better ways to do this, but I kept it simple and put plain text versions of all of my recovery codes in a Veracrypt vault, gave it a massive password, and chucked it in a cloud storage service folder and also put that vault on a thumb drive. The thumb drive is stored in a safe location off site along with my backup Yubikey.&#x20;

This is a good moment to consider the recovery process for your password manager too. Having a massively encrypted list of your account recovery codes doesn't do you much good if your password manager is inaccessible without a lost hardware token when you need those codes the most.&#x20;

## 3. Change Restore Addresses on High-Risk Accounts

Next it's time to think about the restore processes on your highest-risk accounts and imagine the different paths an attacker could use to break into your chain of trusted accounts. For a typical Google account, that means you have a phone number, an email address, and maybe some two-factor recovery codes.&#x20;

As with most chains, you are only as strong as the weakest link in that chain. That's often your cell phone provider--if an attacker manages to clone your cell phone, they get access to phone-based two-factor authentication and account recovery texts (That's why app- or hardware-based two-factor authentication are always preferable to text message-based two factor).&#x20;

I started by switching over my most important accounts--my primary Google account, my cell phone account, domain registrars, and crucial third-party accounts, like Apple and Amazon. Once I had the important accounts locked down, I started the slow process of moving everything else over. Using a password manager made this a little easier. I made a tag in my manager for all of the accounts that had been converted over, and gradually worked my way down the list until all the accounts were connected.&#x20;

Side note: I left a handful of lower-priority accounts attached to my primary Google account. Special bonus shoutout to Netflix, which continued to let the attacker cancel my account despite spending hours on the phone with their security team about the ongoing attack.

#### A Note About AppleIDs

Changing my Apple ID to a new email address without wiping and restoring all the devices attached to that account caused a bunch of weird side effects that I'm not going to get into here. Because my account is the owner of my family's account, it created a handful of issues with making purchases from other family members accounts, that we were mostly able to solve by logging all of the family's devices out of their iCloud accounts and then logging them back in. This was an undocumented procedure on Apple's part, and their CSR team was unable to tell me what would happen when I tried it. If I were trying this again today, I'd probably log everyone out first, make the changes, then log devices back in.&#x20;

## 4. That's It. You're Done!&#x20;

Obviously, nothing is foolproof, but this is what I came up with after checking in on best practices and applying them to my situation. If you have comments, suggestions, or general feedback, I'd really appreciate it if you'd leave a comment! &#x20;


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://notthatwillsmith.gitbook.io/techpod-shownotes/master.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
