Closed Bug 995268 Opened 11 years ago Closed 11 years ago

Firefox Sync and Master Passwords are now mutually exclusive

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Version:
29 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1013064

People

(Reporter: ben, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [qa+])

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release) Build ID: 20140407135746 Steps to reproduce: It seems that suddenly Firefox Sync and Master Passwords have become mutually exclusive on Firefox Beta v29 (Desktop) ("Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0")! This is *terrible* news for me as it means that I will no longer be able to use Firefox Sync for passwords. I do not feel safe having all my passwords stored in an unencrypted manner on my devices. I will not compromise my local security in order to gain the convenience of synced passwords - but I will *REALLY* miss the ability to sync my passwords between my devices :( Actual results: I go to the Options window, click the Sync icon and note that the 'Passwords' checkbox is unticked and disabled with a "[?]" which, when clicked, takes me to: https://support.mozilla.org/en-US/kb/why-cant-i-sync-my-passwords?as=u&utm_source=inproduct Expected results: It should allow me to sync passwords and continue to have a Master Password, like it always has!
Component: Untriaged → Security
Component: Security → Sync
Severity: normal → major
Unfortunately, yes. We're going to work on a solution that allows passwords to be synced when you have a master password in a future version.
Severity: major → normal
Status: UNCONFIRMED → NEW
Component: Sync → Security
Depends on: 986637
Ever confirmed: true
Summary: Firefox Sync and Master Passwords are now mutually exclusive?! → Firefox Sync and Master Passwords are now mutually exclusive
This *really* saddens me. I can't see a reason that the two cannot work together. I recently wrote a long blog post about password security recommending the use of Firefox ( http://www.bennish.net/blog/2013/12/my-personal-password-policy/ ) but until you fix this bug, Firefox has effectively become useless to me and I will have to consider switching back to Chrome. And yet I wanted so much to enjoy the new GUI. It's especially annoying that this change has been made so soon after the Heartbleed OpenSSL vulnerability as when I change ALL my RANDOM passwords (once I'm happy that the sites are not vulnerable), I will now be unable to use Firefox Sync! :-( Any idea when this will be fixed?
Flags: firefox-backlog-
OS: Windows 7 → All
Hardware: x86_64 → All
Just a note to say that issue #711636 is now a special case of this issue when Platform=Android
I would like to echo Ben's concerns. I use random passwords for every website and rely heavily on Firefox Sync to propagate my password to all devices (desktop and android). I use a master password on all devices to ensure safety in case my devices gets stolen/comprimized. Not being able to use a master password and password together makes Firefox Sync useless to me. Ideally I would like the master password to be used both for encrypting locally stored passwords (as is the case today) and for encrypting passwords when they are synced (currently this is solely based on the account password, I believe). I understand that this would probably require the master password to be identical on all devices and would make make it impossible to restore synced passwords in case of a lost password. One would expect that people that opt for a master password are particularly security sensitive and should be ok with this.
I too heavily rely on Firefox Sync + master password. Soma master password improvement could be great too (as my browser is open for days, a master-password timeout would be great, I currently use an add-on for that purpose) I'm totally OK with having the same master password on every device provided it doesn't change the security of the system.
That's a major issue for me as well. It looks like we are stepping back in privacy and security with this new sync. As I understand my history, bookmarks and tabs are been stored in plain text in Mozilla servers, right? If that's right any person with access to the servers would be able to see/leek my information. I might be mistaken but I believe that the previous sync stored all that encrypted using my token.
In general: I encourage you to use BitLocker (Windows), FileVault (Mac), or similar disk encryption tools, along with your OS's memory isolation techniques, instead of (or as well as!) Master Password. Every platform we support has strong disk encryption (even Android), which will protect *all* of the data in your profile, and protect it strongly. By contrast, Master Password protects *only* your passwords, and it does so with a relatively weak encryption step (about as strong as the raw entropy in your master password itself, which isn't much unless you've typed a poem or an AES key). It's also less convenient, because you have to unlock it separately; most OS-level systems unlock when you log in. (That's a selling point to some people, I know, but MP makes a pretty clunky "PIN lock".) (In reply to Sergio Oliveira Campos from comment #7) > As I understand my history, bookmarks and tabs are been stored in plain text > in Mozilla servers, right? > If that's right any person with access to the servers would be able to > see/leek my information. That's not the case. They're stored encrypted by a key that's derived from your password, and the server doesn't have your password. If you're interested in the guts: https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol > I might be mistaken but I believe that the previous sync stored all that > encrypted using my token. The only difference is the source of the top-level encryption key (the "sync key"). It used to be entirely random. Now it's a stretched, derived key.
> By contrast, Master Password protects *only* your passwords, and it does so with a relatively weak > encryption step (about as strong as the raw entropy in your master password itself, which isn't much > unless you've typed a poem or an AES key). My Master Password is a 6 word Diceware passphrase and therefore has a worst-case entropy of about 77.5 bits. The thing is that I don't trust any of the other applications running on Windows or Mac OS X enough to allow them to have access to the key3.db and signons.sqlite files. Disk-based encryption would not protect me in this case as the encryption is transparent to applications. Android devices (my mobile phone and tablet) run each application as their own separate user so this is not so much of an issue, but on Windows and Mac OS X, every other application running as my 'Ben' user can easily read my passwords directly from the disk without a Master Password. If I uninstall Firefox Beta 29 now, install Firefox 28, configure (old) Sync, and then opt to stay using the old sync when Firefox 29 release comes out, will I be able to continue using a Master Password and syncing my passwords? Cheers, Ben
(In reply to Ben Kennish from comment #9) > If I uninstall Firefox Beta 29 now, install Firefox 28, configure (old) > Sync, and then opt to stay using the old sync when Firefox 29 release comes > out, will I be able to continue using a Master Password and syncing my > passwords? For so long as the old Sync client code is supported, yes. That should be at least another 4 months.
Thanks Richard. Unless it is possible to use a Master Password with the new Sync after that 4 month period, I would wish to continue using the old Sync but would be happy to run my own (old) Sync server as detailed here: http://docs.services.mozilla.com/howtos/run-sync.html Will it then be possible to carry on using a Master Password with the old Sync? If not, what can those of us that do not like the new Sync do? I'm starting to really wonder why old Sync is being retired at all tbh, especially considering the well formed arguments in comments such as this: https://blog.mozilla.org/services/2014/02/07/a-better-firefox-sync/comment-page-1/#comment-490
(In reply to Richard Newman [:rnewman] from comment #8) > In general: I encourage you to use BitLocker (Windows), FileVault (Mac), or > similar disk encryption tools, along with your OS's memory isolation > techniques, instead of (or as well as!) Master Password. > > Every platform we support has strong disk encryption (even Android), which > will protect *all* of the data in your profile, and protect it strongly. I use full disk or home dir encryption on any device I use. The threat model I want to protect against is a vulnerable application reading a plaintext password file and thereby getting access to *all* my passwords. Disk encryption cannot protect against that. There are 100+ passwords in my Firefox password store... it would take me days to change all passwords. Please allow a master password to encrypt passwords both locally and remotely.
Keywords: regression
I'm not sure on how 'well' the passwords were encrypted, both if you were using a master password and if you were not using a master password, but right now, I just created a test firefox profile, added some dummy passwords to it and used a program that i googled for, and it unencrypted my passwords pretty much instantly, meaning that this encryption is pretty much useless. I would feel that adding a master password that firefox never saves to disk would help increase the time needed to break it (that is if it is using good encryption), but now that firefox sync does not allow master passwords, firefox might as well just be storing passwords as a plain text file.
Encryption relies on some kind of secret. Without a Master Password, there is no secret and as such any "encryption" that Firefox does is really just obfuscation to make it a _little_ more difficult than loading up key3.db and signons.sqlite files in a basic text editor! I need Master Password and Firefox Sync to work together on my Desktop installations of Firefox because I do not wish to trust the other applications (running as my local user) not to rip my passwords from key3.db and signons.sqlite. I am now running Firefox 29 but with the old Firefox Sync (1.1) which I consider superior to the new Sync (1.5) in multiple ways. I believe that those who have already installed Firefox 29 are unable to add Sync 1.1 accounts so the only solution for them is to install Firefox 28, configure it for Sync 1.1 and then upgrade to 29. I am still awaiting an answer to questions that I made in Comment 11. Cheers, Ben
(In reply to Ben Kennish from comment #11) > Will it then be possible to carry on using a Master Password with the old > Sync? We will not be changing that.
Thanks Mark but I guess my real question is: I am not prepared to use the new (1.5) Firefox Sync until I can use it with a Master Password. Will you continue to support the old 1.1 client Sync code in Firefox until Sync 1.5 supports a Master Password? (To be honest, I don't really want 1.5 Sync at all - I was and am still happy with 1.1 Sync and would like to keep using that.)
Can someone provide a summary of what changed in Sync 1.5 that disallows the usage of a master password? I am not super familiar with the protocol and how it all works, but if its just storing an encrypted byte string, shouldn't you just be able to store the password encrypted with the master password instead of the 'default' encryption? Or is this just a UI / usability issue? (as the old dialog message was very ugly and scary and popped up at seemingly random times even though it wasn't random)
The primary challenge is that Sync and the Master Password are currently independent mechanisms. Sync can't access your passwords if they are encrypted by the MP, so we can't sync your passwords until you've entered your MP. There is a fair amount of complexity to making this work well (Bug 675883). The whole mechanism should probably be revisited, e.g., why not just encrypt your passwords locally with your FxA password? We were unable to address adequately these issues in time for the new Sync in Fx 29, so we did the simplest thing possible: disable password sync if MP is turned on. That's not ideal, but if you read through Bug 675883, you can see that not addressing this properly can also lead to some bad user experiences.
(In reply to Chris Karlof [:ckarlof] from comment #18) > The primary challenge is that Sync and the Master Password are currently > independent mechanisms. Sync can't access your passwords if they are > encrypted by the MP, so we can't sync your passwords until you've entered > your MP. There is a fair amount of complexity to making this work well (Bug > 675883). The whole mechanism should probably be revisited, e.g., why not > just encrypt your passwords locally with your FxA password? > > We were unable to address adequately these issues in time for the new Sync > in Fx 29, so we did the simplest thing possible: disable password sync if MP > is turned on. That's not ideal, but if you read through Bug 675883, you can > see that not addressing this properly can also lead to some bad user > experiences. What if we were to follow a practice similar to Chromium's secure sync, in which there is an additional password required if the user wishes complete end-to-end encryption. This client-level password must then be entered in all devices where the user wants Chromium sync. An enhancement to this would be by making a similar feature but with an added toggle to "Remember this master password in the future" Enabling this toggle means to follow chromium's current behavior where it's necessary just one time (during set up) so as to decrypt the server-side data. Disabling this toggle means to prompt the user once-every-session whenever the first need arises to access the keystore (ie. how MP behaves currently)
As the Sync password and passphrase are stored within Firefox's passwords database (at least they are for Sync 1.1), I think it should be clear to security conscious people (e.g. anyone who uses a Master Password) that Sync will require knowledge of the Master Password before it will function. I'm currently using Firefox 29 with old Sync (1.1) and it works *exactly* as I would hope. A Sync operation is not attempted until I make local changes (e.g. add a bookmark) or manually click the Sync toolbar button. As soon as I make local changes, I am prompted for the Master Password so that it can perform a sync. If I cancel, I can add further bookmarks without a prompt. I know I keep harping on about Sync 1.1 but I really don't understand the need for the overhaul that is Sync 1.5. "If it ain't broke, don't fix it!" 1.1 wasn't broken and now 1.5 (which seems to me in many ways to be less secure than 1.1) is broken w.r.t. Master Password.
(In reply to Ben Kennish from comment #20) > I know I keep harping on about Sync 1.1 but I really don't understand the > need for the overhaul that is Sync 1.5. "If it ain't broke, don't fix it!" > 1.1 wasn't broken and now 1.5 (which seems to me in many ways to be less > secure than 1.1) is broken w.r.t. Master Password. The answer to that: you are unusual. (Ever heard the phrase "you are not your users"? That applies to you, too.) The vast majority of our users don't grok a pairing-based system, don't know how to manage an AES key (quick, where's your offline copy of your recovery key?), and lack the domain knowledge to make good security tradeoffs. I've known very technical people be puzzled why their browser was so out of date, and seen their surprise when I told them it's because their master password was locked, so Sync wasn't running. I just saw a piece of user feedback that they tried for EIGHT HOURS to set up Sync using pairing, reading every support doc they could find, and gave up and uninstalled. That's a user who's now most likely using Chrome, giving away their browsing history to Google to monetize. We're trying to make the web better for everyone, not just the folks who are knowledgeable enough to understand how Master Password, Sync, J-PAKE, and key management works. Firefox Accounts gives people a well-understood user-pass login system, but maintains client-side end-to-end encryption. That's a pretty amazing tradeoff from my perspective. As to this bug in particular: it just so happens that having Firefox Accounts set up, syncing passwords, and having Master Password turned on isn't a setup that does what you expect -- an app might not be able to read your password database (without spending 30 seconds to crack your MP), but it could read your FxA credentials and prefs.js and simply download your passwords from your Sync server. So we don't let you sync those passwords. A solution to that conundrum will arrive at some point. In the mean time, please no more +1 comments.
Whiteboard: [qa+]
Thanks Richard. I understand your points and agree with what you are saying in essence. Why not give users a _choice_ between Sync 1.1 and Sync 1.5? It doesn't even need to be through the GUI if you think it will confuse the majority of users (maybe it could just be a flag in about:config) but at the moment it sounds like the Sync 1.1 client code will be removed altogether in the future and that then there will be no choice but to use 1.5. I hope this isn't the case and would be very pleased if I am wrong about this. Re: your second to last paragraph, you seem to be suggesting that Firefox Sync 1.5 is storing the FxA credentials in areas unprotected by Master Password. Is this true? Why not store these details within signons.sqlite? I think that Firefox should definitely be more verbose about Sync failures. I'd suggest: (1) First time Firefox tries to sync and cannot (because the Master Password has not been provided) it prompts for the Master Password. (2) If it is not supplied, the user is given a clear warning message ("You did not provide the Master Password so Firefox Sync cannot sync your information until you do.") (3) The sync toolbar button (if shown) displays a warning triangle and has "Firefox Sync cannot run until you provide the Master Password. Click here to Sync" as hover text. Cheers, Ben
(In reply to Ben Kennish from comment #22) > Thanks Richard. I understand your points and agree with what you are saying > in essence. > > Why not give users a _choice_ between Sync 1.1 and Sync 1.5? For several reasons. The most obvious: Sync 1.1 is going away this year -- as soon as we can kill it. Tacitly or explicitly encouraging new users to adopt it is heading in exactly the wrong direction. We also aren't willing to expend the QA and engineering cost to maintain two setup flows, and to create the UI to switch between them. Allowing existing 1.1 users to continue syncing, but not support creating new accounts, seems like a reasonable compromise. And finally: there are only a few very small sets of users for whom 1.1 is a better choice -- users who want to sync passwords _and_ use master password; and users who self-host, use already use Android, and want to add new devices. That's a pretty small set, and not a good tradeoff for everyone else. > It doesn't > even need to be through the GUI if you think it will confuse the majority of > users (maybe it could just be a flag in about:config) That already exists, kinda -- services.sync.fxaccounts.enabled. It's what allows the old Sync 1.1 account to work at all in 29+. But I don't think anyone's tested what it does if you don't already have a Sync 1.1 account set up, which goes back to my earlier point: it doesn't make sense to keep supporting and maintaining an older system that we want to kill ASAP. It might work, in which case great. If it doesn't, it won't get fixed. If you're willing to spend the time, you can manually set prefs and passwords to configure an old Sync account. > but at the moment it > sounds like the Sync 1.1 client code will be removed altogether in the > future and that then there will be no choice but to use 1.5. I hope this > isn't the case and would be very pleased if I am wrong about this. That is absolutely the case. Sync 1.1 will be dead as soon as we can kill it. That's gated on easier self-hosting, a good migration story for old Sync users, and a few other acceptance criteria, so likely in two or three months. I don't know of anyone who thinks that maintaining two parallel syncing solutions is a good idea, so I'd be surprised if anyone contradicts me on this! > Re: your second to last paragraph, you seem to be suggesting that Firefox > Sync 1.5 is storing the FxA credentials in areas unprotected by Master > Password. Is this true? Why not store these details within signons.sqlite? Because then you'd have to enter your master password before we could even determine your FxA credential status, let alone run a sync. I think we're more likely to store your FxA credentials in the Mac Keychain than we are to put them in password manager. (There are a whole bunch of other reasons that are also visible as flaws in the existing Sync -- e.g., an inability to implement something like Sign In To Browser, which relies on data outside the profile; and when you clear private data, it blows away your Sync key!) > (2) If it is not supplied, the user is given a clear warning message ("You > did not provide the Master Password so Firefox Sync cannot sync your > information until you do.") We definitely don't want Sync to nag the user any more than it already does.
> That already exists, kinda -- services.sync.fxaccounts.enabled I can't find this var within about:config. I had a quick look for an identifier. Is it services.sync.clusterURL? > > (2) If it is not supplied, the user is given a clear warning message ("You > > did not provide the Master Password so Firefox Sync cannot sync your > > information until you do.") > . > We definitely don't want Sync to nag the user any more than it already does. I'd disagree that a single informative message (perhaps at the bottom of the window) would be a 'nag'. Would you agree with this... New sync (v1.5) --------------- == Advantages == * Adding a new device is simple - requires a single email and password * Resetting password does not wipe the data == Disadvantages == * Passwords cannot (currently) be synced when a Master Password is set * FxA credentials stored on device in the clear - malware running on it might be able to access these and thereafter continually have complete access to your constantly updated sync data until you change your Sync password Old sync (v1.1) --------------- == Advantages == * Works in combination with Master Password * Randomly generated, high strength encryption key with guaranteed high entropy == Disadvantages == * Somewhat trickier to sync a new device - need access to a currently synced device or the recovery key Cheers, Ben
(In reply to Ben Kennish from comment #24) > > That already exists, kinda -- services.sync.fxaccounts.enabled > > I can't find this var within about:config. I had a quick look for an > identifier. Is it services.sync.clusterURL? Richard's information is out of date - that pref no longer exists. > malware running on it Malware running on your computer has untold ways of getting valuable stuff. Ben, I understand your concerns but don't think you are helping move this bug forward. Please refrain from re-hashing points you have already made.
> Malware running on your computer has untold ways of getting valuable stuff. Agreed - although in many cases it needs Administrative/root rights to do the more dangerous things. I do not wish to rehash any points but if someone could let me know whether my summary of the comparative advantages and disadvantages of 1.1 and 1.5 is reasonably accurate I would appreciate it. Thanks, Ben
Ben, I think your comparison is reasonably accurate. Brian Warner is working on a blog series to go into the comparison in more depth. The first article in the series is here: https://blog.mozilla.org/warner/2014/04/02/pairing-problems/ The controversy around using a Master Password to protect a local password store has been discussed in the depth elsewhere, and I recommend you read those if you haven't already: https://news.ycombinator.com/item?id=6166731 https://bugzilla.mozilla.org/show_bug.cgi?id=973759
> https://blog.mozilla.org/warner/2014/04/02/pairing-problems/ Excellent article - thanks for sharing that, Chris. I look forward to reading the other posts in the series. > https://news.ycombinator.com/item?id=6166731 > https://bugzilla.mozilla.org/show_bug.cgi?id=973759 Also a lot of food for thought - thanks again. I will keep quiet now but am hoping that if Mozilla do choose to shut down their v1.1 Sync servers and remove the code from Firefox, that when they do so, they/someone else I can trust creates a Firefox Add-on that allows more security conscious users to continue to use v1.1 with their own Sync servers. Cheers, Ben
I confirm that Master Password is only one way for protect your saved passwords, because any system encription will protect only when computer is turned off. Where computer is turned on and system is loaded - all unencrypt passwords already typed and all files are available without any encryption. So any application or user can easily copy Firefox password storage file and will got unencrypted all user passwords! This is big security hole!!! Using master password unencrypted passwords is available only to Firefox and no other, this is good security solution. But from Firefox 29 this way broke passwords syncing. So I vote +1 for fixing this issue via adding syncing passwords with master password to new Sync engine.
Why cannot we have something in the middle? How about this: the passwords protected by MP won't sync automatically, but you can press a button to sync. At that time, if you have not entered MP yet, Firefox can ask you to enter the MP or simply tell you to enter the MP somewhere (e.g., when starting up). Now I am thinking, why cannot the sync done after the users enter the MP when they want to use any password?
So, I heard a good argument for using Master Password despite its weak crypto last weekend and that is that the "show passwords" function in the password manager is protected by the Master Password as well and therefore someone (possibly someone without deep knowledge or tools of pulling your logins.sqlite) accessing your computer in an unattended moment is being stopped from looking at your passwords with a few simple clicks. Unfortunately, that is now incompatible with sync. That said, I thought we'd sync the raw passwords anyhow and not the encrypted variant? If we do sync the encrypted variant, could we just always make the FxA password and the Master Password the same?
> If we do sync the encrypted variant, could we just always make the FxA password and the Master Password the same? This is a good idea, I vote for this realisation.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #31) > So, I heard a good argument for using Master Password despite its weak > crypto last weekend and that is that the "show passwords" function in the > password manager is protected by the Master Password as well… Some of us refer to that as the "PIN lock use case". One of the arguments against MP is essentially: * Unless you enter a really long passphrase, MP is so easy to crack that you might as well enter a 4-digit PIN. * The UX for the feature is awful, so if it's only being used as a PIN, one might as well design a better PIN lock and get rid of MP. That is: MP isn't protection for your valuable profile data, it's not really a strong way to protect your passwords, and it's a crummy kiddy-proof lock in the UI. > That said, I thought we'd sync the raw passwords anyhow and not the > encrypted variant? Passwords always have been, and currently are, synced independently of your master password ("raw", but not "unencrypted"). We need your MP to decrypt them in order to sync. > If we do sync the encrypted variant, could we just always > make the FxA password and the Master Password the same? No: 1. The record format is already specified. We can't switch to syncing the encrypted variant without bumping the record format, which will lock out clients that don't speak the new one. 2. What would we do for users who already use a master password? 3. What would happen if you reset your FxA password?
This is literally insane. At the very least you need to display big warnings before people unlink from old sync given that there is no way to go back once you require that new sync requires you to give up your security!
(In reply to Richard Newman [:rnewman] from comment #33) > We need your MP to decrypt them in order to sync. Ah, that's the key to the issue, thanks for mentioning it!
(In reply to Richard Newman [:rnewman] from comment #33) > One of the arguments against MP is essentially: > > * Unless you enter a really long passphrase, MP is so easy to crack that you > might as well enter a 4-digit PIN. > * The UX for the feature is awful, so if it's only being used as a PIN, one > might as well design a better PIN lock and get rid of MP. > > That is: MP isn't protection for your valuable profile data, it's not really > a strong way to protect your passwords, and it's a crummy kiddy-proof lock > in the UI. > As I already mentioned previously, my Master Password is a six word Diceware passphrase and therefore has a *worst-case* entropy of about 77.5 bits. That is not a "crummy kiddy-proof lock". All password authentication is rubbish if the user chooses bad passwords. So unless a massive flaw in 3DES in CBC mode is discovered, this isn't a good argument for removing the authentication altogether imo
(In reply to Ben Kennish from comment #36) > As I already mentioned previously, my Master Password is a six word Diceware > passphrase and therefore has a *worst-case* entropy of about 77.5 bits. > That is not a "crummy kiddy-proof lock". As I mentioned in Comment 21: you are very unusual. And here I was responding to the "PIN lock" use case that kairo raised. From experience interacting with lots of users, that seems to be one of the most used applications of MP. If I had to guess, with no studies backing this up, I'd guess: 60%: "I know I want moar securities, so I will turn on MP. Nobody ever told me that it takes off-the-shelf software a matter of minutes to crack the DB." 38%: "Every little helps, but most of all this stops people easily reading all of my passwords." (a big complaint about Chrome a year ago: <http://www.engadget.com/2013/08/07/chrome-saved-passwords/>) 2%: "I have a thorough understanding of the crypto in use, and can pick an appropriately strong password and manage the locked state of the browser manually." Master Password doesn't help the first category: their password DB is trivially easy to attack. Indeed, it offers misleading confidence to those people. It doesn't really address the second category well: they'd be much better served with guest mode/child mode/sign in to browser, or even a trivial non-encrypting PIN lock. The UI afforded by the PSM is pretty bad, and we don't do a good job of explaining why you'd want to use MP. It serves the third set, but many of those users would be better off simply putting their profile on an encrypted disk image, or using 1Password/LastPass instead off the Firefox password manager.
Just my 5 cents. Used to be a developer, now supervising a small network. I have a couple of systems on "secure" areas and a couple in "insecure". On the latter ones, I had MP on FF. In any case, I strongly disagree with having to lose MPs in order to jump to the Sync 1.5 bandwagon. Let me elaborate: Quite a few opinions pointed that atm it was not possible to have MP alongside Sync 1.5. If that was the case, then the reasonable thing would be to develop and release the new Sync architecture, once MP was included in the solution. I will not label this engineering decision in terms of right and wrong. I do not possibly have the knowledge to do so. Even if this is a case of a wrong decision, they do occasionally roll out and reach the user. And this is where this case really got fubar'ed: sync 1.5 was presented with no information to the user regarding the change. In fact, reading the FAQ outlying the change, there was only one caveat presented and that was about (IIRC) users staying in the older platform. No warnings at all that password sync will be impossible with sync 1.5. Only AFTER the user migrated his system to the new platform. Again, Firefox was rolled out with a HUGE change that effectively removed a critically wanted feature (in the eyes of the user, nevertheless), putting the user in the unpleasant situation to have to select whether to go forward, or revert to the previous situation. With not enough data to do so in the latter case. I guess it be hell once sync 1.1 will be rolled out, for those folks still using it, to understand what has to be done to roll onto 1.5... Again: it's not a matter if this was a sound engineering decision or not. It was on the way it was forced down on our throats, thinking that we were just simply doing performance/stability improvement (which it was), without changing anything at all on the things we like about the sync 1.1 (which it wasn't). Which brings me to the last part of this monologue. I am VERY disappointed with the removal of MP. So disappointed in fact, that I came here amidst a ton of work to write down my grunts about this change. Mr. Newman, I *definitely* agree that MP might seem that much better a protector, than a PIN. But: * I definitely do not have a MP of a 5 character variety, and definitely not ones that could be broken with a dictionary attack. A statistic outlier I might be, then again quite a few non-techie folks I have introduced over the last 2-3 years to Sync, embraced it with open arms and utilized some heavy MPs. Do not know the content, but they definitely were long ones. * In a work environment, a coworker could easily open FF and check things. In the home environment, with teens running around, various data also should stay private. Granted, other security means could possibly be enforced, filesystem protection for example. These are NOT for the non-technical inclined. Occam's razor here, sync 1.1 was extremely elegant factoring in the limitations of sync'ing at the presence of a MP. * Combining Sync/MP and deletion of cookies at exit has been an extremely effective means to lock out unauthorized accesss to sensitive data. No biggies in configuring these for other non-tech folks as well. * Finally, one could argue that replacing a truly random piece of data (the key in 1.1) with a salted/stretched of non-random/pass-associated data (in 1.5), is something ok. Without going as far to conjure what would happen if this proposition is not valid, I can only state the obvious. Every now and then, crypto-methods are exploited due to weaknesses found. A step in the backward direction (could be wrong)... Bottomline: for me and for quite a lot of folks out there, sync 1.1 was *PERFECT*. For those folks utilising decent MPs, it operated like having a local PGP-protected file, without the fuss of having to maintain one. I could not find a single hitch or complaint. Nothing. It was one of the two reasons I did not move to Chrome (the other, being of course the profiling or even the eavesdropping). And again, with utmost respect to the development community, it was not only the change that did the "damage" but also the uninforming rollout, leading us into a road we do not want to travel, but discovering it until it was too late to go back. Please do bring MPs back! PS: If I understood correctly, sync of everything except the passwords was done, regardless of whether the MP was entered? That could be definitely be a cause of some incosistent states around. Proposal: change it so ANYTHING sync'ed, requires entering the MP. From a user-point of view, wouldn't that mean that it would just have to be entered immediately upon FF start?
(In reply to Michail Pappas from comment #38) > (...) In any case, I strongly disagree with > having to lose MPs in order to jump to the Sync 1.5 bandwagon. Let me > elaborate: (...) Great piece of grunt Michail. I too actually put on hold some work in order to find why my passwords were not synched! You have better express my opinion that I would have beenable to do. I would like to add one more thing to it. As you mentioned I was not aware of the changed, but since the migration to Firefox 29, I started having sync problems with my password whereas I was still using the old sync (see bug #1009414). So I decided to join the bandwagon and create a Firefox Account. Now I have the choice of removing my MP to use the very functionnality I like most in Firefox (safe passwords sync) or stop having this great functionnality. And what is missing from your grunt is another UI mistake. After creating the account, I was asked to choose which items I wanted to sync, I selected passwords, bookmarks, history and tabs only. As I am a savvy user, I went into the preferences after the sync to verify the "status". First of all, all items where selected to sync and not the subset I chose. Second, password had been unselected without notification. I understand that for the time being passwords can't be sync if using a MP, but if I hadn't gone to the preferences I would not have know it!
I agree with you Michail - I don't think Firefox can 'lead the way' by pandering to the ignorance of the average web user - if anything we should be trying to educate users and encouraging them to be *more* secure - imho the time spent on Sync 1.5 could have been better spent on improving the Sync 1.1 GUI and improving the text that describes the process Michail Pappas said (in Comment 38): > PS: If I understood correctly, sync of everything except the passwords was done, > regardless of whether the MP was entered? That could be definitely be a cause > of some incosistent states around. Proposal: change it so ANYTHING sync'ed, > requires entering the MP. From a user-point of view, wouldn't that mean > that it would just have to be entered immediately upon FF start? This cannot be enforced because for Sync 1.5 the account details (email and password) are stored on disk in a file that is not protected by Master Password ... Richard Newman said (in Comment 23): > > Re: your second to last paragraph, you seem to be suggesting that Firefox > > Sync 1.5 is storing the FxA credentials in areas unprotected by Master > > Password. Is this true? Why not store these details within signons.sqlite? > . > Because then you'd have to enter your master password before we could even > determine your FxA credential status, let alone run a sync. So any application can simply examine those credentials and it's Game Over. A summary of the facts as I see them: + Firefox Sync 1.1 stores the Sync account details in files protected by Master Password - Firefox Sync 1.5 stores the Sync account (FxA) details in files not protected by Master Password - Firefox Sync 1.1 cannot function until the Master Password has been entered + Firefox Sync 1.5 can function at any time + Firefox Sync 1.1 will happily sync passwords when Master Password is enabled - Firefox Sync 1.5 refuses to sync passwords when Master Password is enabled + Firefox Sync 1.1 and Master Password provides protection against malware or someone else using your device ('pesky kids') - Firefox Sync 1.5 cannot protect against these things Users of Firefox Sync 1.5 who are syncing passwords (and therefore do not have a Master Password set), are not only allowing all applications open access to their passwords file, but to their Sync account details too. If someone gains access to an old and forgotten about device that the user has configured Sync for, they can grab the Sync account details - and these two tokens (email and password) give them continual access to an up-to-date list of all that user's passwords (as well as their History, Bookmarks, Preferences, etc of course.) User of Sync 1.5 wishing to improve their security in the future may opt to enable Master Password. But as soon as they realise that it prevents them syncing passwords (which imo is one of the most useful components of Sync), I'm pretty sure they will disable the Master Password very soon after.
(In reply to Richard Newman [:rnewman] from comment #37) > (In reply to Ben Kennish from comment #36) > > > As I already mentioned previously, my Master Password is a six word Diceware > > passphrase and therefore has a *worst-case* entropy of about 77.5 bits. > > That is not a "crummy kiddy-proof lock". > > As I mentioned in Comment 21: you are very unusual. > > And here I was responding to the "PIN lock" use case that kairo raised. From > experience interacting with lots of users, that seems to be one of the most > used applications of MP. If I had to guess, with no studies backing this up, > I'd guess: Here's the best data I know of about MP usage in Firefox: http://monica-at-mozilla.blogspot.com/2013/02/cant-live-with-them-cant-live-without.html Only *one* user of the ~12k users in the study had master password enabled. It's unclear what this means for Firefox users in general, but I feel pretty safe stating this: a very small percentage of Firefox users have master password enabled. I think there are simple improvements we can make to how Fx Sync and MP interact (e.g., only pause password syncing until the MP is entered, rather than disabling it entirely). However, our engineering resources are finite. We generally prioritize our work based on its anticipated impact on our user base, and the above numbers on MP usage don't support devoting significant engineering resources to improving the hazard around the interactions between MP + Fx Sync. I also think there are improvements we can make to how to store the FxA credentials, but I don't think relying on the current MP to protect these credentials will be useful to our broader user base. I think a "log into profile" feature would be a popular and broadly useful feature, but that's a longer term project.
(In reply to Chris Karlof [:ckarlof] from comment #41) > (In reply to Richard Newman [:rnewman] from comment #37) > > (In reply to Ben Kennish from comment #36) > > > > > As I already mentioned previously, my Master Password is a six word Diceware > > > passphrase and therefore has a *worst-case* entropy of about 77.5 bits. > > > That is not a "crummy kiddy-proof lock". > > > > As I mentioned in Comment 21: you are very unusual. > > > > And here I was responding to the "PIN lock" use case that kairo raised. From > > experience interacting with lots of users, that seems to be one of the most > > used applications of MP. If I had to guess, with no studies backing this up, > > I'd guess: > > Here's the best data I know of about MP usage in Firefox: > > http://monica-at-mozilla.blogspot.com/2013/02/cant-live-with-them-cant-live- > without.html > > Only *one* user of the ~12k users in the study had master password enabled. > > It's unclear what this means for Firefox users in general, but I feel pretty > safe stating this: a very small percentage of Firefox users have master > password enabled. "There are lies, damned lies and statistics": * A (somewhat) security-conscious user will have telemetry disabled, alongside enabled MPs, fearing some exploit or data leak. I did for example, don't really know if that is a trend or not. But if I was included in the survey, I'd also have more than 100 passwords listed. * Even if telemetry was force-enabled on all firefox clients, one would have to consider how he would calculate the number of clients using it. As is, the report worked in the notion that there is a X% percentage of *USERS* using MP. This is plain wrong. Example. If all 4 PCs I have access to were accounted for in this report, then it would show that 1 of them has MPs enabled and the other two don't. In the same report it would show that there are 4 users and 1 of them is using MPs. This twists heavily the results: the developers would think that a single user and a single pc is affected by the loss of MPs along sync. Only a single user and a single PC might be dissatisfied. Yes it is a single user, but no it is *4* PCs affected here! If the user finds the functionality elsewhere, he'll change *all* firefox installation, not only the one where MPs are enabled! Bottomline, in the context of MPs *and* sync usage, I strongly doubt the report results, regarding who actually uses MPs or (even more) MPs along sync. > I think there are simple improvements we can make to how Fx Sync and MP > interact (e.g., only pause password syncing until the MP is entered, rather > than disabling it entirely). However, our engineering resources are finite. > We generally prioritize our work based on its anticipated impact on our user > base, and the above numbers on MP usage don't support devoting significant > engineering resources to improving the hazard around the interactions > between MP + Fx Sync. I fully understand that (a) any FOSS project has limited resources and that (b) prioritization is definitely required to maximize usability impact. In this case though a significant amount of effort, although intended to improve this situation, actually impacted in a negative way the user's experience. A final comment here, stating the obvious: it is the heavy users, the "outliers" if you so prefer, that are the strongest evangelizers of a platform. The ones that will actually take the time to read the FAQ, see what might went wrong, ask in a forum. Or even, check the open bugs, make an account, post in bugzilla. And tell you, the ones that don't take a dime for a zillion lines of code, that you might have done it wrong, hoping that you will treat our criticism not as disrespect, but rather as a respectful request...
At least it's nice to finally see some admission of the weakness of the Master Password cryptographic implementation. Of course, something is better than nothing and that is what I have always been banking on. One of the main reasons I use firefox is the Master Password encryption of passwords. The main reason I no longer use Chrome is the lack of a master password. The reason I want this data encrypted inside of signons.sqlite is to protect against the disastrous case of someone getting access to that file. One alternative is to store the information in something like the gnome keyring, or apple keychain (presumably there exists something for other OS environments like KDE or Windows). This approach would benefit in that passwords could be saved on disk in an encrypted form in the keyring, and decrypted for sync so that they can be shared with other sync endpoints.
I have a suggestion. Keep the new (suboptimal security) sync architecture for syncing everything else. Create a master key (distinct from the master password). Encrypt it using the PBKDF2 of the master password. Encrypt all passwords with the master KEY, client-side, and upload the encrypted KEY on the server. All clients must have the same master password to decrypt the key, to decrypt the passwords. (Is this what Truecrypt does?) Previously, the sync key was encrypted by the master password. Now the sync key is a function of the sync password. An alternative idea is to make the sync key a function of the sync password, the master password, and another value, computed such that f(syncpass, "", nullvalue) is equal to f(syncpass, "password", passwordvalue), possibly xoring the PBKDF2 result with the value. Using that proposal, you will only be able to sync after entering the password, and you cannot remove the master password while preserving the ability to redownload passwords afterwards. I'm not sure if that idea is plain dumb or not. The best approach depends on whether you want to force all devices to encrypt the passwords identically (more secure, more consistent, but possibly inconvenient, keyloggers can steal your password from an untrusted device), or each device has its own master password (less secure, less consistent, more convenient and flexible, and a malicious device can outright steal all your passwords directly). I suspect the two approaches may be mutually exclusive, as the key would have to be encrypted differently based on the varying master password, while only one version can be the official encrypted key. The first approach, any device can generate a new key, reencrypt the passwords, and reencrypt the new key using the master password. Any device can corrupt the key, preventing any other device from decrypting the passwords. The second approach (similar to old sync), a stolen device with a temporarily unlocked master password can link up another device without a master password, then allowing the passwords to be stolen from the second. You can ask for the master password again when trying to sync a new device, but that's still a weakness.
(In reply to Richard Newman [:rnewman] (pto -> May 19) from comment #33) > That is: MP isn't protection for your valuable profile data, it's not really > a strong way to protect your passwords, and it's a crummy kiddy-proof lock > in the UI. Please take that up with the security team. Dissing a long-standing feature/implementation of a different team doesn't help to make our product better. > > If we do sync the encrypted variant, could we just always > > make the FxA password and the Master Password the same? > > No: > > 1. The record format is already specified. We can't switch to syncing the > encrypted variant without bumping the record format, which will lock out > clients that don't speak the new one. > > 2. What would we do for users who already use a master password? > > 3. What would happen if you reset your FxA password? That could all be solved with some thought (could we basically make the password store just store the same encrypted object we transmit over the wire for Sync, could we sync up the stores/passwords when people set up FxA, could we do the same decryption and re-encryption dance that we do when people change the MP now, etc.) - but this is not the bug to solve this, we should do that in a bug in the Password Manager component. (In reply to Richard Newman [:rnewman] (pto -> May 19) from comment #37) > If I had to guess, with no studies backing this up, Please don't go there. Guesses always make people think you are not taking them seriously. Let's please take privacy-concerned users seriously. (I have actually heard hints that if we leave things this way, we might be pretty well in game game of winning an anti-privacy award.) > Master Password doesn't help the first category: their password DB is > trivially easy to attack. Indeed, it offers misleading confidence to those > people. Let's not try to save the problems of the Master Password in a Sync bug. I'm happy if we finally go and try to attack the "Master Password issue", but let's try to decouple solving the issues. (In reply to steeve from comment #43) > At least it's nice to finally see some admission of the weakness of the > Master Password cryptographic implementation. It has been admitted for quite some time, and there is bug 973759 specifically about it. Admission of MP weaknesses by Sync devs is not helpful. We need to solve the Sync issue here, not all problems of the world. rnewman, just concentrating on finding something that works for MP users and we could do pretty fast completely on the Sync side, could we just delay synching passwords until the MP has been provided somewhere? Also, why did we remove Sync prompting for the MP by itself?
All I said was that it was nice to know. I have asked and searched the firefox forums several times looking for information about the security of the implementation of the MP. And your response about not wanting to solve the problems of the world is unwarranted if there is indeed an issue with MP and Sync that need to be resolved, preferably simultaneously. Typical response that I come to expect in these forums. And now I'm just **** off about your attitude, and the risk of losing another firefox evangelist is one step closer to reality.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #46) > Please take that up with the security team. Dissing a long-standing > feature/implementation of a different team doesn't help to make our product > better. My opinion is the result of years of talking to various folks in and around the security team, fwiw, as well as dealing with MP from a Sync standpoint. Lots and lots of people think it should be improved or removed (e.g., Bug 973759, in which you cross-commented). And I disagree: being honest isn't dissing (would anyone really contest that the current MP UI is not a good kiddy-proof lock, that MP is not a strong way to protect your passwords, and that it only protects signons rather than other profile data?), and being honest is the only way we'll move things forward. > rnewman, just concentrating on finding something that works for MP users and > we could do pretty fast completely on the Sync side, could we just delay > synching passwords until the MP has been provided somewhere? Also, why did > we remove Sync prompting for the MP by itself? I think you might be misunderstanding the problem here. The decision was made to *turn off* password syncing when MP is enabled and a user has a Firefox Account. There's no technical reason why it wouldn't work. Unlike in Sync 1.1, we don't need to access signons.sqlite in order to begin syncing (... only to sync passwords). That decision was made because your FxA credentials are written in cleartext to disk, and thus an app that could have read your passwords (but for MP) can now read your FxA credentials and circumvent a MP by just fetching your passwords from the cloud. Turning off password sync just avoids that particularly painful theoretical papercut. In short: if you have MP turned on, we assume that you don't want apps with profile-dir read permissions to be able to read your passwords, regardless of how many hoops they jump through. We haven't removed the MP prompting code; it's still used for Sync 1.1. You just never see it from Sync 1.5, because by definition you aren't syncing passwords if you need to unlock MP. So, that's the backstory. I hope you can see why the solution here probably isn't going to be part of Sync. FxA credentials would need to be stored somewhere other than a cleartext bundle (with all the issues that I've outlined before about when those credentials need to be available to the Firefox UI), or MP needs to change/go away to cut the knot. There is a theoretical solution involving building a new password sync format, such that an attacker with your FxA credentials couldn't read your passwords from the cloud, but: (a) that's a lot of work (and there's nobody available to do it), (b) it wouldn't interop with existing clients (Fx29-Fx3*, extend until work is done), (c) it adds a lot of cross-device complexity (does your phone cache your master password so it can sync, or does it ask you every 30 seconds?), (d) it doesn't address the fact that your whole FxA credential bundle is in cleartext on disk, and thus there's some clear conceptual disjunction between reality and people's view of the importance of signons.sqlite versus their other profile data. A keychain-backed SITB seems like the best approach to me, but what do I know?
(In reply to Richard Newman [:rnewman] (pto -> May 19) from comment #48) > And I disagree: being honest isn't dissing (would anyone really contest that > the current MP UI is not a good kiddy-proof lock, that MP is not a strong > way to protect your passwords, and that it only protects signons rather than > other profile data?), and being honest is the only way we'll move things > forward. Well, the point is that we are NOT honest. We are never telling the MP user that we'll just stop synching their passwords, and when they find help about it (on SUMO AFAIK), it just bluntly tells them to switch off MP but doesn't explain any issue. > The decision was made to *turn off* password syncing when MP is enabled and > a user has a Firefox Account. > > [...] > > That decision was made because your FxA credentials are written in cleartext > to disk Those two facts together with the blunt help text telling people to just turn off MP will probably easily earn you a Big Brother Award, from what the organizers of that anti-privacy award were telling me on the recent conference (and why I even became aware of the issue). To put it in their words: Please make sure you book a flight to Vienna for Oct 25 to be around for receiving that award. (I myself will probably make sure I'm out of town and will probably need to stop talking to my friends in that organization.)
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #49) > Well, the point is that we are NOT honest. We are never telling the MP user > that we'll just stop synching their passwords, and when they find help about > it (on SUMO AFAIK), it just bluntly tells them to switch off MP but doesn't > explain any issue. Did you file bugs for those? There's supposed to be an affordance (should be a "?" that links to SUMO) in the data types area that explains why the checkbox is greyed out, and if that's missing it should be fixed. > Those two facts together with the blunt help text telling people to just > turn off MP will probably easily earn you a Big Brother Award, from what the > organizers of that anti-privacy award were telling me on the recent > conference (and why I even became aware of the issue). Not my decision, I'm afraid. Bug 970167 for context if you want it. Please bear in mind that what we're shipping right now -- FxA, and Sync hacked to work with it -- is the result of the efforts of a whole bunch of people to make reasonable tradeoffs under very difficult circumstances. I'm pretty impressed with what shipped in 29, but I don't think anyone would say that it's even close to perfect. This decision was one of those calls -- which evil do you wanna ship?
(In reply to Richard Newman [:rnewman] (pto -> May 19) from comment #50) > (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #49) > > > Well, the point is that we are NOT honest. We are never telling the MP user > > that we'll just stop synching their passwords, and when they find help about > > it (on SUMO AFAIK), it just bluntly tells them to switch off MP but doesn't > > explain any issue. > > Did you file bugs for those? There's supposed to be an affordance (should be > a "?" that links to SUMO) in the data types area that explains why the > checkbox is greyed out, and if that's missing it should be fixed. No, I didn't even have time (or a particular wish) to reproduce this, I can only talk about what those actual privacy-sensitive end users told me. (I personally don't even use MP, and neither Sync 1.5 as I want to sync with SeaMonkey which doesn't support FxA yet.) > Not my decision, I'm afraid. Bug 970167 for context if you want it. Thanks for the pointer. > Please bear in mind that what we're shipping right now -- FxA, and Sync > hacked to work with it -- is the result of the efforts of a whole bunch of > people to make reasonable tradeoffs under very difficult circumstances. I'm > pretty impressed with what shipped in 29, but I don't think anyone would say > that it's even close to perfect. This decision was one of those calls -- > which evil do you wanna ship? Ideally, always none. If we'd have a crash that affected as many people as this decision seems to, I might be involved in getting a point-release out with some kind of fix or backout. But that said, I know there's tons of work in there and a lot of it is good, but ugly corners like this concern me deeply as we are using our peers in the privacy community over this, which is pretty nasty long-term. If we want to increase our usage and reach of our message, we need those people in our boat.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #51) > If we'd have a crash that affected as many people as > this decision seems to, I might be involved in getting a point-release out > with some kind of fix or backout. When we have a crash, how do we estimate the number of users it affects, e.g., 10, 10000, or 10000000? What's the bar for a point-release? You suggest that this issue exceeds that threshold. Can you share how you've estimated that?
Totally agree with Chris' comments above. This is the first "feature" on Firefox which might actually make me consider another platform. Really wish 1.5 was dropped in favor of 1.1, adding only strong password requirements for MP (which would take care of some of the criticism against MPs).
(In reply to Chris Karlof [:ckarlof] from comment #52) > When we have a crash, how do we estimate the number of users it affects, > e.g., 10, 10000, or 10000000? What's the bar for a point-release? You > suggest that this issue exceeds that threshold. Can you share how you've > estimated that? It's not an exact science, numbers there are just helpers for the decision, esp. when it comes to doing point-releases. The last one we did, 29.0.1, was not due a crasher but due to PDF printing not working, which is an edge cases feature but when used, it is pretty important to work. For crashes, we have done point-releases for issues that only concern a certain family of old AMD processors some time, maybe less than 1% of our users, but 1% of our active daily instances is still millions of installations affected. And if there are severe security or privacy risks, we have done chemspill releases scrambled into 24h without any significant amount people being affected yet. And this is an issue closely related to privacy (help is saying that people should abandon local privacy if they want to use Sync). All I can go with in an estimate like this is my feeling. Even more so as nobody can tell how many people are actually affected by this, or can you?
I filed Bug 1013448 to help us be more evidence driven in this and future decisions regarding master password.
I feel exactly the same as Ben Kennish about this issue. I also have just recently promoted Firefox Sync + MP on my blog as a convenient _and_ secure FLOSS solution, for example for those who used to use Xmarks or LastPass: http://odoepner.wordpress.com/2013/12/14/how-i-manage-my-website-logins-using-firefox/ I have been a Firefox supporter since Firebird days, my name was on the one page ad during the getfirefox campaign and I have worked as a volunteer in Germany doing Firefox support for years. What frustrates and angers me are statements from Mozilla developers (?) that folks like Ben, me and others are "unusual", followed by anecdotes about a majority of users who would supposedly be challenged by the necessary steps for a secure sync as in 1.1 with MP and "pair a device" dialog. Who are you developing Firefox for these days? I would expect that a lot of the old school Mozilla community and a lot of folks who have some IT background prefer the more secure sync 1.1 and MP. Your eagerness to "kill" sync 1.1 makes me wonder who at Mozilla actually uses Sync for their own passwords? Is Firefox developed by people don't use it themselves anymore? How do the Firefox developers sync passwords and keep them secure? If you guys were a for-profit business that has to sell as many copies as possible, then I would somewhat understand your lowest common denominator reasoning about the "majority of users". Firefox has been in the business of leading the web in the right direction. In many ways I still see that happening, for example with asm.js and Firefox OS. But the Firefox 29 release and this Sync "upgrade" make me feel lilke Gnome 3 all over again (i.e. remove features and declare that as progress). Without the "Classic Theme Restorer" Firefox 29 would be unacceptable for me. But of course that is off-topic in this thread. I can only hope that Mozilla is not yet fully undermined by the arrogance that some of you display here on Bugzilla. Thank you if you have read until here. Please consider: If Mozilla continues to target the lowest common denomiator and continues to break advanced features and extensions with every release you will one day not like your own product anymore.
I just noticed that the comments on the official announcement of the new Sync are mainly negative, along the same lines as the complaint filed in this bug. It is quite astounding how the change is presented as an improvement when really it is a step backwards in many ways: https://blog.mozilla.org/services/2014/04/30/firefox-syncs-new-security-model/
Thanks for sharing your concerns - but I think we are conflating a few points here. (In reply to Oliver Doepner from comment #56) > Your eagerness to "kill" sync 1.1 makes me wonder who at Mozilla actually > uses Sync for their own passwords? Is Firefox developed by people don't use > it themselves anymore? How do the Firefox developers sync passwords and keep > them secure? Without implying I speak for anyone else, I believe most Firefox developers believe the new sync is materially as secure as the old one - there certainly are different tradeoffs, but I have no problem syncing my passwords with the new sync. https://blog.mozilla.org/services/2014/02/07/a-better-firefox-sync/ has some background on this. The issue in this bug is about the fact we no longer sync your passwords if you have a master-password enabled. We realize this is a significant limitation and we are working on a fix to bring things back to parity with the old sync. We do take this issue seriously, and the fix will almost certainly involve storing the FxA credentials in the login manager, so would be as protected by the master-password as any other passwords are. > Thank you if you have read until here. Please consider: If Mozilla continues > to target the lowest common denomiator and continues to break advanced > features and extensions with every release you will one day not like your > own product anymore. I agree with your concerns here, but don't believe this is a reflection of that - we believe the new sync remains secure, and based on quantitative research, believe it also lowers the barrier to entry for a significant number of users. That sounds to me like a win-win. If you believe there are weaknesses in the new sync (which is independent of the master-password issue), then our security team would be happy to discuss them with you - but this isn't the bug for that.
Is there a bug for the fact that username/password authentication is generally less secure than the "pair a device" approach? See some reasoning here, for example: https://blog.mozilla.org/services/2014/02/07/a-better-firefox-sync/comment-page-1/#comment-490
I am glad that the team is looking at this seriously, it is a serious issue and one that needs to be fixed. When I found out about the new Sync not supporting Master Passwords but the only way to Sync when a Reset Firefox was completed, it really really frustrated me. Quantitative Research is good when it is checked to make sure that it is providing an improvement in the product. I agree that using it to remove features that are not valuable can be useful, but taking away security layers does not make a product better. Enhancing the ease of use with the same security levels would improve the product. Consider if your vehicle manufacturer only created 5 keys for all their vehicles and they were all blue in colour because they found that through their quantitative research that is the colour most people wanted. Same idea, no master password and you have a host of people using similar passwords. I fully agree with Oliver on the uid/pw security and that is why Google Authenticator exists. Uid/pw is convenient, and that is why I prefer to use it.
(In reply to Mark Hammond [:markh] from comment #58) > We do take this issue seriously, and the fix will almost > certainly involve storing the FxA credentials in the login manager, so would > be as protected by the master-password as any other passwords are. Great to hear. Thank you for the update!
So how about using syncing the passwords along with the master password; syncing the master password along with the saved passwords? I realise that the master password would then have to be 'stored' in mozilla's server, so as an alternative; Maybe instead of using a master password, if you wanted to use the 'master password' you would have to login to your mozilla account if you wanted to use the stored passwords? In any case, if you're not connected to the internet then I don't see why you would want to access your passwords... so if you were just checking a password by loading up firefox, the only reason for finding out the password would be so you can login to a site, REQUIRING internet anyway... and if your mozilla sync account was hacked, can your passwords be stolen anyway if you've set up sync for passwords? (or is there a 'was this you' message if the passwords are synced to an unknown PC?)
It is easy to imagine that I have some other internet access but not via my computer. Or I need to remember a password for later use via another computer. I can then use "show passwords" to retrieve a password I need even though my machine is not internet connected. I am a little confused about why this is hard. Can't sync just trigger the password vault master password request if it hasn't already been provided in this session? And then can't it get at the passwords? Note that in my case, I use a master password on the netbook I travel with, but not on my home computer. Please don't assume that all the sync partners either use or don't use a master password.
@Greg Why do you need internet if you are accessing some page in your company network without internet access, or some server that is only available via VPN that blocks any other internet access, or some server that runs on your local machine while you are offline in the train, on the plan or in your garden? ;-) (At least the last two cases are actually valid use-cases for me and I heard about the first one)
(In reply to Richard Newman [:rnewman] from comment #8) > In general: I encourage you to use BitLocker (Windows), FileVault (Mac), or > similar disk encryption tools, along with your OS's memory isolation > techniques, instead of (or as well as!) Master Password. > By contrast, Master Password protects *only* your passwords, and it does so > with a relatively weak encryption step (about as strong as the raw entropy > in your master password itself, which isn't much unless you've typed a poem > or an AES key). Amongst other places, I use firefox on my home computer and on a work computer. As a security-conscious person, my home computers' hard drives are encrypted. As a security-conscious company, my hard drive at work is encrypted as well. At work, I use a master password and at home I do not. Why? As my work computer is a domain-based computer, my entire hard drive is open for anyone on the network with administrative privileges to browse, modify, copy from, etc.. The computer is company property, so I'm fine with that. At this point, I assume you can see where I am going here. Prior to this bug, I could freely synchronize my passwords between my home computer and work computer with the knowledge that - unless IT had installed a keylogger - my FireFox passwords were secure / safe from prying eyes. Now that a master password and synchronization are mutually exclusive, I am forced to choose between (a) synching my passwords and allowing IT access to all of my passwords or (b) not synching my passwordss
(In reply to Mark Hammond [:markh] from comment #58) > The issue in this bug is about the fact we no longer sync your passwords if > you have a master-password enabled. We realize this is a significant > limitation and we are working on a fix to bring things back to parity with > the old sync. We do take this issue seriously, and the fix will almost > certainly involve storing the FxA credentials in the login manager, so would > be as protected by the master-password as any other passwords are. Thanks Mark. Will we be able to continue using Sync 1.1 (using Mozilla's servers) until this time? Cheers, Ben
(In reply to Ben Kennish from comment #68) > (In reply to Mark Hammond [:markh] from comment #58) > > The issue in this bug is about the fact we no longer sync your passwords if > > you have a master-password enabled. We realize this is a significant > > limitation and we are working on a fix to bring things back to parity with > > the old sync. We do take this issue seriously, and the fix will almost > > certainly involve storing the FxA credentials in the login manager, so would > > be as protected by the master-password as any other passwords are. > > Thanks Mark. Will we be able to continue using Sync 1.1 (using Mozilla's > servers) until this time? > > Cheers, Ben Taking this one step further, I am considering uninstalling 29.0.1 and reinstalling 28.0 in order to use Sync 1.1. So it's two questions here: 1) For how long is it possible to continue using 1.1? 2) Is it possible to create a new Sync 1.1 account? (Believe they have been answered before, not sure though).
(In reply to Michail Pappas from comment #69) > Taking this one step further, I am considering uninstalling 29.0.1 and > reinstalling 28.0 in order to use Sync 1.1. 29 can use Sync 1.1 if it has been set up in the profile with an older version. You could install a separate copy of 28 to set up Sync 1.1 and then move to 29 and continue to use it. Sync 1.5 is only used if you set up Sync with 29 or newer.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #70) > (In reply to Michail Pappas from comment #69) > > Taking this one step further, I am considering uninstalling 29.0.1 and > > reinstalling 28.0 in order to use Sync 1.1. > > 29 can use Sync 1.1 if it has been set up in the profile with an older > version. You could install a separate copy of 28 to set up Sync 1.1 and then > move to 29 and continue to use it. Sync 1.5 is only used if you set up Sync > with 29 or newer. Thanks. Any idea for how long will 1.1 be supported? Mostly afraid of corruption in the sync'ed data...
@Björn and @Marc, I was suggesting having to login to access passwords as a temporary solution to get the problem solved quicker, and then it could be sorted so you don't need to login and master passwords could be synced with other devices that don't have master passwords In any case if you are using Firefox's password manager to store passwords for places other than internet sites, maybe you should consider using a password manager anyway that has a firefox addon, like roboform or LastPass
(In reply to Michail Pappas from comment #71) > Thanks. Any idea for how long will 1.1 be supported? Mostly afraid of > corruption in the sync'ed data... It's unclear at this point when Sync 1.1 will stop to be supported, but there will not be corruption to data when it is. You probably will be offered some kind of migration to 1.5/FxA at that point, but AFAIK that code is not written yet.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #73) > You probably will be > offered some kind of migration to 1.5/FxA at that point, but AFAIK that code > is not written yet. And we will have fixed the underlying problem and re-enabled password synching for master-password users by then.
@Greg and why should I want to do that? If you assume I don't need those passwords synced, this is plainly wrong. I still need those passwords synced to all devices that are in that same network.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #73) > It's unclear at this point when Sync 1.1 will stop to be supported, but > there will not be corruption to data when it is. You probably will be > offered some kind of migration to 1.5/FxA at that point, but AFAIK that code > is not written yet. Thanks for the clarification. (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #70) > (In reply to Michail Pappas from comment #69) > > Taking this one step further, I am considering uninstalling 29.0.1 and > > reinstalling 28.0 in order to use Sync 1.1. > > 29 can use Sync 1.1 if it has been set up in the profile with an older > version. You could install a separate copy of 28 to set up Sync 1.1 and then > move to 29 and continue to use it. Sync 1.5 is only used if you set up Sync > with 29 or newer. Worked perfectly, with the exception of my Android devices: could not find a way to add them to sync...
(In reply to Michail Pappas from comment #76) > (In reply to Robert Kaiser (:kairo@mozilla.com) from comment #70) > > 29 can use Sync 1.1 if it has been set up in the profile with an older > > version. You could install a separate copy of 28 to set up Sync 1.1 and then > > move to 29 and continue to use it. Sync 1.5 is only used if you set up Sync > > with 29 or newer. > > Worked perfectly, with the exception of my Android devices: could not find a > way to add them to sync... Just to clarify the implications here: I elected to *remove* firefox from my 2 Android devices altogether, since I could not connect them to the old Sync infrastructure. A minor hint on how important master password+sync is in my case...
@Michail just use the same procedure. Install an old version from https://ftp.mozilla.org/pub/mozilla.org/mobile/releases/28.0/, add the device to Sync and then upgrade to the latest version.
@Björn: Thank you! Will do this later on!
I fully agree with Michail. The implementation of this new Sync feature is a disaster. I guess I am the "usual" user. So much so that this issue inclined me to sign-up for an account and write about it. I don't monitor bug files. I don't participate in intricate security discussion. I just know what is need to keep my passwords safe while using Firefox. If you have a MP feature, then people would use it. This is COMMON SENSE. If I'm such an "unusual" user category as many FF developer categorize me to be, then I am wholeheartedly flattered - or lack common sense, either way. But this is not the point. My point is I consider myself an layman and this new Sync not only failed to address user needs of password sync and in-fact broke this feature. This is my first post, btw. So using layman analogy, this new Sync is like a layman using an Apple iphone (not Android, b/c layman cannot figure out Android) and unable to use iCloud (which includes Apple Keychain btw) UNLESS a device password is REMOVED. How obscure is this?? How far along do you think Apple would be if they have implemented iCloud this way? Not very long. And by this day and age, I think there are many laymans out there would have created Apple iphone device passwords. Although, I could be a technological super-star to have use one. Either way, Yes, Michail is totally correct on this issue. The architecture of the "new" Sync should be scrapped and re-examined entirely.
(In reply to Bruce from comment #80) > ... The architecture of the "new" Sync should be scrapped and > re-examined entirely. Obviously there have been some roadmap issues, and possibly shortcomings with laying out the requirements for stage one in advance. That being said, mistakes do happen, and a solution is being worked on intensively - on this and other bugs. I don't think it should be scraped, and the overall design is both solid and scalable, even if the implementations are not yet full. And I'm saying this as someone who still uses the old sync because I want to use MP. Patience, and hopefully next time we'll be able to see more issues while laying out the roadmap for new features.
I'm considering setting up sync and found this issue. Please help me understand. I read that sync data is encrypted in the browser, and only an encrypted blob is sent to Mozilla servers. As far as sync is concerned, I might as well be uploading encrypted pictures of cats and Mozilla wouldn't know. Is that still the case with the new sync framework? So, what stops Firefox from uploading the encrypted password store to Mozilla servers, then downloading it on another device? I could use the password store on another device by unlocking it with the same master password. The sync framework doesn't even need to know the master password, unencrypted passwords shouldn't be sent over the wire, that would be a disaster. Let's put aside the debate about how useful master passwords are. I'm just suggesting that the MP-protected password store could be easily synced between devices, and it could be opened on all devices by the user only, with the same MP across devices.
(In reply to Jozsef Fejes from comment #82) > ... As far as > sync is concerned, I might as well be uploading encrypted pictures of cats > and Mozilla wouldn't know. Is that still the case with the new sync > framework? Yes. > So, what stops Firefox from uploading the encrypted password store to > Mozilla servers, then downloading it on another device? Nothing. This is indeed how it works. > I could use the > password store on another device by unlocking it with the same master > password. The sync framework doesn't even need to know the master password, > unencrypted passwords shouldn't be sent over the wire, that would be a > disaster. The sync system doesn't know any of your passwords, and no password is ever sent unencrypted and it's impossible to decrypt them outside of your computer. The issue is that it's not working well right now if you have a master password, and it's being worked on. > Let's put aside the debate about how useful master passwords are. I'm just > suggesting that the MP-protected password store could be easily synced > between devices, and it could be opened on all devices by the user only, > with the same MP across devices. That might be a valid solution. But a solution is already being worked on right now and it's near final stages. Some problems have many solutions, and a good solution is already on its way.
(In reply to Jozsef Fejes from comment #82) > So, what stops Firefox from uploading the encrypted password store to > Mozilla servers, then downloading it on another device? I could use the > password store on another device by unlocking it with the same master > password. That's not how things work. The master password encryption technique is very weak and easy to break (there are different bugs on that), using that encryption for Sync would be a bad idea. Also, master passwords on different machines are completely independent. So what Sync does is to first read the actual password from password manager in a decrypted fashion, then encrypt it with the high-grade encryption technique used by Sync and only then sending it to the Sync server. And that's why there is some interplay there between the two.
I very rarely reply to comments here or report bugs anymore. Most of my interest in Mozilla Firefox has been the rendering engine and most visible bugs there have been fixed in the last 7 or 8 years. I have been using Firefox since it was called Phoenix so I am familiar with the SOP of Mozilla. The only danger here is physical access to other people's machines (stolen computers, etc...). Even Linux, itself, is vulnerable to that. I can steal a computer, boot a rescue CD, chroot into the disk and change the root password and then gain access to the machine. The only protection against it is something like LUKS encryption. This is analogous to the master password mechanism in Firefox. With the rapid release cycle, some incomplete features occasionally slip through. But at this stage in product maturity, it won't happen often so don't lose faith in Mozilla ;) I admit that there is some loss of functionality and "customer sense of security" here. I am calling it a "sense of security" because it is very subjective and the lack of it is not always the end of the world. Sure it is not an optimal situation but Comment #1 already indicated that they are working on a solution that allows you to use Sync 1.5 and still secure your passwords with a master password. This is probably simply taking time do to what I think are changes between old Sync and new mechanism. I am sure the developers also want their passwords to be physically secured so this is affecting everyone and not just you and your clients. However, I would like to ask. While I understand the sarcasm in the first part of your comment as you were trying to prove a point, which "large IT company" lets its employee post things like "Seriously you nutters, what an extreme f**k up by Mozilla" on software bug trackers?
(In reply to Hussam Al-Tayeb from comment #86) > However, I would like to ask. ... While a retort is not uncalled for, let's keep this on topic. Thanks.
(In reply to Dell from comment #85) > ... the removing of the MP was pure genius... Master Password hasn't been removed. Please stop trolling. And I remind you to follow Bugzilla Etiquette: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Why not just use the same information that is stored on the sync servers locally, and access it with the same method and password that is used for sync? If the local passwords file isn't encrypted, it's a security hole. What stops any application running on the machine from getting access to the passwords stored there?
Depends on: 1013064
No longer depends on: 986637
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
No longer depends on: 1013064
Users understand that even once resolved there will be a window for testing and editing before the fix is rolled out. How about sharing when users (of the release version) might expect to see the fix? Thanks for the hard work many people contributed / are contributing to get this fixed!
Bugzilla UI is cryptic, but bug 1013064's target milestone of 34 is what indicates that we're shooting to have this "ride the trains" to Firefox 34.
Ok fellas need some help with the workaround presented above to use old-type sync on Android devices: at the time it was instructed to install mozilla/fennec 28.0, configure its (old-type) sync and THEN let it upgrade to the latest firefox version. This way it kept the old-type sync. I have upgraded my nexus 7 tablet to Android L and on this platform although installation of fennec 28 is possible, trying to actually run it throws an error. Does anyone know a workaround? That is install *and* run an old-type sync firefox client on Android L, without having to root the device (if rooted I could backup my working recent ff with its old-type sync and restore it in its entirety with titanium backup)? Any help will be appreciated. And apologies for this bug-report partial hijacking...
Michail: You shouldn't need to install an older version of Firefox. You just need to manually add a "Firefox Sync (deprecated)" account using the Android's Settings->Accounts section. This has worked for me up until the current Firefox stable release (v33.1)
(In reply to Ben Kennish from comment #94) > Michail: You shouldn't need to install an older version of Firefox. You > just need to manually add a "Firefox Sync (deprecated)" account using the > Android's Settings->Accounts section. This has worked for me up until the > current Firefox stable release (v33.1) Ok, I definitely feel like an idiot here :) Thank you for the advice, worked like a charm!
Bug 1013064 is marked as VERIFIED FIXED but this bug is not. Does the status of bug 1013064 indicate that this bug will be fixed soon and I can start using sync 1.5 with a Master Password?
This is marked as a duplicate of a verified fixed bug - you should consider this bug fixed too. So yes, you can.
Excellent. Thanks, Mark B-)
Is it really resolved? I still have to disable the master password to sync passwords, on Firefox mobile (Android) v48.0. What I do: - start with a fresh installation on android (4.4). No data, no cache for Firefox app. - set the master password - connect to my sync account - save this account password (it asks for my master password) - go to the passwords screen and look at the password (to validate that the password database is unlocked) - validate the new sync device (via the link in the confirmation email) - wait for sync completion - reload the password database: no other password was synced Then I disable the master password, force another sync, and all my passwords are here.
This bug was for desktop. MP and syncing shouldn't work on android. Sometimes it does, but it shouldn't.
OK. I see.

Hi, i'm getting this error. Sync works as i can see the updated bookmarks, but for the love of Password Managers gods, i can't sync passwords. I use master password.

Ubuntu Linux 18.04
Firefox 67.0

The other system is Archlinux, with the updated firefox.

As a developer, I travel around and i switch from working from the pc to the laptop a lot.

What i been doing is keeping chrome around because it can sync properly, and i just have to open it to get the old passwords.

(In reply to leite.carvalho from comment #102)

Hi, i'm getting this error. Sync works as i can see the updated bookmarks, but for the love of Password Managers gods, i can't sync passwords. I use master password.

Ubuntu Linux 18.04
Firefox 67.0

The other system is Archlinux, with the updated firefox.

As a developer, I travel around and i switch from working from the pc to the laptop a lot.

What i been doing is keeping chrome around because it can sync properly, and i just have to open it to get the old passwords.

Please file a new bug with as much detail as you can include.

Flags: needinfo?(leite.carvalho)

hi, i think i got the wrong bug sorry. i replied in https://bugzilla.mozilla.org/show_bug.cgi?id=1013064, but can't find a way to delete this one

sorry for the noise.

Flags: needinfo?(leite.carvalho)

(In reply to leite.carvalho from comment #104)

hi, i think i got the wrong bug sorry. i replied in https://bugzilla.mozilla.org/show_bug.cgi?id=1013064, but can't find a way to delete this one

sorry for the noise.

That bug is closed. You're more likely to get timely help if you file a new bug.

You need to log in before you can comment on or make changes to this bug.