1500843 - Firefox should store kB, rather than just the derived keys like kSync

Status: RESOLVED WONTFIX

(Firefox :: Sync, enhancement, P3)

Description

[Ryan Kelly [:rfkelly]]

In Bug 1426304, we changed the way that Firefox stores the keys linked to your Firefox Account.  Rather than directly storing the master key material "kB", it now stores only derived key material for the things it wants to do on your account, such as the sync key "kSync".

Per Bug 1426304 Comment 0, the motivation for this change was the Lockbox WebExtesion, which was going to use a key derived from kB for local encryption of data on disk.  Having Sync store kB unencrypted in the same profile would defeat the intended security of this scheme.

That reason is no longer relevant, and I've come to view the change from Bug 1426304 as a mistake.

Our Scoped Keys system [1] is designed around a certain kind of conceptual symmetry between server-side and client-side access control measures: if you old an OAuth token bearing scope "X" then you should also hold the client-side key material corresponding to scope "X".

When you're signed in to Firefox, it holds a sessionToken for your account, which is equivalently powerful to an OAuth token bearing all possible scopes.  Symmetrically, we would expect it to also hold the key material corresponding to all possible scopes, but it doesn't. It only holds the key material for the "oldsync" scope.

This asymmetry limited our design options when building the new send-tab experience, is adding complexity to the implementation of our device-pairing experience, and will soon mean that users must re-enter their password whenever they sign in to https://send.firefox.com in a signed-in browser.

I think we should revert Bug 1426304 and have Firefox store kB rather than the derived sync-related keys.  (Obviously that's going to be interesting for already-signed-in users, but we could at least opportunistically captures kB for new signins).

Nick made a kind of preemptive counter-point to this over in Bug 1426305 Comment 14:

> I thought about this while reviewing, and concluded that we _want_ the user to sign in
> (using an OAuth flow) for each new service that they use.  That is, you shouldn't be
> able to silently opt a user in to a potentially information-leaking service without a
> credential verification loop.
> 
> To me, this is a big part of the OAuth flow story, and why I've tried to support the
> "get keys via OAuth" work where possible.  We need to uniformize this stuff and stop
> special casing Sync quite so much, and this is a step in that direction

I agree with this general sentiment, and it aligns really strongly with the symmetry I talk about above.  For things where the user is specifically signing in to access Sync data (such as the Lockbox mobile app) we should only hand out the derived sync keys.  And correspondingly, we should only hand out access tokens that are scoped down to the sync service.

But signing in to Firefox itself is a bit different.  If I understand our product intention correctly, I think we intend it as more of a "connect the browser to your account" in a general sense, and less of a "connect this browser specifically to your data in Firefox sync" kind of thing.  In which case it makes sense for the browser to hold kB directly.

In more technical terms: the browser should either hold the pair (sessionToken, kB) and have full access to your account, or it should hold an OAuth token scoped specifically to sync and the corresponding sync encryption key.  Holding a full-access sessionToken and a limited-access encryption key doesn't make conceptual sense.

Nick and Matt, you had great feedback on this during the original discussion, what's your reaction to this?

Alex, I'd appreciate your thoughts on this from a product perspective, especially looking toward an ecosystem of Firefox applications rather than just a Firefox browser on several different platforms.

[1] https://docs.google.com/document/d/1IvQJFEBFz0PnL4uVlIvt8fBS_IPwSK-avK0BRIHucxQ/

Comment 1

[Alex Davis [:adavis]]

> This asymmetry limited our design options when building the new send-tab experience is adding complexity to the implementation of our device-pairing experience, and will soon mean that users must re-enter their password whenever they sign in to https://send.firefox.com in a signed-in browser.

From a product and UX perspective, this change seems to have prevented us from offering the types of user experiences people have come to expect.

IIUC, the recent changes we did result in the below limitations:

1) device pairing will currently only work for apps that want to kSync. That means that Notes could not use the pairing flow to login. If Send releases an app, they too will not benefit from that great pairing experience.

2) If we push things into uncharted territories, it would not be unreasonable for those same apps to want to authenticate to a local install of Firefox on the same device (e.g. like FB and Google do between their apps). For example, after install, Notes might detect that there is active FxA session in Firefox, user clicks to sign-in, we redirect via deep-link to Firefox for an OAuth flow, user approves the login and we redirect them back to Notes with the right keys.

