Security news that informs and inspires

How Popular Web Services Handle Account Recovery

Hunter Smith's dilemma should be a familiar one: He forgot his password and cannot access his online account. To make things worse, he can't reset the password because he originally signed up with the email address for a previous job. Or he has his password, but he also turned on two-factor authentication on his account and he'd recently changed phone numbers. He needs a way to prove to the service provider he is really the Hunter Smith in question and not some sneaky imposter.

If you’ve ever needed to get back into your account on an online service after changing your email address or getting a new phone, you went through account recovery. We expect to have to take extra steps to identify ourselves as the account owner, but we also expect some level of security to prevent someone else from forging our details. While passwords may be involved, account recovery isn't your basic password reset. The extra steps help "recover" the account to its rightful owner: You.

As a long-time hacker, there is nothing more fun than using the real world as a laboratory. So I looked at how 12 popular web services handled account recovery and found slight differences in each of their processes. As expected, some had better layers of security than others. The list included email providers Gmail, Yahoo, and Microsoft's Live.com; social networking platforms Facebook, Twitter, and LinkedIn; tech hubs Reddit and GitHub; online retailers Amazon and Apple; and cryptocurrency exchanges Coinbase and Kraken. I included Apple because Apple ID is required for shopping on iTunes and Apple Music. Cryptocurrency made the list because I wanted to be cool.

I looked at each provider's account recovery process as well as what type of security was in place to protect the account. I noted the minimum level of security required to access the account, the instances when extra security steps were required (such as during recovery), and additional security features beyond the basic password and two-factor authentication options. Setting up secure account recovery is hard enough, but if the account isn't protected from forgotten/stolen/phished passwords, then the entire process becomes moot.

Note: Everyone names things differently and pages sometimes change. The options available, what they are called, and where they can be found are accurate as of February 2018.

While passwords may be involved, account recovery isn't your basic password reset.

There are different types of recovery schemes: Recovery keys, trusted devices, alternate email addresses and phone numbers, and a form of personal identification, such as a driver's license or a passport. Each one has its own strengths as well as trade-offs.

Unlike security codes which are generated during login, recovery keys are generated during initial account creation and can be stored offsite or offline. There are various cryptographic schemes that can be used, and the most practical one would involve public key (or asymmetric) cryptography. The key proves the owner is the legitimate owner and is allowed to add new information and credentials to the account. If the key is lost, the account owner loses the ability to recover the account. Therefore, the recovery key must be protected, and protected well. The storage location should be physically or digitally secured.

Many of the web services I looked at offered some kind of backup/recovery codes or special recovery codes that could be downloaded offline. Remember, though, if you are wiping or reinstalling your device, you may lose security keys, backup codes, and code keys. See if there is a way to save them (printing out backup codes is not a bad idea), or remember to go back to the accounts to regenerate the keys to replace the lost ones.

When users designate their devices as trusted devices on a service, a cryptographic key unique to that hardware is generated and stored. The user can initiate account recovery only from these devices, but it also means that so can anyone who has possession of the device, especially if the same device is used for two-factor authentication. In theory, an attacker with physical access to a trusted device could extract the cryptographic material and make another device trusted, as well. Web services typically allow more than one trusted device. As long as you maintained a couple of trusted devices, you might not find yourself in an account recovery scenario, anyway. Keep in mind that you shouldn't physically hand over trusted devices to another person to show a cat video or a trendy meme. Take good care of your devices.

While many web services let users register trusted devices, this wasn't a common security feature among the ones I tested.

If the user saves an alternate email address and phone number (also called recovery or backup addresses) the service can send recovery information even if the user no longer has access to the primary address or number. Most services require the secondary phone to be able to receive text messages, so landlines are typically out. If the service is using SMS to send messages to the alternate number, a clever attacker posing as the web service could craft a phish asking the user to submit the codes sent to their phones into a fake site. The attacker can log in to the account, if they act quickly before the codes expire.

