1562743 - Ensure that FxA and Sync work nicely with OSKeystore integration

Status: NEW

(Firefox :: Firefox Accounts, enhancement)

Description

[Ryan Kelly [:rfkelly]]

Bug 1463865 tracks a broad effort to move towards using the OS's builtin keystore facilities for storing secrets within Firefox, and its dependent Bug 1562324 is more specifically about using nsIOSKeystore for the password database.

We need to figure out how this will all interact with Firefox Accounts and Sync.

Background: when you sign in to Firefox Sync, the browser obtains a sessionToken that it uses to authenticate requests to the backend servers, and a set of encrpytion keys that it uses to encrypt your synced data before sending it up to the cloud. The sessionToken and other account profile data is stored in a plaintext JSON file on disk (named "signedInUser.json") while the encryption keys are stored in Firefox's password manager (as a special entry named "chrome://FirefoxAccounts (Firefox Accounts credentials)".

This was the best design available to us at the time, and has some important properties:

• For most users, their browser happily syncs in the background without any user interaction.
• For users with a master password enabled, the sync encryption keys are protected by that master password, in exactly the same way as their other saved passwords.
  • (For certain values of "protected" anyway, ref Bug 524403)
  • Such users will be prompted to enter their master password when launching Firefox, in order to unlock the keys needed for sync.

It has also proven to be kind of fragile in practice. We regularly get bugs about how a corrupt keystore file, or the presence of a third-party password management addons, causing the browser to unexpectedly disconnect from sync.

Bug 1463865 may be a good opportunity to revisit this design and come up with something better!

We also need to watch out for unintended side-effects. For example, if we keep the current storage scheme for FxA but we move password storage behind nsIOSKeystore, does that mean that all sync users will now need to re-authenticate when launching Firefox in order to unlock the sync keys? Maybe that's for the best, but we'll need to be deliberate about the UX involved if so.

Comment 1

[Ryan Kelly [:rfkelly]]

:markh, my bugzilla fu is failing me, could you please link the meta-bug we have for third-party password managers interfering with FxA?

Comment 2

[Ryan Kelly [:rfkelly]]

For example, if we keep the current storage scheme for FxA but we move password storage behind nsIOSKeystore,
does that mean that all sync users will now need to re-authenticate when launching Firefox in order to unlock the sync keys?

:jcj, could you please check my understanding here, would this indeed be a consequence of using nsIOSKeystore for passwords as described in Bug 1562324?

Comment 3

[Lina Butler [:lina]]

Bug 1166571 is probably the one you're thinking of, Ryan. Third-party password managers can't replace the login manager anymore, but issues with the key database can still cause problems for Sync (bug 1295122).

Comment 4

[Ryan Kelly [:rfkelly]]

Perfect, thank you!

Comment 5

[J.C. Jones [:jcj] (he/they)]

Not necessarily, no. Let me move my needinfo to Dana who can confirm here, but we had to add a special API to request re-authentication for credit cards, as by default, most platforms only require the user auth when the app changes in some way. And the mechanism we use for this would be per-profile, there wouldn't need to be a series of prompts shown to the user. (The OSKeystore is storing one secret, and then using that secret to protect everything in the profile).

Comment 6

[Dana Keeler (she/her) (use needinfo) [:keeler]]

(In reply to Ryan Kelly [:rfkelly] from comment #2)

For example, if we keep the current storage scheme for FxA but we move password storage behind nsIOSKeystore,
does that mean that all sync users will now need to re-authenticate when launching Firefox in order to unlock the sync keys?

:jcj, could you please check my understanding here, would this indeed be a consequence of using nsIOSKeystore for passwords as described in Bug 1562324?

Presumably there would be a migration step from the old storage to the new storage. Users that have an NSS ("master") password set would have to enter it to unlock the old storage to get the secret to protect it using nsIOSKeyStore. However, I don't see any reason why users would have to reauthenticate to FxA (unless of course they couldn't unlock their profile).

Comment 7

[Ryan Kelly [:rfkelly]]

I don't see any reason why users would have to reauthenticate to FxA

To clarify, I meant "re-authenticate to the OS keystore in order to unlock local storage", not "re-authenticate to FxA".

Comment 8

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Oh - J.C.'s answer stands, then (the user shouldn't need to reauthenticate to the OS just to store a new secret).

Comment 9

[Ryan Kelly [:rfkelly]]

Thanks all, this sounds promising. I think there are two potential actions coming out of this bug:

• When Bug 1562324 comes to trying to replace password storage and master-password with nsIOSKeyStore, we should walk through the FxA and Sync flows and just check that they all still feel reasonable. It sounds like there shouldn't be much change based on the comments above, but it'll be worth checking.

• Concurrently, we can think about moving sync key storage out of the password manager and into a separately-managed store protected by nsIOSKeyStore. This could be as simple as using nsIOSKeyStore to protect the sync keys and storing them encrypted in signedInUser.json, but of course we'll need to carefully design and review something here.

IIUC neither needs to be a blocker for the other.