Account Recovery

[boris]

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.

---

Thank you to @expede, @benjaminbollen, and @dholms for specification and security design.

Account Recovery Key Flow

Early Design / User Flow Notes

Resources

• Whitepaper description of Account Recovery https://whitepaper.fission.codes/identity/account-recovery

[samuelandert]

Nice, I like, where this is going.

[boris]

I captured how Matrix’s Element client handles this:

Element (Matrix Client) "Secure Backup" Screenshots

Using the web-based “Element” app to connect to Matrix servers, I took screenshots of the prompt to setup Secure Backup. This is equivalent to Fission’s Account Recovery. → account recovery is probably the right name for the recovery half of this process. Secure Backup as the name of storing recovery codes is good. A couple of notes: User can choose between a secure key and a security phrase. → Why have a choice? We will default to a key. Main login into Matrix is via username and password. …

Would love to see screenshots on how other systems do this, as well as any wording or messaging.

[boris]

Here is Trust Wallet’s backup process, and here are their Best Practices for Storing Your Recovery Phrase.

Skipping the paper and password manager options, here’s what they say about mobile devices:

Note taking Apps like Notes for iOS, Samsung Notes for Android or OneNote let you create notes protected with a password. If you don’t want to use a Password manager, storing it inside a password protected (and encrypted) note also works.

[gyuri-lajos]

@boris

storing it inside a password protected (and encrypted) note also works.

or a WebNative FS folder in the private part.