Auth Lobby Account Recovery
1/ Who will benefit from this idea? Define the audience, what they care about, what motivates them.
- people developing apps that use Fission to store private data in WNFS
- people using Fission-enabled applications who store private data in the application, regardless of whether they understand that they are using Fission under the hood or not.
2/ What is the problem or opportunity? What do people want to accomplish and why?
Today, if someone using Fission Auth loses their auth “session” across all devices, all of their private data is unrecoverable.
3/ What is the most important benefit to people? The most important, directly addresses problem raised in previous answer, augmented with 3 supporting benefits.
The ability to recover private data in the case where all current fission sessions have been lost.
The ability to message to people using the system that if they lose all of their devices, there is a way to recover their data.
The ability for organizations using the system to document and plan for disaster recovery scenarios.
4/ How do you know what people want? Substantiate your claims of knowledge.
- We get email support messages from people who lost private data in Fission and are upset about it.
- We get feedback from app developers concerned about being able to support customers who have lost auth access.
- competitive analysis of similar encrypted personal data systems ( 1password, etc ) reveals that account / data recovery is a prominent feature that is well documented in support materials.
( TODO: identify sources of actual feedback )
5/ What does the experience look like? Narrated mock-ups that describe the experience of a person using this feature.
5.a/ App Developer use case
When a developer signs up for a fission app publishing account, they are asked for a working email address. At this registration opportunity fission sends an email to the developer with a unique activation code in order to confirm the email address.
When the developer confirms their email address, we then send a second email to them with additional information to get them started. In addition to this, we will also send them a recovery key and instructions on how to recover their account including any private data using this key.
When we provide this key, we should provide it in such a form that optimizes a mobile-enabled recovery flow by providing the key using a QR code. We should also allow an ascii text version of the recovery key that can be used to copy and paste into a text field.
By sending an email with the recovery key to someone, by default we are storing the recovery key in their email inbox and they are therefore protected by the same security measures the user has applied to their email account - that by default the data stored in the user’s fission account is only as secure as the data in their email, with the following implications:
- as long as the user has access to the email account and has retained the email, they will be able to recovery their account and their data.
- if the user’s email account is compromised, the fission-stored data could be exposed - assuming the user retained the original recovery email stored in their account.
- the user has the opportunity to strengthen their privacy and security by taking additional measures to back up their recovery keys in other systems[1].
[1] Other systems - for our purposes this is only vaguely defined. One could imagine various strategies that are workable: forwarding the email to an additional email account, printing out the QR code or pasting the QR code file or code into a secure storage solution such as 1Password.
Disaster types supported:
- loss of all devices that maintain Fission sessions
Disaster types not supported:
- loss of all sessions as well as loss of the recovery key or recovery kit.
Recovery flow
- developer has lost access to their fission account.
- developer retrieves recovery code and scans / enters the code in the account recovery page provided by fission.
- fission sends a reactivation email
Security concerns
For the most part this proposal is designed to be secure enough for most users, with obvious paths to making this more secure by ( for example ) storing the recovery key in a more secure location than their email account or in the simplest case, adding MFA support to their email account.
We are concerned about scenarios that involve recovery keys being exposed to browsers running browser extensions in ways such that a widely deployed malware extension could harvest large numbers of recovery keys over time.
FAQ
Q: What if the recovery key is lost for all time?
A: Fission has an alternative email-enabled flow that re-instates the top-level name and public files for a given account but cannot recovery encrypted data.
Links
