Security case study: Account Recovery

Yesterday we talked about how we don’t like the idea of security theatre. Instead we develop measures which meaningfully improve the confidentiality, availability and/or integrity of our customer’s data.

Today we’re going to look at a great example of this: when we re-did our password, 2FA and account recovery systems.

Our original password system with alternative logins was a classic “evolved” system that was begun over 10 years ago. Parts were upgraded over time and additions added on. The world we started in 15 years ago was completely different to today. We were an early adopter of something as simple as SSL encryption for all protocols (web, IMAP, SMTP, etc); this was relatively rare at the time. Back then attackers were less sophisticated and online identities weren’t as important. Stolen accounts were rare.

But all of that has changed. Online attackers are much more sophisticated, and the things they want vary enormously, from

• information about a user,
• control of their account to steal bitcoins, or
• even Twitter handles.

About two years ago, we decided to completely redo our password and recovery mechanisms. We designed an entirely new system, carefully considering all the cases.

The first result of this was a completely new authentication system. We moved all protocol passwords (e.g. IMAP, SMTP, CalDAV, etc) to separate application passwords. These allow us to have different access controls for each password:

• they easily allow you to identify which particular device is logging in via your login log,
• you can disable access on a per-device basis if necessary,
• the passwords cannot be used to access the web interface and thus gain access to account settings.

We also completely redesigned how we store user web passwords to allow us to easily store passwords hashed with any hash function we choose. This lets us change over time to keep up with best practice.

Account recovery is a vital part of our security process. Users get locked out for a variety of reasons, from lost passwords, to hacked accounts (most often caused by phishing or password reuse). We want to make sure we are recovering an account to a legitimate user, and not to a malicious attacker attempting to gain access.

When considering our security policy, we tried to enumerate a set of situations that accounts might find themselves in. Quoting some of the thinking from the initial design document:

The primary cases where account recovery is required are:

1. Locked accounts. (Hacker steals password and sends spam.)
2. Forgotten password. Most commonly immediately after changing it (or creating the account for the first time).

In more detail, here are the following scenarios where we would like to allow recovery. In all the following, U = User, pw = password, H = Hacker:

1. U changes pw (no 2FA) and immediately doesn’t know what they changed it to.
2. U hasn’t used service for a while and can’t remember what pw is.
3. U has 2FA and loses Yubikey/U2F/Phone.
4. U has 2FA and forgets password, or changes it and can’t remember new one.
5. PW stolen. H changes pw. U tries to recover.
6. PW stolen. H changes pw + recovery options.
7. PW stolen. H changes pw + recovery options + adds 2FA. U tries to recover.
8. PW stolen. H adds 2FA. U tries to recover.
9. PW stolen. H uses to send spam. Account locked. User has no recovery options.

Conversely, we must deny recovery to anyone else. When in doubt, we should side with denying access. In more details, here are some of the scenarios that must be taken into account:

1. PW stolen. U changes pw immediately. H tries to recover with old pw.
2. PW stolen. U adds 2FA. H tries to recover with current pw.
3. PW stolen. H accesses account. U changes pw. H tries to recover with old pw.
4. PW stolen. H goes through reset process but waits at end screen. User changes pw or adds 2FA. H than tries to change pw at end screen.
5. PW stolen. Account locked. H tries to unlock.
6. PW stolen, but account has 2FA. H tries to recover.
7. Phone stolen. H has access to email account via IMAP/app + any 2F token + SMS.
8. PW stolen. H changes recovery. U changes pw + recovery. H tries to recover.

From that as a starting point, we then proceeded to design a completely automated system to meet all these needs. We are acutely aware of the risks of social engineering and the goal of the new tool was to completely remove human interaction in as many cases as possible.

No automated system can resolve 100% of cases, and this type of system must err on the side of denying access in cases where there is sufficient doubt. Where users contact support because they were unable to regain access to their account through the recovery tool, we have a policy in place to escalate to senior security team members. This lets us review each case and further refine our automated system.

There is a tension between keeping your account secured while maintaining recovery in the face of everyday life events such as: password loss, device reset, or changing phone numbers. We believe with our current system we have found a reasonable balance. Users who elect to enable two-step verification can weight the balance towards higher confidentiality at the expense of potential loss of recovery. We make sure that recovering your account if you have 2FA enabled is no less stringent than login and still requires two independent factors.

As an example of one of the many small tradeoffs that occur: some users have questioned why we require people to have a recovery phone number in place when you setup a 2FA option as phone numbers are known to be insecure. With 2FA set up, a phone number alone is not enough to perform an account recovery: a correct password is still required. Someone compromising your phone alone won’t be able to gain access to your account. In fact if they tried, we’d email you letting you know that there was a failed attempt to reset your password, likely alerting you to the fact that your phone number had been stolen!

This is a good balance. If you really don’t want your phone as a recovery option, you can remove it after adding the 2FA, but this is risky. We’ve seen several people do this, and then lose their 2FA device (they lost their phone, or their TOTP app got reset, etc), or even change their password and immediately forget it, without a recovery option. If that happens, you will lose access to your account permanently. Setting up 2FA without a recovery option suggests that you value security over availability at all costs, and it’s up to you to ensure you never lose your password or 2FA token.

Working on the design and implementation of the new security and account recovery system took well over a year with many discussions along the way. Real world security is hard, but we believe we’ve now got one of the best systems in place.