Making it easier for users to manage key recovery with cloud-based recovery!
|
Working in and around crypto interfaces long enough, you’ll come back to a variation of this sentiment: “Give me exclusive control over my account. I also want the ability to reset my password with your help.”
For those of us working on the UX of self-custody, this is the closest thing we have to an impossibility result: “I want a safety net, but no wires.” There are solutions to mitigate this problem—I’m thinking, for example, of Farcaster’s elegant onchain ID recovery system—but as with all things engineering, tradeoffs abound.
At Privy, our goal is to give every app the right means of securely engaging their users. This is why we are so excited to introduce Cloud-based recovery today! Today, we say “why not both?”
This feature offers users more control by allowing them to back up their secret to the cloud. While automatic recovery remains the simplest experience Privy offers, this marks a new milestone of our ongoing effort to improve the UX of self-custody.
Our work here is never "finished"—building with Privy means future-proofing your application, balancing security, custody, and performance for your users.
Here’s a bit more on the launch.
A quick primer on the Privy cryptosystem
Skip ahead if you already know how Privy works, or read about in detail here.
As a reminder, Privy splits user keys into 3 shares on creation. On its own, each share is useless (and yields no information needed for key reconstruction). If 2 shares are combined, the user’s key can be reconstructed. We have a device share that sits on the user’s device, an auth share held by Privy associated with the user’s login method, and a recovery share used to provision new devices for use.
In the basic course of operation, the device and auth share are recombined to regenerate the key and sign a message. The tricky bit is provisioning a new device, for instance if a user loses their phone or decides to log in from their laptop as well. Enter the recovery share.
The recovery share is always encrypted on the user’s device so only they can access it. This enables the user to easily provision a new device by logging in, decrypting the recovery share on device and using it with the auth share to recover their key and split it again yielding a new device share. Throughout this process, Privy can never access it or the user’s key; only the user can.
Anatomy of the feature
In automatic recovery, the recovery share is cryptographically protected, and the entropy this depends on is secured by the system architecture.
In password-based recovery, the cryptosystem is very much the same, but the user directly provides a password used to derive the encryption material for the recovery share instead.
This means the user controls exactly how the recovery share is encrypted with no dependency on Privy infrastructure, but it also means they’ll have to reinput that password to provision a new device. If they lose their device and forget their password, they’ll lose access to their account. No password resets here.
We believe this tradeoff space matters and it is important to offer both options to developers and their users. Users and apps come in all shapes and sizes and certain power users want to control exactly how to secure their recovery system. To that end, we've collaborated extensively with customers to determine the right balance of friction, enabling users to easily set passwords while reinforcing the importance of securely storing them.
This has meant UIs that:
- Help users set strong passwords with the tap of a button.
- Have them reinput passwords on creation to ensure they weren’t mistyped.
- Have the user confirm and reconfirm that they understand the consequences of password loss.
And yet, we know password loss can happen. This sort of tension is representative of the design challenges building a self-custodial system. For instance, we consider whether to force users to choose randomly generated passwords (which are more secure, but also more likely to be forgotten) or allow them to pick their own (easier to remember, easier to reuse).
Staking new ground in the tradeoff space
The introduction of Cloud-based recovery is an exciting unlock that helps balance UX and dependency on system architecture. Users can automatically set strong passwords without needing to store or remember them.
Your user just needs to log in to Google (or their favorite cloud), and give appropriate permissions. That’s it. Of course, they can always set their own password if they prefer.
At a high level, you can think of the tradeoff spectrum as:
- Automatic recovery: Offers the best user experience and architectural guarantees.
- Password-based recovery: Provides cryptographic guarantees but results in the worst user experience.
- Cloud-based recovery: Enhances user experience while maintaining cryptographic guarantees.
In building out this system, we considered other options abandoned along the way, such as using passkey blob storage to store the actual recovery share (too unreliable today) or emailing a “recovery packet” to the user (insecure).
There’s a lot more we’re excited to build here, including using passkey for entropy as they become more reliable, and onchain fallbacks using EIP-3074. Over time, better primitives enable us to bridge UX and system guarantees in ever more elegant ways—this is why we celebrate launches like today’s. Onward!
Thank you to everyone who provided the feedback and insights that led us here. If you’d like to check out this feature, head to demo.privy.io and toggle on “user-managed recovery” in the embedded wallets section. If you’d like to build with Privy, sign up at dashboard.privy.io. We’re excited to work with you.