A recent story about a VPS provider customer losing two servers due to social engineering sparked a conversation we have regularly at Exoscale: How do you handle lost 2-factor token requests?

Two-factor authentication relies on securing access to your account based on something you know and something you have. The usual something you know part is a user identifier and a password, while the something you have part is generally access to an out-of-band way of retrieving a one-time password.

Common techniques to provide access to a one-time password are:

  • Sending an SMS pin-code, a common technique employed by banks.
  • Using physical devices to retrieve a pin-code, such as a RSA SecurID device or Yubikey.
  • Using a time-based one-time password — TOTP for short — made popular by Google Authenticator and supported by many providers such as Github, Dropbox, Bitbucket, and Exoscale.

For critical services, such as access to your infrastructure on Exoscale, we recommend taking advantage of 2-factor authentication.

What to do when the inevitable happens ?

As a security-conscious customer, you checked all the boxes and activated 2-factor protection for your Exoscale account. Unfortunately, you lost the phone on which you had your authentication application to retrieve TOTP tokens.

If you misplaced the backup codes that were given to you when you set-up your device you now have no way of accessing your account again.

The provider conundrum

As a provider, when contacted to reinitialize tokens we’re in a tough position. As you know, our support is performed by our dev & ops team, and we all designed our 2-factor authentication to be bulletproof. We thus feel that reinitialising access to accounts for such requests would defeat the purpose of what we built. At the same time, since our service is usage-metered, if you have resources running you would be expected to pay for a service you don’t have full control of anymore.

The essential question is thus: Should there be a way of resetting 2-factor authentication beyond initial backup codes?

At Exoscale, stances vary on that question from very strong ones, opposed to any kind of access restoring, to more accomodating ones.

What we can do

In a situation where you have lost access to your one-time passwords, we settled on two methods to authenticate users. This is predicated on you having done one of two things:

  • Having a phone number configured in the user account.
  • Having an RSA public key registered in your private account (not an organization account).

If a phone number is present in the account, we will send a challenge to the phone number and act on the request if the correct challenge is sent back to us in the account reset request.

If an RSA public key is registered in your private account, we will send the digest of a challenge, expecting it to be signed with your private key. Using the public key registered on your account, we will verify the signed digest and act on the account reset request if verification succeeded.

What you should do

As a customer there are a number of steps you can take to ensure your account is never compromised and you never need to go through this procedure.

First and foremost, make sure you store your backup codes in a secure place. This will guarantee you can reinitialize access to your account at any time, up to 10 times.

Another measure would be to install oath-toolkit in addition to your phone’s authenticator. TOTP is not Google specific, it’s a standard defined in RFC6328 and is thus implemented by several applications. On a machine you trust and that is well protected, you can install the toolkit which will allow you to retrieve your one time passwords should you lose access to your codes.

And last, and this will seem obvious, you should always ensure you verify certificates presented to you. We take great care in making sure our sites are well secured, so any spurious certificate confirmation dialog would be a sure sign of a man-in-the-middle attack.