Closed Bug 711636 Opened 13 years ago Closed 4 years ago

Master password support for Android Sync

Categories

(Firefox for Android Graveyard :: Android Sync, defect, P5)

Product:
Firefox for Android Graveyard
Component:
Android Sync
Platform:
All
Android
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: jvoll, Unassigned)

References

Details

Fennec's content provider stores encrypted passwords. Sync needs plain-text passwords so that we can encrypt them our way when sending them to the server. Therefore we much encrypt/decrypted usernames/passwords to match Fennec's content provider. Right now the obvious places for this to occur are: -decrypt in RepoUtils.java in passwordFromMirrorCursor() -encrypt in AndroidBrowserPasswordsDataAccessor in getContentValues() Both of these places have been marked with this bug number in the code.
Blocks: 709835
No longer blocks: 709835
Blocks: 709385
Sriram, can you give us an update on where we stand with this?
One of the ideas was to provide an UI that can ask the user for the "master password" to key in. This can be a parameter in the URI request from Sync.
(In reply to Sriram Ramasubramanian [:sriram] from comment #2) > One of the ideas was to provide an UI that can ask the user for the "master > password" to key in. This can be a parameter in the URI request from Sync. Short-term I'm more concerned about the non-MP situation; AFAIK Fennec always encrypts, just with a null password. So: * Can we detect when there's an MP set? If not, please file a bug for that :D * How can we encrypt and decrypt when there isn't? That's this bug. * How do we present an interface to decrypt when a master password is set? Most likely that'll involve Fennec providing something like this interface: http://developer.android.com/reference/android/accounts/AccountManager.html#getAuthToken%28android.accounts.Account,%20java.lang.String,%20android.os.Bundle,%20boolean,%20android.accounts.AccountManagerCallback%3Candroid.os.Bundle%3E,%20android.os.Handler%29 so that we can ask for a token and have a small, doesn't-load-the-world Java component get-and-verify the user's MP. That's future work, IMO. In short: how can we get the minimum shippable set of stuff done to land password sync?
Depends on: 704682
Priority: -- → P2
Filling in a missing dependency link.
Depends on: 718760
blocking-fennec1.0: --- → beta+
I took care of basic password stuff in bug 718760. Repurposing this bug, and removing the blocking flag since MP-Sync isn't required for 1.0.
blocking-fennec1.0: beta+ → ---
Summary: Add encrypt/decrypt to password sync → Master password support for sync
This is still marked as blocking the passwords engine. Chenxia, wesj, does this still block landing the engine? If it does not, please decouple the bugs. :)
As I said one line above, master password support is not required for 1.0.
No longer blocks: 709385
Priority: P2 → P3
Think of this as a ping to start thinking about how we want to address background syncing with MP enabled. An idea I've had in the past (and wrote up in a bug somewhere) is for Fennec to send a passwords-only sync intent to Sync when MP is unlocked, passing with it a short-lived token. That token can then be passed back into the passwords CP to allow for appropriate encryption/decryption of records. We can also support a mechanism as described in Comment 3, where if you haven't managed to sync in a while, we ask Fennec to ask the user to unlock their MP.
Depends on: 757646
Priority: P3 → P2
Summary: Master password support for sync → Master password support for Android Sync
We would like to start moving on this as soon as we can, because it causes a really degraded experience for a broad swath of users.
Priority: P2 → P1
My plan was to throw away MP support as soon as we have sign-in to browser support. But sign-in to browser was moved down on the priority list for k90 yesterday.
(In reply to Wesley Johnston (:wesj) from comment #10) > My plan was to throw away MP support as soon as we have sign-in to browser > support. But sign-in to browser was moved down on the priority list for k90 > yesterday. I imagine the underlying mechanism would have to be similar -- we need to remotely encrypt and decrypt records without handling your credentials, regardless of whether it's a discrete MP or implied crypto via Persona.
Sign in to browser will not encrypt. I'd vote for just killing encryption then. Cracking signons.sqlite takes a machine with a few hours of processing time and the skill at searching for "Firefox password breaker". Its (IMO) pretend security.
(In reply to Wesley Johnston (:wesj) from comment #12) > Sign in to browser will not encrypt. I'd vote for just killing encryption > then. Cracking signons.sqlite takes a machine with a few hours of processing > time and the skill at searching for "Firefox password breaker". Its (IMO) > pretend security. I seem to recall bsmith having some informed opinions on this -- Brian, is there any existing bug/direction/discussion around killing MP?
Any news on this?
Richard, if it were up to me, no variant of Firefox would have Master Password support, and instead we'd rely on the OS's PIN/account password/unlock support. However, I am not very well informed about sign-in-to-the-browser (SITTB) and what we're expecting that experience to be like. If it is like Chrome's experience then my idea of relying on the operating system's sign in mechanisms won't work well. Clearly, you don't want to sign into the browser on somebody else's computer and have all your passwords and whatnot stored unprotected on their computer. So if (SITTB) won't encrypt data as asserted in comment 12, then how are we planning to have this work? In general, I am not sure to what extent we're planning to have SITTB support a "guest mode" on various types of devices. I think it is important to figure out how those things will work before we do any ripping out of encryption, lest we just end up needing to add it all back later.
Yeah, SITTB got punted on for Desktop (for now, at least), but when it was still under consideration the thought was that the first version (at least?) would not be doing any kind of profile encryption -- it was just a mechanism to pull down your profile from the cloud, not a local security mechanism. (It's unclear if this would be a feasible guest-mode, at least not without a bunch more work.) I think that's likely an awkward long-term stance, but it's a reasonable first step. Master Password has never worked very well, it's the wrong solution to the wrong problem. (Or, more generously, it's an ok-ish solution to the very narrow problem PKCS#11 tries to solve.) To do it right we need to step back and define what we're trying to solve, and how we're going to solve it in a more usable way. I'm pretty sure the existing MP won't be part of it, but we'll see.
I would add that if Master Password is used then sharing tab over Sync won't prompt for password and displays empty screen. You have to find a page that will trigger Master Password prompt (which might be not that easy either (see bug #780463)) and then you can return to sharing option and all your other devices are now shown.
Will Master Password with Sync be supported in the near future? If not, what is the recommended way of keeping Firefox passwords downloaded via Sync secure on an Android device?
Sync is mostly in maintenance mode as there is work to write a Persona based Sync service. The work around is to remove the master password. Perform a Sync. Then re-add the master password.
CCing a couple of the PICL folks so that this is in the back of their minds. Summary: you can't get to Fennec's stored passwords if MP is enabled.
Product: Mozilla Services → Android Background Services
(In reply to Kevin Brosnan [:kbrosnan] from comment #20) > Sync is mostly in maintenance mode as there is work to write a Persona based > Sync service. Btw., this is https://wiki.mozilla.org/Services/Sync/NextGen .
Presumably we'll end up doing this by moving all of our password infrastructure into Java-land, and wrapping it in Android-native unlocking stuff that will work with our CP. And that way we also get to kill the separate password CP process.
Depends on: 946857
Hardware: ARM → All
Priority: P1 → --
Has any progress been made on this issue? I just got an 'advert' in Firefox for Android telling me that I could sync Master Password across all my devices. Does this mean it's working now?
No, there is no support yet. I'm not sure if there ever will be for master password. The about:home snippet that you [1] saw was falsely configured to show on mobile instead of desktop. [1] "Set up Sync on Firefox to keep your settings, bookmarks and passwords organized."
That is not the snippet I'm seeing, and which I think Ben is referencing. What I'm seeing says "Firefox master password works across your devices. Set your master password today."
Yes that sounds like the one I saw
The syncing of master-password-protected saved passwords does now seem to work on the desktop, at least as of v35. From reading some of the tickets related to that support, it sounded like it sync'd the encrypted passwords, and so required the MP to be the same across installs. But that would also mean it doesn't need to decrypt the passwords in order to sync them. I don't know if this is correct, however. I setup some test profiles on the desktop to test / prove to myself that the new sync system now can sync MP-encrypted passwords, but doing the same on Android is ... difficult, at least for me, since I don't want to lose my "old sync" setup if it doesn't work.
(In reply to Matthew Gabeler-Lee from comment #29) > From reading some of the tickets > related to that support, it sounded like it sync'd the encrypted passwords, > and so required the MP to be the same across installs. But that would also > mean it doesn't need to decrypt the passwords in order to sync them. I don't think that's the case. Sync will require MP to be unlocked, and will retrieve cleartext passwords, which it will wrap with Sync's own encryption chain. Nothing about the Sync password engine is expecting encrypted passwords, and bad things will happen if that's the case. > … but doing the same on Android is ... difficult, at > least for me, since I don't want to lose my "old sync" setup if it doesn't > work. Each Firefox channel -- Nightly, Aurora, Beta, release -- has its own Sync accounts on Android. So long as you're testing a different channel, you can test with impunity.
Blocks: 1213688
NI myself to investigate current state of MP visa vis Sync.
Flags: needinfo?(gkruglov)
My summary of MP and Sync is pretty much Comment 30. I'll add a personal note, after trying this out, that the current implementation MP is pretty much unusable from UX point of view. I lasted less than one day with it enabled. Prepare to see MP prompts seemingly out of nowhere whenever sync is running in the background, with absolutely no indication as to what's going on. We should really kill this half-baked feature.
Flags: needinfo?(gkruglov)
From triage: Can we review the decision to keep the master password on Android?
Flags: needinfo?(jcheng)
IMO, MP on Android is a key differentiating feature for Firefox. The security level associated with my saved passwords is very different from my phone lock screen. I would not want to be faced with the choice of putting an MP level password on my phone unlock vs. having my saved passwords protected by something as weak as my phone unlock. MP and the ability to run an ad blocker are nearly the only things Firefox on Android has going over alternatives in my view. Please don't let the perfect be the enemy of the good here. I hardly think the appropriate solution to a UX that needs work is to remove security protections on the most easily lost or stolen device the user owns. And I don't think the MP prompts are really all that cumbersome. Yes a little confusing, but they are trivial to dismiss and they don't come back for a fair while. While this could surely be improved, I don't think it's a deal breaker for the security conscious user.
+1 on what Matthew said. Using MP for years and it is one of my go-to features in FF and one of the reasons to use Sync at all (even though its weaknesses have been discussed)
Thanks for chiming in, Matthew and Albert! I completely agree that perfect is the enemy of good, and that removing the feature entirely seems like a harsh response to these concerns. Sadly, the problems are deeper than the UX. MP uses weak encryption: it's easy to crack, and tools like Firemaster can do this quickly. It does prevent casual snooping, but, despite its name, MP is not a serious security mechanism. OS-level encryption is far better at protecting your data. Trading usability for security is already tough, except, in this case, you get security theater. :-( If you haven't seen it already, bug 973759 has a good summary of what's wrong with MP. In addition to the dialog popping up unexpectedly, Firefox doesn't tell you why it's asking for your password. It looks suspicious, and we've had folks wonder if the prompt on Desktop is malware (https://github.com/mozilla/fxa-auth-server/issues/1779). You can dismiss the dialog, but then Sync won't be able to sync your passwords. On Desktop, Sync won't run at all, because it stores your FxA credentials in the password manager. We don't make these implications clear. We've talked about improving our password management story, and there will be movement on that this year...but it won't be the same mechanism as MP. As implemented, MP doesn't meet our quality standards, and, with a replacement on the way, it's hard to justify spending time on it. That's why it's on the chopping block.
Hey, would it make any sense to have FxA manage the encryption keys for Master Password? That way, users don't need to remember their FxA password and an encryption passphrase for MP. Context: FxA is working on providing and managing encryption keys for other Firefox products like Hoverpad, Lockbox and for webextensions through a new FxA webextension API. Perhaps there is a way to provide more value to Accounts and improve the MP user experience by tying local encryption to an account.
(Edit: the question that remains though per my above comment is if by doing that we could also somehow make it easier to Sync encrypted local data)
(In reply to Alex Davis [:adavis] [PM FxA+Sync] from comment #40) > Hey, would it make any sense to have FxA manage the encryption keys for > Master Password? That way, users don't need to remember their FxA password > and an encryption passphrase for MP. If every user had a Firefox Account, then yes, unifying the two passphrases would be sensible. But not every user has an Account; and users lose access to their accounts; and change their passphrases, etc; so I don't think it's feasible to unify in this way. That is, I think you're turning one hard problem (how to make Master Password/pin unlock schemes have value in the browser) into two hard problems (how to make Firefox Accounts have value/manage key material AND how to integrate against Master Password, given that Master Password has to function without a Firefox Account).
This has been suggested a few times over the past four years (for example, Bug 995268 Comment 31). There are lots of difficulties here: - Coupling a remote lifecycle to a local feature. - Coupling two optional features -- MP without FxA, FxA without MP. - Managing key changes. I don't want to lose my logins if I forget my FxA credentials! - Maintaining correct behavior for FxA clients that don't support MP. - Chicken-and-egg on desktop: we store your FxA credentials in Login Manager, which is why Sync triggers a Master Password prompt when you open Firefox. What happens if we encrypt your Login Manager with your FxA credentials?! - Future migration away from MP (Bug 1271851). IMO (and I'm not alone in this!) a much better time investment is to use system credential storage (e.g., the macOS Keychain) to store encryption keys, just as we do on iOS, and remove the PSM Master Password feature altogether. This gives _all_ users strong encryption protection without any custom interaction overhead: we would hook into the existing OS lock/unlock behavior like TouchID and screen lock. Sync and FxA protect your logins in flight and at rest on the server; local crypto would protect your logins at rest on your device. My suggestion for this bug is to finish reimplementing login storage outside of Gecko, and then implement whatever additional security layer we want on top, using native Android notifications and credential storage. Master Password as it currently stands would not be part of that solution (see Comment 15 and Comment 16).
Flags: needinfo?(jcheng)
Product: Android Background Services → Firefox for Android
Just when I thought it was ME, I found this issue. So, basically don't use Master Password on Fire Fox. I set one up. Now I have to take it down but when I use my phone to reset MP using this link's https://support.mozilla.org/en-US/kb/reset-your-master-password-if-you-forgot-it information to type in chrome://pippki/content/resetpassword.xul from the FF browser (I am using duckduckgo search engine) I get an error that the webpage does not exist or was moved. If I use this from my desktop I can at least get to the page. Is there a special page to reset MP from an Android phone when using FF browser with duckduckgo? I searched on this site and found this to be somewhat related but could not find anything about resetting MP. https://bugzilla.mozilla.org/show_bug.cgi?id=1259701 Should I just uninstall/install FF? I don't have any PW's saved as the first thing I did was set up my MP. By the way, I am not very computer literate so any fix has to be pretty darn simple and laid out in laymen terms. Thanks!
(In reply to MorganS from comment #44) > Just when I thought it was ME, I found this issue. > > So, basically don't use Master Password on Fire Fox. I set one up. Now I > have to take it down but when I use my phone to reset MP using this link's > https://support.mozilla.org/en-US/kb/reset-your-master-password-if-you- > forgot-it information to type in chrome://pippki/content/resetpassword.xul > from the FF browser (I am using duckduckgo search engine) I get an error > that the webpage does not exist or was moved. If I use this from my desktop > I can at least get to the page. Is there a special page to reset MP from an > Android phone when using FF browser with duckduckgo? > > I searched on this site and found this to be somewhat related but could not > find anything about resetting MP. > https://bugzilla.mozilla.org/show_bug.cgi?id=1259701 > > Should I just uninstall/install FF? I don't have any PW's saved as the first > thing I did was set up my MP. > > By the way, I am not very computer literate so any fix has to be pretty darn > simple and laid out in laymen terms. If you don't have anything that you mind losing (i.e., no saved PWs), then I suggest uninstall and reinstall. You can also "Clear Application Data" from the Android Settings App, which should have the same effect -- but it can be a little harder to find that option, since the Android Settings App has changed a lot with the Android releases. Sorry that this is not a good experience :(
No problem. I uninstalled/installed. Problem solved.
Priority: -- → P3
Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195 Needinfo :susheel if you think this bug should be re-triaged.
Priority: P3 → P5
See Also: → 1013064

Same problem but very very scary and a lot of researching. Password syncing was fantastic until I put a master password on FFAndroid. Before that I had only only a master password on several versions of FFWindows. I wished I had seen this before adding a MP to Android : "When Master Password is enabled, passwords will stop syncing to Firefox for Android." in https://support.mozilla.org/en-US/kb/using-master-password-firefox-android

**** This warning message above should be included and in bold when creating a master password in FFAndroid !! Please please add this !! ****

Also, for me the following quote was not true "When Master Password is disabled, passwords will begin syncing again." in https://support.mozilla.org/en-US/kb/using-master-password-firefox-android When I tried to clear my Facebook cookies and logged-in state with FFAndroid -> "Settings" -> "Clear private data" -> "Cookies & acive logins" (not "Saved logins") and somehow my passwords all disappeared.

Scary to think I may have lost all my passwords. Tried everything before uninstalled latest FFAndroid and reinstalled it after clearing cache and "Clear Application Data". Finally got it to work; I think ...
A lot of debugging, and testing on FFAndroid-M 65.0.1, FF 65.0.1 win64, FFEsr 52.9.0 win64 (I know it's no longer supported but I really need it).

What is the main bug # for this (7 yr old) bug ? Search gives me many many.

Thanks everyone working on FF.

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.