How does social login with MetaMask work?

opmerking

To learn more about creating a new wallet with Google/Apple, jump here. Read below to dive into the technical setup, security, and self-custody considerations when using MetaMask’s social login flow.

Crypto wallets are necessary to do anything in web3. While Secret Recovery Phrases (SRPs) remain the prevailing industry standard to create one, they pose problems:

• It can be clunky and confusing for new users to write down 12 secret words when creating a wallet
• Many skip backing up the SRP when creating a new wallet, leaving their funds at risk
• Others take shortcuts like screenshotting their SRP, not realizing how insecure that is
• Even those who do write down their SRP at the time of wallet creation can misplace it later

There is no shortage of stories about people inadvertently exposing or losing their SRP, ultimately resulting in the loss of their funds. To support more users, we’ve introduced a self-custodial process that avoids backing up the SRP manually when creating a wallet.

Now, when creating a MetaMask wallet, one has the “Login with Google/Apple" option—instead of writing down the SRP during setup, it’s securely backed up online and protected by both a Google or Apple login and a password you create.

The system

At its core, MetaMask’s social login uses a cryptographic primitive called “Threshold Oblivious Pseudorandom Function” (TOPRF) alongside a distributed key management protocol to ensure that you remain in custody of your tokens, all while providing a high level of protection against attacks and failures.

The system components

• MetaMask clients (your wallet app or browser extension)
• Login providers (Google or Apple)
• Key share holders (Server nodes holding fragments of the cryptographic key)
• Data store (houses encrypted data)

The feature is designed to be self-custodial. The only instance where a full SRP exists is on your device, after you’ve successfully authenticated with your login and password.

• When the SRP is backed up, it is stored in MetaMask's backend as encrypted ciphertext
• The encryption key is split across multiple key share holders using Shamir Secret Sharing (SSS)
• No single party (not MetaMask, not the data store, not Google or Apple), other than you, can reconstruct the SRP in plaintext
• The SRP is obtained in a 2/2 setup: by authenticating with the selected login provider (Google or Apple), and supplying the correct password

Backing up the wallet

This is how the online SRP backup works:

1. You login with Google or Apple and obtain a corresponding access token upon successful login (Note: this is not a 'token' in the cryptocurrency sense, but instead a bit of backend code.)
2. You choose a strong wallet password
3. Your device generates a random OPRF key, splits the key into key shares using Shamir Secret Sharing (SSS), and stores the key shares across the key share holders (where access control is governed by your social login token)
4. Your device runs the OPRF locally to derive an encryption key from the OPRF key and your password
5. The encryption key encrypts the SRP and stores it in the data store

Recovering the wallet

If you lose your device or want to log in to MetaMask on a new device, you can just log in with Google or Apple in that new instance, and input your password.

It will feel just like logging into your wallet, but on a technical level, it’s “restoring your wallet” from the online SRP backup:

1. You log in with Google or Apple on the new device
2. You enter your password
3. Using the password and the authentication token from the login provider, your device runs the TOPRF protocol with the key share holders
4. The encryption key is derived if the password is correct
5. Your encrypted SRP is downloaded from the data store and decrypted

The process fails if the password is wrong. To protect against brute-force attacks, the key share holders employ a rate limiting mechanism to limit the number of password guessing attempts.

Self custody and security

In typical MetaMask fashion, we didn’t want to compromise on self-custody with social login, even when introducing easier wallet creation flows. For a truly self-custodial solution, there must be a component that is independent of the infrastructure and only accessible to you. In this case, it’s your password.

tip

You are required to manage this password as securely as you would manage your SRP.

With the cryptographic encryption system, we created a solution where the SRP remains protected by the password even if all other system entities are compromised.

• Key share holder compromise: If a number of key share holders below the secret-sharing threshold is compromised, full security as described above remains intact. If a number of key share holders above the threshold is compromised, the attacker obtains the OPRF key, but still needs to brute-force the password to derive the correct encryption key.
• Login provider compromise: If your Google or Apple login is compromised, then an attacker can engage in the recovery protocol (steps outlined in the “recovering the wallet” section) with the key shareholders. However, the number of password guessing attempts is limited due to the server-side rate limiting.

Using password managers and local keychains secured by biometrics can help to reduce the risk of password loss or theft, but there is still a huge reliance on the password.

That’s the tradeoff for maintaining self-custody, so make sure you keep your password and devices safe! We hope this introduces a more convenient path to create and restore your wallets.

References

• TOPPSS: Cost-Minimal Password-Protected Secret Sharing Based on Threshold OPRF | SpringerLink
• How to share a secret | Communications of the ACM