3) And then there is the desktop case. If more services within the desktop browser start to use FxA with scoped keys (which I suspect could easily happen over the next couple of years), it doesn't make sense to have to ask the user to re-authenticate to each one of them to retrieve their keys.

In summary, I don't think it's unreasonable for Firefox to have the "super power" to authenticate all other apps.

Comment 2

[Matthew Miller [:m_and_m]]

My initial reaction is "oh no".  However, I understand the (new?) rationale, and the direction everything moved, the current limitations make less sense holistically.

For OAuth-based scoped-key applications (e.g., Notes), I do think having the user authorize each application does make sense.  That doesn't mean the user has to authenticate for each app, but at least having the possibility the user has to approve each app's permissions (which is ultimately what the OAuth scopes are about) seems ideal.  Today that permission approval is mostly a mostly-invisible and slightly-annoying redirect loop, but it's still valuable to allow for some form of intent verification at some point.

One of the concerns with storing kB is the perception that it compromises such scoped-key applications when they are an extension.  Storing only kSync meant it was impossible for someone else on the same computer to obtain the other scoped-keys without an actual user authentication.  This protection now goes away, but them the question: how concerning is that in practice?

It would be nice if more device-specific protections could be used when storing kB, if possible.  That at least helps mitigate that concern to cases where it's "something running as the current OS user" able to access and derive other keys.

Comment 3

[Ryan Kelly [:rfkelly]]

> For OAuth-based scoped-key applications (e.g., Notes), I do think having the user authorize each application does make sense.

I strongly agree; if the browser holds kB then we can make this a "click OK" scenario rather than a "type your password again" scenario, but we shouldn't remove the explicit authorization step.

> One of the concerns with storing kB is the perception that it compromises such scoped-key applications
> when they are an extension.  Storing only kSync meant it was impossible for someone else on the same
> computer to obtain the other scoped-keys without an actual user authentication.

Was this true for e.g. the Notes webextension?  I seem to recall is storing its key in the user's profile in a manner that was no more secure than the handling of kSync.

> It would be nice if more device-specific protections could be used when storing kB, if possible.

+1, and I know you've been working hard on this problem.  Lets discuss the current state of affairs on that front in our next 1:1.  I think I'd happily make that work a blocker for this change.

Comment 4

[Nick Alexander :nalexander [he/him]]

