1211199 - Master password can be bypassed when sync is enabled

Status: RESOLVED DUPLICATE of bug 927963

(Firefox :: Sync, defect)

Description

[bgstandaert]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150929144111

Steps to reproduce:

1. save a password in Firefox on device A.
2. Enable the "master password" feature on device A.
3. Enable Firefox sync.
4. Connect device B to the Firefox sync account, and start syncing.


Actual results:

Once you have signed in to your sync account, your saved passwords are copied to device B, but your master password is not. This means that on device B, your saved passwords are not protected by a master password, and can be accessed from preferences or from autofill. This is bad for a lot of reasons:

 - Users may not realize that master password isn't enabled. Anyone with access to their computer can access their saved passwords, but they may not realize this, since they enabled master password before syncing.
 - If I guess your sync password, I can view your passwords without knowing your master password. If you chose a weak password for Sync since it only held your history and bookmarks, but also had saved passwords, your saved passwords (which might be for financial sites, etc.)  can be viewed just by guessing the weak password.
 - Saved passwords aren't encrypted using the master password, which seems like a bad idea.


Expected results:

Saved passwords should be encrypted using the master password, so that something like this can never happen. While the immediate cause (master password not getting synced) can probably be easily fixed, the better solution would be to use the master password to encrypt saved passwords (using the same or similar key derivation used for sync passwords) so that issues like this can never happen.

Comment 1

[:Gijs (he/him)]

Mark, I tried to read bug 1013064 to understand if this is by design or whether it was part of the concerns there or not, or... something... but I struggled - it seemed it was mostly about whether or not the fxa credentials get stored in some way? Maybe I missed the point. Anyway, can you help triage this as regarding whether this is expected or not, known or not, etc. ?

Comment 2

[bgstandaert]

(In reply to :Gijs Kruitbosch from comment #1)
> Mark, I tried to read bug 1013064 to understand if this is by design or
> whether it was part of the concerns there or not, or... something... but I
> struggled - it seemed it was mostly about whether or not the fxa credentials
> get stored in some way? Maybe I missed the point. Anyway, can you help
> triage this as regarding whether this is expected or not, known or not, etc.
> ?

Is there something I can clarify about what the issue is?

Comment 3

[:Gijs (he/him)]

(In reply to bgstandaert from comment #2)
> (In reply to :Gijs Kruitbosch from comment #1)
> > Mark, I tried to read bug 1013064 to understand if this is by design or
> > whether it was part of the concerns there or not, or... something... but I
> > struggled - it seemed it was mostly about whether or not the fxa credentials
> > get stored in some way? Maybe I missed the point. Anyway, can you help
> > triage this as regarding whether this is expected or not, known or not, etc.
> > ?
> 
> Is there something I can clarify about what the issue is?

No, your bugreport is very clear. The issue was that I was trying to understand the bug where the sync-with-mp was implemented. It wasn't originally possible, in "new" Firefox accounts sync, to sync anything when a MP was set. Doing so has interesting challenges because of the double passwords and what gets synced (or deleted when you clear history, or...) which were discussed at length in the aforementioned bug, as well as in meetings, other bugs, etc., but I wasn't originally involved in that discussion and so I'm not the right person to figure out what should happen here, or if/how what you describe was foreseen/fixable, already public knowledge ("known limitation") or not, etc.

Mark (or someone else with more context than me) will respond here and figure out how to proceed.

Comment 4

[Richard Newman [:rnewman]]

Bug 1013064 is unrelated. This is a dupe of Bug 927963, which is essentially "if master password is set anywhere, it should be set everywhere".

We WONTFIXed that a long time ago, because it doesn't make sense: users have lots of reasons for enabling MP, and there would be lots of very painful edge cases if we tried to make it universal. (Not to mention crypto difficulties.) See the last comment in that bug.

I'm going to dupe this, and this isn't security-sensitive.