Review the security/privacy/convenience tradeoffs of enabling send-tab whenever you're signed in to Firefox
Categories
(Firefox :: Firefox Accounts, task)
Tracking
()
People
(Reporter: rfkelly, Unassigned)
References
Details
Per Bug 1570565, we aim to decouple "Signing in to Firefox" from "Enabling Firefox Sync", so that users can easily access other Account-related features and services in the browser without having to sync all their data to the cloud.
The proposed UX for this change makes "send tab" available on every Firefox instance where the user is signed in, regardless of whether or not they've enabled sync on that device.
This will be convenient for users and is a nice bit of value-add for signing in to Firefox, but we don't get it for free. Send-tab uses the same encryption key as the rest of Firefox Sync, so if we do implement things this way then:
- Signing in to Firefox for any reason will involve an extra email confirmation loop, just like signing in to Sync does today, since this is an extra security step designed specifically to protect the Sync encryption keys.
- Every signed-in Firefox will be capable of syncing with the user's account, regardless of whether the user has opted in or not, because it will hold all the necessary credentials and keys. This might have security or privacy implications, depending on your threat model.
- This may be mitigated if we improve the security of how FxA credentials and keys are stored, such as via integration with OSKeyStore per Bug 1562743.
I'm currently feeling OK with the tradeoffs involved here, but I'd like to get a gutcheck from some security-minded folks. Paul, Greg, what's your reaction to this? Does it seem like something we should write up more thoroughly and submit for a formal secreview meeting?
(As a side note, it's also worth noting that this will only work with "new send tab", which has already been decoupled from the rest of sync. Devices in this state will not be able to send or receive tabs to Fennec or to older Firefoxes that don't support new-send-tab).
(In reply to Ryan Kelly [:rfkelly] from comment #0)
I'm currently feeling OK with the tradeoffs involved here, but I'd like to get a gutcheck from some security-minded folks. Paul, Greg, what's your reaction to this? Does it seem like something we should write up more thoroughly and submit for a formal secreview meeting?
Looks OK to me.
I'm not sure about the client side implications, but I think it's a significant enough change for formal secreview and it might make sense to review related changes while we're at it.
In particular I like having fewer signin flows, and that bug 1570565 reduces confusion around separate logins for Fx/Sync and FxA-authed services. No idea how to measure this, but I'd be curious if training users not to enter their FxA password multiple times reduces successful phishing attempts (sidenote: the slidedeck in bug 1570565 is great).
|
Reporter | |
Comment 2•6 years ago
|
||
:pauljt and I chatted in IRC and he didn't highlight any concerns; I'm clearing the ni? but Paul, please feel welcome to weigh in with any further comments at any time :-)
I'm not sure about the client side implications, but I think it's a significant enough change for formal secreview
and it might make sense to review related changes while we're at it.
OK, sounds good, I'll use this bug as a reminder to include a formal secreview as plans firm up some more.
|
|
Reporter | |
Comment 3•5 years ago
|
||
I've pulled together our proposed changes into the secreview template here:
https://docs.google.com/document/d/1oJEgHSGWgq6w14kKD7TPEgLciewkVa2LjiIjJQfd0Xs/
And will send an email as well.
|
|
Reporter | |
Comment 4•5 years ago
|
||
Just a quick note that I will be taking a couple of weeks PTO starting September 15th, while I'm out :vladikoff is the best person to coordinate with on the engineering side here. :pauljt is working on a broader secreview of FxA as a system and offered to help organize things on the secreview side.
|
||
Comment 5•5 years ago
|
||
:pauljt let me know if you want to chat about this!
|
||
Comment 6•5 years ago
|
||
:pauljt do you need any further info from our team, we're hoping to land our changes in Fx71.
Sorry for no update - I'm working on it (and other parts of FxA as part of our shifting our team to services work). I'll prioritise this piece and get it closed out asap, should be in the next day or so.
Hi all, I've finished this review - I took the liberty of expanding this to "considering all the threats relating to the fxa/sync decouple".
Summary of findings:
- To the original question: are there concerns about the trade-off of having the credentials available to Sync, even if Sync is disabled? The local attacker threat is a complex one, and I don’t think it makes much of a difference, if you take into account the browser as a whole (especially including about:logins, and the protection of stored password).
- We still support an FxA login flow which enables sync. This flow works, even if you are already signed in to FxA with with Sync disabled. Websites might use this to trick a user to enable sync - but this probably doesn’t gain the attacker anything directly, so its probably not a huge risk, but something to consider.
Additional findings unrelated to this change:
- MTIM attacker can subvert http resources loaded into privileged process (http://addons-amo.cdn.mozilla.net/ is http and https://addons.mozilla.org uses STS but doesn’t have includeSubDomains set. Both domains are currently on process allowlist)
- Isolating accounts.firefox.com in its own process is undermined if a compromised process can just grab the user’s FxA password out of the password manager (which is currently possible)
Full notes: https://docs.google.com/document/d/1IreOtfwdxnw7kiMsCNcmXWj2fLFtGh9Zcl6-TXJnwuk/edit#heading=h.dlalftvp40q2
TLDR: There are some improvements I will file elsewhere (unrelated to this change), but the risk trade-off from comment 0 sounds reasonable to me.
|
|
Reporter | |
Comment 10•5 years ago
|
||
Thanks :pauljt! I'm going to close this bug out, and we can follow up on the above improvements in separate issues as you file them.
Description
•