We are working on account recovery in a secure way, and have some upcoming writing and designs to share in addition to this post.
Fission’s account system is designed to include file storage with each account, built on the Webnative File System #wnfs. This has a private, encrypted portion that is the default user storage, as well as a public, unencrypted portion. The file system is encrypted end-to-end and encrypted at rest, as well as designed to not leak file metadata or directory structure. Only the user and their linked devices hold the key to access the encrypted files – Fission can’t access the files and can’t recover the unencrypted data.
Account Recovery is to solve for the catastrophic failure case where someone loses access to all their devices – we will implement UX and other user nudges so that device linking can be used to get access, rather than having to go through full account recovery.
The hardest case to safe guard is an account holder with only a single smartphone as their one and only computing device. This is also the base case for the majority of the world, so we have to cover this case.
We have designed a method of using the BLS signature scheme to generate account recovery codes along with a co-signing service hosted by the Fission platform to have the user hold a backup key that can be used for recovery.
Much like email verification, we store a flag to ensure that Fission account holders go through a process of downloading account recovery codes. We especially prompt for this if only 1 device is linked.
We have had some requests that Fission make it possible to store a backup key directly in a vault system of some kind. This is under consideration, but we will initially not be storing any keys, and it will be made clear whether this is an opt-in or opt-out feature of the account system if we implement it in the future.
Account Recovery Key Flow
Early Design / User Flow Notes
- Whitepaper description of Account Recovery Account Recovery - Fission Whitepaper