Secure your Lockbox: FxA as master password and to allow sync

[sandysage]

As a Firefox Account user, I find the password manager is optimized for me such that I can set it up in 5 clicks or less, and retrieve and fill my credentials in 3 clicks or less.

Acceptance Criteria

• An account is not required to get started using Lockbox
• FxA sign in & create account flows are Lockbox specific
• Sign in flow removes the user from their Lockbox context as little as possible
• User has to authenticate every time they quit and restart the browser
• If a password reset happens, Lockbox can still authenticate the user with the new password but they do not have access to any previously stored data
• If a password change happens, Lockbox can still authenticate the user with the new password with access to all their previously stored data

Expected behavior

1. Install Lockbox
2. Create an entry
3. With an entry in place, persistent call-to-action appears to sign-in or create a Firefox Account (not required)
4. If the user decides to, "Secure your Lockbox", a pop-up window appears with either the sign-in or create account flow
5. Sign-in: user signs in via the pop-up. the pop-up window closes upon sign-in leaving the user back on the editor
6. Create account: users completes the FxA creation in the pop-up window, which directs them to verify their account via email. User manually returns to the editor in the opened window/tab.
   • NOTE: Having to click a link in the email confirmation flow, means users can get derailed from the signup process. FxA team is experimenting with having the user type in a code rather than click on a link.
7. Click "sign-out" or close the browser
8. Reopen Firefox
9. Click on the toolbar icon
10. FxA login appears in pop-up window

• NOTE: It's preferred that this flow appear in a doorhanger UI rather than a pop-up window (as seen in the visual design Invision link)

11. Sign in

• NOTE: It's strongly preferred that this flow does not force the user through an email confirmation loop, since this is just "re-authenticating" to an existing device.

12. Pop-up closes upon sign in
    *NOTE: Based on current limitations, need to determine if it's better to land the user on the fullscreen editor upon sign in versus having to click the toolbar icon twice (once to prompt the FxA sign in pop-up, and second to prompt the list view)

Visual Design

https://mozilla.invisionapp.com/share/54E2A6ZKF#/screens/

Context

The concept of a master password as one password that would give access to many more passwords is generally understood by users. But it's unclear if that's just as understood when a user needs to have an account to sync their data to different devices. Do users accept creating and managing both an account (with a password) AND a master password?

The hypothesis here is that users want less to manage and understand that their data is secured by their Firefox account access. And that this proposed flow matches already existing workflows around using a federated identity to access other accounts (ie can log into an account using Google or Facebook sign-in).

Extension (Alpha) Tasks

• Use binary keys to protect data lockbox-datastore#52 to implement "key from FxA"
• OAuth flow with scoped keys in extension to replace master password Replace master password with FxA #363
• update OAuth details to point to production Update OAuth Details to FxA Production #174
• ability to "Lock" (Sign Out) Allow user to "Lock" editor via "Sign Out" to prevent unwanted access to Lockbox data #149
• first run (replace master password from Secure your Lockbox: FxA as master password and to allow sync #209) with Update first-run editor #292
• update architecture docs Update FxA integration document mozilla-lockwise.github.io#12

Sync

• Cloud storage of saved credentials so that they can be accessed from any supported platforms (a single database of credentials for each user) lockbox-datastore#50 to implement sync

Mobile

• OAuth flow with scoped keys in iOS app FxA OAuth flow lockwise-ios#52

Future?

• offline key flow handling for extension?
• offline key flow handling for iOS app?
• password reset handling?

[sandysage]

Per emails with FxA:

• Users can install the webextension and start using it locally without linking their Firefox Account. It will store their data locally but not attempt to put it in The Cloud.

• Once they're using the product, users may be prompted to connect their Firefox Account to get backup and/or syncing of their passwords.

• This will launch the FxA OAuth flow in a popup window, and we expect a significant number of users to have to create an account at this point.

• This will use the new scoped-keys flow to obtain a Lockbox-specific encryption key, to be used for encrypting data locally.

• This will obtain an OAuth token for access to a storage backend running Kinto, into which Lockbox will sync the encrypted data from its local storage.

• When the user closes Firefox, Lockbox will discard its encryption keys, but keep some of the othe state around from the OAuth dance in order to make re-authenticating easier.

• When the user re-opens Firefox and tries to access their Lockbox data gain, Lockbox will do another FxA login flow to re-authenticate the user

• This will use the new scoped-keys flow to obtain the same Lockbox-specific encryption key as before, so the user can decrypt their locally-stored data.

• It's preferred that this flow appear in a doorhanger UI rather than a pop-up window.

• It's strongly preferred that this flow does not force the user through an email confirmation loop, since this is just "re-authenticating" to an existing device.

• If the user happens to try to access their Lockbox data while they're offline, they'll get a connection error when loading the FxA OAuth flow.

• Having to click a link in the email confirmation flow, means users can get derailed from the signup process. FxA experimenting with having the user type in a code rather than click on a link.

• If the user is signed in to Lockbox on a device, and then does a password reset on their Firefox Account, then Lockbox will discover this when it next tries to sync and finds that its OAuth tokens have been revoked. It will enter some sort of "needs re-auth" state and prompt the user to sign in again.

• If there was a password reset user encounters another email-confirmation loop on this device

[devinreams]

@sandysage to help drop in designed/desired flow here

may need separate tasks here real quick..

[hmcgaw]

@sandysage @changecourse Is there a design for this? I'm working on recommendations and it would be helpful to understand how the current master password creation will change. My understanding is that creating a master password will be replaced by the FxA creation flow, is that right?

[devinreams]

Is there a design for this? I'm working on recommendations and it would be helpful to understand how the current master password creation will change

@hmcgaw just to close the loop, I know you have this, but the planned design is in the Invision doc: https://mozilla.invisionapp.com/share/54E2A6ZKF#/259383381_0-0_Add_Lockbox

[devinreams]

This will launch the FxA OAuth flow in a popup window, and we expect a significant number of users to have to create an account at this point.

@linuxwolf @sashei do you two have corresponding sub-tasks or issues opened for the extension (datastore?) and iOS app to track the exploration and OAuth work yet so we can add it to the epic list above?

[linuxwolf]

@linuxwolf @sashei do you two have corresponding sub-tasks or issues opened for the extension (datastore?) and iOS app to track the exploration and OAuth work yet so we can add it to the epic list above?

• Use binary keys to protect data lockbox-datastore#52 to implement "key from FxA" (added by me)
• Cloud storage of saved credentials so that they can be accessed from any supported platforms (a single database of credentials for each user) lockbox-datastore#50 to implement sync (added by @devinreams )

[sandysage]

@changecourse I think the workflow articulated here is as defined as we're expecting for now, right? If so, let's remove the "needs-ux" label, knowing that other tasks may need your involvement.

[changecourse]

@sandysage I think that's true... Removing the label...