Not all services let users use alternate email addresses and phone numbers to perform full account recovery and save new account information. Most services, such as Live.com, limit users to just performing a password reset. Users enter new information once they are back in the account. GitHub lets you save secondary phone numbers for backup two-factor authentication, which is pretty uncommon.

Users can send some form of personal identification, such as government-issued ID, to prove their identities during account recovery. It's not fool-proof, since people have been making fake driver's licenses for years. A buddy of mine once showed me a legitimate-looking driver's license with my hacker handle alongside his picture, and that was more than a decade ago. Unless the service has a way to validate the ID, this is not a great option. Some services have this as their main and only account recovery option--which is reason enough not to use an alias when initially setting up the account.

Since account recovery is, in essence, a bypass of the main account security protocols, they should be treated as an alternative authentication system. Account recovery security processes should be equal, or higher, in quality to the main account security scheme.

Services have to balance the benefits with what makes sense for their users when making security decisions. An overly complex account recovery system could be a potential minefield as users make mistake navigating the extra steps, or could be onerous enough that people don't bother to use the service. I prefer the recovery key method, with trusted devices running a close second. The ideal scenario is to combine elements from difference schemes. Using an account recovery key with a form of two-factor authentication from a trusted device would be awesome!

Account recovery is, in essence, a bypass of the main account security protocols, and therefore should be treated as an alternative authentication system.

How do the online services from my original list of 12 compare when it comes to account recovery? There are similarities across web services, such as the fact that the majority of them store backup phone numbers. Twitter, Reddit, Amazon, Coinbase and Kraken do not support secondary email addresses. All services support at least one account recovery method, but Yahoo, LinkedIn, and Coinbase doesn't generate account recovery code that can be used to get access to your account when all other methods fail. Apple offers the most options out of all the services.

Web services considering their account recovery options are strongly recommended to look at how both Facebook and GitHub have implemented their account security options, including account recovery. Both sites are excellent examples of how to do account recovery (and account security!) right, and while there is plenty to nitpick over the implementation details, under the hood, they are done correctly.

As I mentioned earlier, account recovery is directly tied to general account security, so I wanted to see what kind of security layers was in place to protect the account. It doesn't matter how the provider implemented account recovery if basic account security can be bypassed and someone else can access the identity-related information. As part of this investigation, I looked at basic security requirements during account creation, and then checked if the service allowed users to add a alternate recovery email address or phone number for password reset or account recovery, turn on two-factor authentication, or link with third-party sites to handle authentication. When creating the password as part of the initial signup, I used a variation of [hunter2](http://bash.org/?244321) that met the site's minimum password security requirements, such as hunter2hunter2!! or hUnTeR2HuNtEr@. After that was complete, I looked at what security choices existed, noting the minimal needed actions to turn on any account recovery options.

As with account recovery, I saw some overlaps and some significant differences across services. Most services supported some form of two-factor authentication (may also be called multi-factor authentication (MFA), two-step authentication, or two-step verification), which involves something you know (password) and something you have. The second factor can be many things, including a physical security key, a security code sent via SMS or text message, a security code read to the user over a voice call, a one-time code key generated by a mobile app, or a "push" notification sent to the user's mobile device to verify or block an attempted action. The services I looked at were all over the place in the kind of options offered.

If you are an online service monitoring security events, we have some recommendations.

Online service providers wondering how to tell the difference between recovery attempts and fraudulent takeovers should check out our recommendations on how to monitor security events.

The most common example of two-factor authentication is entering a special numeric code (usually 6 digits) on the login screen which was sent to the phone via text or SMS message. Some services call instead of sending a text, and a robotic voice reads off the code as part of a phone call. While we support SMS and encourage its use when there is no alternative, we highly recommend "push" technology as more secure.

One thing about the push notifications: A notification that simply states “Someone just logged in as you. Is that cool?” is not a push because the authentication has already occurred. It is simply a notification after the fact. A true Push notification will block the authentication attempt if the user does not approve the action.

