Account management should be client-side

RESOLVED DUPLICATE of bug 1034526

Status

Cloud Services
Server: Firefox Accounts
RESOLVED DUPLICATE of bug 1034526
3 years ago
3 years ago

People

(Reporter: Steven, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151110142142

Steps to reproduce:

Go to about:accounts, clicked sign up.


Actual results:

about:accounts loaded a sign up frame in an iframe


Expected results:

I expected the client-side signup code (and the rest of the account management client-side code) to be bundled with the Firefox browser itself.

Firefox shouldn't blindly trust this code fetched from the server. It's supposed to be impossible for the accounts server to get the user's password and decrypt the user's sync data however, as is, an attacker could modify the server to inject some malicious JavaScript into these account management forms to steal the user's password.

According to the announcement,

> Given the importance of your password, we’ve designed Firefox Accounts such that Mozilla’s services never see your password’s clear text. Instead, Firefox first strengthens the password through client-side stretching with PBKDF2, and then derives several purpose-specific keys via HKDF. Neither your password nor the derived “unwrapping” key are ever transmitted to Mozilla. You can read more about the protocol in its technical description on GitHub.

This is incorrect. *Firefox* doesn't do the key-derivation. Firefox runs some code provided by the Account Server that's supposed to do the key-derivation but this code is really free to do whatever it wants.


Note: I understand that the Firefox codebase could also be compromised but I assume the Firefox codebase is stored in a secure VCS and I know that releases are signed. Basically, I can audit the Firefox codebase, I can't audit the account management javascript every time I download it.

I apologize if this is in the wrong section.
Thanks Steven.  There's been quite a bit of discussion internally about the pros and cons of the current approach, and it's not something we jumped into lightly.  You may find the discussion in Bug 1034526 interesting.

FWIW, we do have several additional layers of security against attacks here, e.g. client-side cert pinning and server-side process separation.  We may explore more in the future, e.g. deterministic builds with subresource integrity assertions to improve auditability.  I doubt you'll find them compelling, but I hope to convince you that we've thought long and hard about this setup.

> Basically, I can audit the Firefox codebase,
> I can't audit the account management javascript every time I download it.

Note that the iframe is only used during initial establishment of the connection, once you're signed in to the browser the day-to-day process of syncing does not load dynamic code from the server.

> I know that releases are signed

As an aside, finding a way to sign releases of FxA would be an interesting way to add some additional security around this process.

> Firefox shouldn't blindly trust this code fetched from the server.

Practically speaking, I don't think there's much chance of transitioning from web-content to native UI for the signin flow, the dev-process advantages of working in web-content are simply too compelling.  In fact if things go to plan, we will soon be replacing the native signin flow on Firefox for Android with a similar iframe-based approach.

However, I'd like to explore other ways to give you the properties you're looking.  From the description it sounds like you're concerned most directly about the security of the encryption key, rather than the login process as a whole.  Would the option of a separate encryption key, managed solely by the browser rather than code from accounts.firefox.com, give you what you want here?  (Although we don't have concrete plans to implement that, it's something we've talked about a few times in the past).
(Reporter)

Comment 2

3 years ago
> Note that the iframe is only used during initial establishment of the connection, once you're signed in to the browser the day-to-day process of syncing does not load dynamic code from the server.

That makes me feel somewhat better.

> As an aside, finding a way to sign releases of FxA would be an interesting way to add some additional security around this process.

You may be interested in mylar (http://css.csail.mit.edu/mylar/) but it's not really a practical short-term solution.

> Practically speaking, I don't think there's much chance of transitioning from web-content to native UI for the signin flow, the dev-process advantages of working in web-content are simply too compelling.  In fact if things go to plan, we will soon be replacing the native signin flow on Firefox for Android with a similar iframe-based approach.

Is it not possible to simply ship the relevant javascript, css, and html with the browser? I guess this does freeze the server-side API (can't assume that the client is up-to-date).

> However, I'd like to explore other ways to give you the properties you're looking.  From the description it sounds like you're concerned most directly about the security of the encryption key, rather than the login process as a whole.  Would the option of a separate encryption key, managed solely by the browser rather than code from accounts.firefox.com, give you what you want here?  (Although we don't have concrete plans to implement that, it's something we've talked about a few times in the past).

That would be fantastic! It's less user-friendly than the old PAKE scheme but it would give me the security I'm looking for.
> It's less user-friendly than the old PAKE scheme

FWIW we may eventually try to bring a pairing flow of some kind, as an option rather than as the default setup flow.  But we've got plenty of other things we want to get to first.

> Would the option of a separate encryption key, managed solely by the browser rather
> than code from accounts.firefox.com, give you what you want here? 

In this case, I'm going close this bug in favour of the older Bug 1034526, which basically asks for the same thing and has more context and discussion.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1034526
You need to log in before you can comment on or make changes to this bug.