At the USENIX Enigma conference, Facebook unveiled a new way to overcome the problem of forgotten passwords. Known as Delegated Recovery, the mechanism essentially allows two online services a user has accounts with to be used as a form of two-factor authentication.
Delegated Recovery is something of a new take on 2FA, building on Facebook’s previously announced support for U2F Security Keys. The problem with password recovery via email or SMS, is that it’s easy for the recovery medium to be compromised, and security questions are easily guessed. Delegated Recovery takes a new approach, and it’s being trialed on GitHub.
Actually, Delegated Recovery is not only being trialed on GitHub, it has been made available on the platform too. It is described as “a protocol that allows an application to delegate the capability to recover an account (e.g. in the event of a credential loss or compromise) to an account controlled by the same user at a third party service provider.”
On GitHub, Delegated Recovery has been implemented as a feature called Recover Accounts Elsewhere:
The Recover Accounts Elsewhere feature lets you associate your GitHub account with your Facebook account. This will help us recover your account for certain two-factor authentication lockout scenarios. For example, you may become locked out of your GitHub account because you have lost your phone or U2F key, changed phones without re-enrolling, or have otherwise lost the ability to use your phone or token without a usable backup.
Currently, losing the ability to authenticate with your phone or token requires that you prove account ownership before we can disable two-factor authentication. Proving ownership requires access to a confirmed email address and a valid SSH private key for a given account. This new recovery feature will provide an alternative proof of account ownership that can be used along with these other methods.
Put simply, if you have an account with GitHub and Facebook, you can use one as a recovery method for the other, but it does require a degree of preparation. For example, you will need to create a recovery token with GitHub that can then be stored within your Facebook account. Should you ever lose access to your GitHub account, you can regain entry using the stored recovery token.
Importantly, the process does not grant access to the locked account, it is just used as a method of identity verification. GitHub explains the flow of information:
- GitHub encrypts a secret value using 256-bit AES-GCM that is associated with an account’s identity in a recovery token object along with other metadata.
- The token is digitally signed by GitHub using secp256r1.
- Facebook stores this token on their servers until needed. This token is not countersigned until a recovery is initiated and is unusable at this stage.
- When a recovery is initiated, Facebook countersigns the token and sends the countersigned token back.
- GitHub verifies the countersigned token using the following rules:
- The countersignature must be valid.
- The countersigned token must have been issued recently.
- The signature of the original, nested token must be valid.
- GitHub looks up a recovery token by a 128 bit randomly generated ID and ensures that token has been confirmed as saved and has not been revoked.
- GitHub decrypts the secret in the original token and uses this to verify the owner of the token.
GitHub only stores the token ID, user ID, and token state. Facebook only stores a token with an encrypted secret that is associated with a Facebook account and does not become valid until it’s used in a recovery. This process helps limit the impact of database dumps and SQL injection vulnerabilities without an additional compromise of the encryption and signing keys.
At no point does GitHub exchange any personally identifiable information with Facebook. Likewise, Facebook does not exchange any personally identifiable data with us.
More information is available from Facebook Engineering and GitHub Engineering.