The security key, which can be referred to as the U2F key, U2F security key, or a hardware-based one time pad (HOTP), stores cryptographic secrets on a USB device. After logging in with a password, users plug the key into the device's USB port and tap on the button to authorize the transaction. Yubikey is a popular U2F key, and there are even some security keys that are near-field communication (NFC) devices.

The code-key is a combination of the security key and text message, as the time-based one-time pad (TOTP) is uniquely generated by the mobile app and entered on the login screen. The app generates the code right after you scan in the QR code displayed on the site, or a unique identifier linking you to the site. The beauty of this is that you don't need a dozen apps for a dozen authentication scenario into a dozen web services. It can all be in one app. Google Authentication is probably the most well-known, and others include Authy, AWS Virtual MFA, and Duo Mobile.

Two-factor authentication that requires entering some kind of a code (regardless of delivery method) into a web field is vulnerable to phishing. I consider push notification or security keys the most secure, with the security key being the (ever so slightly) better choice. Given the choice of using a second factor or just a password alone, I always recommend turning on second factor.

Add extra security to your account. See what you have to do for each web service.

There is no point in having account recovery if an attacker can simply thwart basic account controls. Here are some of the recommended security controls to turn on for your account.

How Each Web Service Fared

Gmail was easy to set up. The password hUnTeR2HuNtEr@ satisfied the minimum password requirements. I was able to add a secondary email and a secondary phone number to the account account. Gmail supports FIDO U2F security keys, codes via SMS, and code keys using an app (TOTP) for two-factor authentication. Gmail also generates backup recovery codes that users can print out and store offline for emergencies. I found that if you activate Google Prompt (Google’s version of “push” notifications), you have to disable the U2F key. Given the choice, I recommend keeping FIDO U2F. In order to set up Google Voice, I needed to use my real phone number.

Yahoo is clearly trying to step up its security game after multiple widely-publicized security breaches in the somewhat recent past. It rejected hunter2hunter2!! and hUnTeR2HuNtEr@ as the password as they contained some variation of the first name “Hunter” in the string. So rEtNuH2ReTnUh@ it is. Yahoo also required a phone number to send a 5-digit “Yahoo Account Key” to verify the account, but I could not use a VoIP number (in this case, Google Voice). Yahoo was the only service on my list (other than Gmail) that did not let me use a Google Voice number. It was also the only one that checked my password to see if I was using a variation of the username.

Yahoo currently supports only SMS and voice (the code is read over the phone) for two-factor authentication.

If I specified a recovery email address or a phone number beforehand, then Yahoo would send an "account key" as part of account recovery. This was not a recovery code, but an extension of the password reset process since the alternative address or number was store within the basic account information section and not under recovery.

Live in this case also includes Outlook.com and Hotmail, as there is really no difference in the security settings between the three Microsoft properties, The password hUnTeR2HuNtEr@ met Live's minimum password requirements. Like Gmail and Yahoo, Live supports secondary email address and phone numbers. Microsoft offers SMS for two-factor authentication and uses trusted devices to protect accounts.

While not really an issue, it is still a complaint: When setting up the mobile app to get the Code Key for offline TOTP authentication, I cannot scan the QR code on the screen into my authenticator app of choice. I first have to set up Microsoft Authenticator. I can delete Microsoft Authenticatior after scanning the code into the preferred app, but the required first step is a pain to deal with.

Facebook accepted hUnTeR2HuNtEr@ as the password and let me use Google Voice to verify the account. It easily has the most security options available There are multiple two-factor authentication options, including FIDO U2F, SMS, and TOTP. It supports trusted devices. Account recovery relies on offline backup codes. Secondary email and phone numbers are for password resets. Email notifications often involve sensitive information, so Facebook lets you add your public PGP key to the account so that all email notifications are encrypted.