(In reply to Ryan Kelly [:rfkelly] from comment #0)
> In Bug 1426304, we changed the way that Firefox stores the keys linked to
> your Firefox Account.  Rather than directly storing the master key material
> "kB", it now stores only derived key material for the things it wants to do
> on your account, such as the sync key "kSync".
> 
> Per Bug 1426304 Comment 0, the motivation for this change was the Lockbox
> WebExtesion, which was going to use a key derived from kB for local
> encryption of data on disk.  Having Sync store kB unencrypted in the same
> profile would defeat the intended security of this scheme.
> 
> That reason is no longer relevant, and I've come to view the change from Bug
> 1426304 as a mistake.
> 
> Our Scoped Keys system [1] is designed around a certain kind of conceptual
> symmetry between server-side and client-side access control measures: if you
> old an OAuth token bearing scope "X" then you should also hold the
> client-side key material corresponding to scope "X".
> 
> When you're signed in to Firefox, it holds a sessionToken for your account,
> which is equivalently powerful to an OAuth token bearing all possible
> scopes.  Symmetrically, we would expect it to also hold the key material
> corresponding to all possible scopes, but it doesn't. It only holds the key
> material for the "oldsync" scope.
> 
> This asymmetry limited our design options when building the new send-tab
> experience, is adding complexity to the implementation of our device-pairing
> experience, and will soon mean that users must re-enter their password
> whenever they sign in to https://send.firefox.com in a signed-in browser.
> 
> I think we should revert Bug 1426304 and have Firefox store kB rather than
> the derived sync-related keys.  (Obviously that's going to be interesting
> for already-signed-in users, but we could at least opportunistically
> captures kB for new signins).
> 
> Nick made a kind of preemptive counter-point to this over in Bug 1426305
> Comment 14:
> 
> > I thought about this while reviewing, and concluded that we _want_ the user to sign in
> > (using an OAuth flow) for each new service that they use.  That is, you shouldn't be
> > able to silently opt a user in to a potentially information-leaking service without a
> > credential verification loop.
> > 
> > To me, this is a big part of the OAuth flow story, and why I've tried to support the
> > "get keys via OAuth" work where possible.  We need to uniformize this stuff and stop
> > special casing Sync quite so much, and this is a step in that direction
> 
> I agree with this general sentiment, and it aligns really strongly with the
> symmetry I talk about above.  For things where the user is specifically
> signing in to access Sync data (such as the Lockbox mobile app) we should
> only hand out the derived sync keys.  And correspondingly, we should only
> hand out access tokens that are scoped down to the sync service.
> 
> But signing in to Firefox itself is a bit different.  If I understand our
> product intention correctly, I think we intend it as more of a "connect the
> browser to your account" in a general sense, and less of a "connect this
> browser specifically to your data in Firefox sync" kind of thing.  In which
> case it makes sense for the browser to hold kB directly.

The existing situation (full sessionToken, partial kSync) is a half-way step to deprecating the full sessionToken and having (partial oauth token, partial kSync); it's equally valid to return to (full sessionToken, full kB), if we want that power in the browser, in which case unwinding the kSync commits make sense.

One thing that occurs: how well separated is the Firefox Account from the Sync 1.5 code in Desktop?  In Android, there's no meaningful separation; Sync 1.5 drives the Account states, owns the Account data, etc.  So if possible I'd want Desktop to have some abstraction around accounts with tokens and kB, and Sync 1.5 with derived things (like kSync).

> In more technical terms: the browser should either hold the pair
> (sessionToken, kB) and have full access to your account, or it should hold
> an OAuth token scoped specifically to sync and the corresponding sync
> encryption key.  Holding a full-access sessionToken and a limited-access
> encryption key doesn't make conceptual sense.

Is it true that the browser will have full access to your account if and when we bring kC into the product?  That is, do you have to give the browser your kC in order to sign in at all?  That means that you can't just use a few services (like, say, Pocket or something else fronted by Firefox Accounts) without turning over the keys to the kingdom.  But I'm pretty sure I do not care to support that kind of pick-and-choose access to services.

In conclusion: I think I prefer the weakest possible credentials in the Desktop product, 'cuz they don't feel secure (in our profile directory, right now).  This is by analogy with setuid executables that immediately fork a lower-privileged process.  However, it needs to be weakest possible credentials ... that enable the functionality that the Product teams want to surface to users.  Since we're not meeting those product needs, I'm on board to roll back.

Comment 5

[Ryan Kelly [:rfkelly]]

> One thing that occurs: how well separated is the Firefox Account from the Sync 1.5 code in Desktop?
> [...]
> So if possible I'd want Desktop to have some abstraction around accounts with tokens and kB, and Sync 1.5
> with derived things (like kSync).

I don't think the separation is too bad on Desktop actually; one of the advantages of not having an explicit state-machine is that we didn't smoosh the FxA state-machine and the Sync state-machine together.  This sounds like a reasonable requirement.

> Is it true that the browser will have full access to your account if and when we bring kC into the product?
> That is, do you have to give the browser your kC in order to sign in at all?

If you *sign in to the browser*, I would expect you need to give the browser "kC" in whatever form it takes.  If you want to access FxA relier services by signing in on the web (that is, signing in inside Firefox inside of into Firefox) then that should not be required.  I haven't thought deeply about the permutations here though...and I can see a case to be made for only prompting for a hypothetical "kC" in situations where it's actually required.

> I think I prefer the weakest possible credentials in the Desktop product, 'cuz they don't feel secure
> (in our profile directory, right now).

This seems to be a recurring theme (for good reason!) so let's make sure we come up with a good resolution there before going ahead with this bug.

Comment 6

[Ryan Kelly [:rfkelly]]

I'm making this a blocker for the fxa-desktop-decouple work, since we're going to want to reconsider how keys are requested and stored as part of that work. We may decide to triage it back out of there if we don't need kB for anything short term, but I wanted it in the bug tree in the meantime.

Comment 7

[Ryan Kelly [:rfkelly]]

I'm making this a blocker for the fxa-desktop-decouple work, since we're going to want to reconsider how keys
are requested and stored as part of that work. We may decide to triage it back out of there if we don't need kB for anything short term

From discussions so far, it sounds like this does not need to be a blocker for the main desktop decouple work, so I'm bumping it back out of the bug tree.

Comment 8

[janet [:janet]]

on the advice on ryan - marking as wontfix