Closed Bug 927963 Opened 11 years ago Closed 11 years ago

Master Password should Sync between devices

Categories

(Firefox :: Sync, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: patrick.seiter, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130910160258

Steps to reproduce:

1. Set up Sync on a Firefox profile.
2. Set a Master Password.
3. Sync to another device.


Actual results:

The master password is not required to view passwords on the new device.


Expected results:

The master password should have been required to view passwords on the new device, i.e. it was synced.
My gut instinct tells me that there's a security reason why this is not done, but I did not find a bug report that could explain as much.
I don't think it is possible to copy the master password to another machine, since there is (I hope!) no plaintext copy of that.

BUT, if you sync a master password protected password store to one without MP protection, FF Sync should warn you and provide the possibility to set MP in the newly synced profile.
No, I mean it should sync the hash of the master password to your other machines. I just changed the master password on my laptop and it will not propagate to my mobile device, for example.

There is a prevailing argument that for some reason the master password is "local" and therefore Sync will not touch it. What's local about it? I use a master password to protect the passwords that sync across all my machines. That's not local, it's an inconvenience. I shouldn't have to change my master password on all of my devices.
(In reply to Martin Pecka from comment #2)
> I don't think it is possible to copy the master password to another machine,

It's definitely possible to do, in theory.

(Hand waving a bit, but you could (in theory) synchronize the *encrypted* versions of the passwords, plus a hash of the master password, and then the other system would be able to verify your MP against the hash and use it to decrypt the sync'd encrypted passwords.)

> BUT, if you sync a master password protected password store to one without
> MP protection, FF Sync should warn you and provide the possibility to set MP
> in the newly synced profile.

That's bug 540975 (which I agree would be nice to fix), not this bug.

(In reply to Patrick Seiter from comment #3)
> I just changed the master password on my laptop and it will not
> propagate to my mobile device, for example.

So for me personally, that's actually a feature. I don't *want* to use the same master password on my desktop as on my mobile device.  On my desktop, my master password is ~15-20 characters long, since I can easily type that many characters and might as well use a long password for extra protection. (This may be particularly important if I share the machine with other folks who have local accounts and I'm marginally worried about them snooping on my profile data).  On my phone, the security model is different (not a shared device, the screen locks automatically after a few seconds, full-disk encryption is available with the press of a button on newer Android versions), *and* it's much more difficult for me to correctly type a long master password (e.g. fat-fingering is likely, and special characters can't be typed unless you enter a different keyboard mode).

This bug would effectively *force* Sync users to use the same MP on all devices (particularly across mobile vs. desktop), and I think that's unnecessary and in many cases (like mine) undesirable.
> it's much more difficult for me to correctly type a long master password
> (e.g. fat-fingering is likely, and special characters can't be typed
> unless you enter a different keyboard mode).

(To be clear -- this ^^^ is the main difference that justifies the "different MP on desktop vs. mobile" use-case, for me. The security model differences are also interesting to consider and make me feel better about using a shorter password on my mobile device, but they're really somewhat tangential.)
I think this is undesirable for several reasons.

1. This puts your Sync client in a position of being able to control your master password. A coding error or an attack on Sync could lock you out of your passwords on your local device, not to mention introducing some sizable complexity.

2. Mandating MP on different devices is undesirable or impossible. Third-party clients might not support any such mechanism, for one thing. For another, consider that my Android phone supports strong OS-level protection; I use MP on my desktop because it's cheap and easy to do, but I don't use it on my phone because it prevents password sync altogether, and the protections that Android offers are stronger than MP, making it unnecessary.

3. Mandating the same MP on different devices is foolish from a UX perspective; it's likely to drive down the strength of passwords on desktop, rather than driving up the strength on mobile devices where keyboard entry is more difficult.

4. I don't even know if we're able to do this from within Sync. It would probably be difficult, and that's work I can't support doing, given that (a) so many of us want to kill MP altogether, because it sucks, and (b) we're not working on the existing Sync codebase.

5. Regarding the assertion that underlies Bug 540975, which is essentially "if a user turns on MP, we should warn them that they're less secure elsewhere": that kinda implies that we should *always* warn the user that their password storage is weak, regardless of if they use Sync! I would rather put effort into the general solution.


As such, I'm going to close this as WONTFIX, but thanks for starting the discussion!
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Three years later and with more knowledge on how the sync system works, I see how terrible an idea this was. Thanks for the input and broadening my horizons guys.
Component: Firefox Sync: Cross-client → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.