Facebook lets you preemptively add three to five friends to a special list to help with account recovery. If you cannot get into your account, Facebook will send recovery codes to each one, they will get those codes to you. You get three codes, and you are back in. This is more of a “Someone logged in as me and changed my password” kind of recovery, and not true account recovery as it helps you reset the password and two-factor authentication options.

The social networking giant also generates one-time passwords if you don't have two-factor authentication enabled and you are concerned about being on a questionable WiFi network. Text otp to 32665 to get the temporary password. There is a minor security concern, though, as someone with access to your phone can login to Facebook using the OTP text. This feature doesn't work if you have two-factor authentication enabled. Another reason to use two-factor authentication.

While Facebook offers a variety of extra security features, they also offer options that seem to run counter to good security choices, such as the ability to login by clicking on the profile picture. Fortunately this option is off by default, and should remain off. You can enable a four digit passcode to go with the profile picture, but I highly recommend disabling this feature. Disabling it can be a pain, as you have to turn it off in account settings and delete associated cookies in the browser. On a mobile device you have to delete the app and its data and then reinstall. Otherwise, even if you change your password, an attacker can still use the feature to click on the profile picture to log in because the cookie is saved in the browser.

I didn’t discover this issue but learned about it from other victims. Leave it off and use two-factor authentication to prevent others from getting into your account.

Twitter actually allowed hunter2hunter2!! for the password and was one of only two services that allowed a password without an uppercase letter. The site required additional security steps before creating the account though: such as verifying my phone number (Google Voice) and my email address. Twitter was the only service to require both just to create the account. Turning on SMS-based two-factor authentication is just a checkbox. I could also use a cody key.

LinkedIn accepted hUnTeR2HuNtEr@ as the password and required email address verification before creating the account. The "Facebook for adults" supports SMS-based two-factor authentication, and uses secondary email addresses and phone numbers for password resets. However there is no unattended account recovery process. To regain control of your account, you have to complete a multi-part form and submit a copy of the government-issued ID to LinkedIn.

Reddit also acceped hUnTeR2HuNtEr@ as the password and required email address verification. Reddit recently introduced two-factor authentication using Code Key, and also provide account recovery codes.

Github was like Reddit in that it required email address verification and its minimum password requirements meant I had to use the password hUnTeR2HuNtEr@. GitHub had nearly as many security choices as Facebook, including support for U2F security keys and SMS-based two-factor authentication. GitHub was the only service that allowed secondary phone numbers to be used as a backup two-factor authentication mechanism, in case you lose access to your primary authentication device.

To get your Github recovery codes you have to enable two-factor authentication, first. You can also store a special account recovery token in Facebook. The GitHub staff uses the token to verify your identity, but cannot access your Facebook account. Github also makes extensive use of SSH to code repositories so it offers extra security options for your SSH keys--but that is slightly beyond the scope of this investigation.

Apple ID accepted hUnTeR2HuNtEr@ as the password, required email address verification, and was the only service that had me pick answers for three different "security questions." Some of the questions were rather simple and barely qualified as security questions, such as the first pet's name, favorite music group, or mother's maiden name. A simple perusal on social media can answer that, which defeats the secret nature of the question and is why security people hate them. Apple has 15 of them, and you have to choose one from a group of five. The company uses these security questions for password resets and account recovery, but go away once two-factor authentication is turned on.

Apple does not use U2F and TOTP solutions for two-factor authentication, as it relies on a trusted devices model. Personally I don’t like it when trusted devices simply means you can skip the login process. I think logging in and re-logging in is great, and I don’t mind the extra work. Since Apple displays the code as a pop-up alert on a trusted device during an account recovery or password reset situation, I am ok with this implementation. However, if someone holding an unlocked trusted device receives the pop-up alert, that person can take over the Apple ID account.

I cannot stress enough that you must secure any trusted device physically, because if a screen is left unlocked or a passcode is shoulder-surfed by someone with ill intent, they could leverage that access.

