1447656 - Setting up Sync should not rely on webpages

Status: RESOLVED DUPLICATE of bug 1034526

(Firefox :: Firefox Accounts, defect)

Description

[Wladimir Palant]

Firefox Sync is supposed to be safe even if the relevant Mozilla servers are compromised. This promise is currently subverted by the Firefox Accounts signup/login when Sync is set up. Instead of using the onepw protocol directly, Sync expects the user to enter their password on a webpage. If the Firefox Accounts content server is compromised and somebody manages to inject a script into that page the attackers will get the password as plain text. After the initial sync they will be able to download all of user's data and decrypt it. With something that critical, the login and registration flow should be part of the browser UI.

Comment 1

[Ryan Kelly [:rfkelly]]

Hi Wladimir, thanks again for your ongoing examination and reports about the service!

I'm going to dupe this to Bug 1034526, which has a different take but is about the same underlying concern.  Please feel free to re-open if that bug doesn't seem to match up with your concerns here.

I also want to add a few words about why things are implemented this way, since the topic does come up from time to know.  I know from experience that some folks find the points below less convincing than others, but hopefully they'll at least convey the carefully-considered set of tradeoffs that got us to where things are today.

The reason the login form is delivered as web content is to increase development speed and agility.  You're right that web content has a larger potential attack surface than code that's built into the browser, but using web content also brings other kinds of security *benefit* that may not be obvious.  That agility meant that during the incident in [1] we were able to respond quickly and effectively to protect users data, and to roll out an updated login flow containing an email confirmation loop.  It means that when we ship two-factor authentication over the coming weeks, it will be immediately available to all users on all platforms.  It means we can address Bug 1320222 in a single place and be confident we won't lock out older devices.  And it means we can easily bring new Firefox apps like Lockbox into the Firefox Accounts ecosystem.

Our approach has been to embrace the benefits of web content while trying to reduce the potential attack surface as much as possible.  That includes some simple things like hosting the web content on its own server to reduce exposure to application server bugs, and shipping default HSTS and HPKP settings for the accounts.firefox.com domain.  It also includes some in-browser measures to prevent interference with FxA web content, such as (the currently private) Bug 1415644.  As a future step I'd like to see us implement content-signing for accounts.firefox.com and have it enforced by the browser, following the example of things like Bug 1437671.

Ultimately I think we can have web content from accounts.firefox.com be just as trustworthy as, say, a Mozilla-developed addon which might ship in the browser by default, which is a pretty high bar.  We're not there yet, but it seems worth pursuing to try to get the best of both worlds.

[1] https://blog.mozilla.org/services/2016/04/09/stolen-passwords-used-to-break-into-firefox-accounts/

Comment 3

[rugk]

> Ultimately I think we can have web content from accounts.firefox.com be just as trustworthy as, say, a Mozilla-developed addon which might ship in the browser by default, which is a pretty high bar.  We're not there yet, but it seems worth pursuing to try to get the best of both worlds.

Maybe something like https://github.com/tasn/webext-signed-pages would nearly be able to accomplish it? Sign all webpage code.
I guess this is what you mean with "content-signing".

However, that said, I still think shipping it as part of the browser is the most consistent and easiest security strategy. It has low complexity and it also allows you to go throw all the QA testing of the Firefox browser itself.
I, for instance, also don't think it's bad if you have to wait some months for a new FxA feature. Why not? it's just more time that this is tested and it works.

Comment 4

[Ryan Kelly [:rfkelly]]

Thanks for the feedback; please direct further comments to Bug 1034526 which has slightly broader context.

> However, that said, I still think shipping it as part of the browser is the most consistent and easiest security strategy.
> [...]
> Why not?

A brief and incomplete answer to "why not?" is that Firefox Sync is not the only consumer of Firefox Accounts authentication.  It would be fine to have the login UI for Firefox Sync builtin to Firefox, but what about the login UI for addons.mozilla.com?  For Pocket? It starts to hit thorny trade-offs pretty quickly when taking multiple different consumers into account.

Comment 5

[Mahdi]

You can give the visitor the option to either use web-based sign-in form or hard coded one (in Firefox). Mega.cz has done that. (At least they have understood security importance of hard-coded form for users)

And advantages of hard-coded sign-in form over "content-signature" headers are:
1- In cases like if china government (or my country Iran) make a deal with Mozilla for spying citizens. A signed copy of installation file (which include sign-in form) give users assurance that they would have a downloaded evidence in hand if Mozilla did a wrong action
2- Check-sum of a Firefox installation file (which have sign-in form inside) can be compared to other sources