Amazon. This was the easiest to sign up to, set your email and a password of at least 6 characters, and it took hunter2hunter2!! no problem. Nothing else was required, I could immediately start shopping. You could add a second phone number to assist with password resets. There is 2FA available via SMS, voice message (where a robotic voice speaks the numbers), and via Code Key. Account recovery involves contacting Amazon via a toll free number, and I have no idea what is involved beyond that, but there are certainly no account recovery codes or any other self-help online methods.

Coinbase required me to link a Visa or MasterCard to the account. As I was unwilling to open a Hunter Smith credit card, and it seemed kind of illegal anyway, using a fake identity was out of the question. None of the passwords that I used for other services satisfied Coinbase's minimum password requirements. Once I verified the email address and phone number, I was able to use SMS-based two-factor authentication and Code Key. Like GitHub, I could use the secondary phone number for backup two-factor authentication if I was using SMS-based authentication. If I was using the Code Key, I can download the private see used and store it offline, somewhere safe. The seed helps recover the Code KEy, as Coinbase does not have any full account backup or recovery codes. If you need account recovery, or need to change two-factor authentication settings without access to the phone or private seed, you have to send in a copy of a government-issued photo ID to Coinbase.

Whenever you authenticate from a new device, Coinbase requires you to authorize the new device using your email address, which is a nice touch.

Kraken accepted the hUnTeR2HuNtEr@. Verifying the email address gave me just "Tier 0" access, which meant I could make changes to my account could not participate on the exchange. To access Tiers 1 through 4 required verifying increasingly detailed information such as government-issued IDs and banking details. While non-intuitive, Kraken offers multiple two-factor authentication schemes, including FIDO U2F and Code Key (TOTP). You can set up multiple forms and assign each one to different actions on the account. Kraken admirably does not support SMS-based two-factor authentication.

Kraken also lets you create a Master Key, or a master password for account recovery, in order to get around failed two-factor authentication. I highly recommend using a password as the second factor on the Master Key. Both the Master Key and the password (which is unique from the normal password) should be stored offline in a safe location. Obviously you should use extremely secure values for all passwords and the Master Key.

Why the Security Decisions Matter

There you have it. The best and not-so-great security choices made by 12 popular web services for account recovery and basic security. Bear in mind that my idea of "best" is subjective, as I operate with a rather paranoid lens where I assume the worst scenarios coming from the most heinous of online attackers. You may place a different level of emphasis on certain feature sets and how they are implemented. Good security depends on putting together a set of somewhat effective choices that may not seem ideal. Email is considered the keys to the kingdom. If your email has been compromised, most services allow for password resets via email so any other service tied to your email is at risk. I highly recommend you turn on two-factor authentication on your email and make sure to generate and securely store recovery codes. If you can add a secondary email address, do it. Do not use the same password for different services, and don't use “good” passwords for important sites and “simple” passwords for others. Use a complex and secure password that is unique for every service you use, and store them in a password manager such as LastPass or 1Password. Just because you use two-factor authentication on accounts you care about doesn't mean you should make figuring out the password a simple guessing game.

Put extra layers of security at multiple points to slow down an attacker. If you have two accounts and they are backups for each other, the attacker just needs to compromise one in order to get both. Or an attacker may piggyback across multiple accounts to reach the final target. For example, an attack may have access to the victim's Yahoo account, which is the recovery address for the Gmail account. The attacker initiates password recovery for Gmail, which gets sent to the Yahoo account. With control of the Gmail account, the attacker gets control of Facebook. If the victim had saved the GitHub security token on Facebook, the attacker can use the token to get into GitHub. And it all began with a compromised Yahoo account.

Two-factor authentication breaks the cycle.

Most major services offer various 2FA implementations. While not all are perfect, they help protect the account from basic attackers you have managed to gain access to a password. Account recovery requires turning on a few extra security features, which are well worth the effort, as it allows you to get back into your account due to either forgetfulness of a password or an account compromise. Turning on extra security features is great - turning on the right ones is even greater.

Mark Loveless is a senior security researcher at Duo Labs.