+++ This bug was initially created as a clone of Bug #524403 +++ I recently ran across "Firemaster", a master password cracking tool (http://www.securityxploded.com/firemaster.php). The keys-per-second claimed seemed higher than I was expecting, so [see bug 524403 for how NSS protects softoken's master password, which is Gecko's master password]. This has been the topic of many discussions internally. See, in particular, the security-group thread with subject "Password Manager Brute Force Vulnerability." See also https://mail.mozilla.org/pipermail/sync-dev/2013-August/000196.html. Jonas, Paul, and I also discussed it within the context of B2G. Christiane Ruetten, Paul, and I also discussed the issue within the context of B2G, and Paul arranged for some non-crypto improvements to master password management in B2G which landed in B2G 1.2 or so. It has also been brought up many times regarding Google Chrome, which does things very similarly to how Firefox does things, as far as this is concerned. See and see the Chrome security team's initial response at https://news.ycombinator.com/item?id=6166731: I'm the Chrome browser security tech lead, so it might help if I explain our reasoning here. The only strong permission boundary for your password storage is the OS user account. So, Chrome uses whatever encrypted storage the system provides to keep your passwords safe for a locked account. Beyond that, however, we've found that boundaries within the OS user account just aren't reliable, and are mostly just theater. Consider the case of someone malicious getting access to your account. Said bad guy can dump all your session cookies, grab your history, install malicious extension to intercept all your browsing activity, or install OS user account level monitoring software. My point is that once the bad guy got access to your account the game was lost, because there are just too many vectors for him to get what he wants. We've also been repeatedly asked why we don't just support a master password or something similar, even if we don't believe it works. We've debated it over and over again, but the conclusion we always come to is that we don't want to provide users with a false sense of security, and encourage risky behavior. We want to be very clear that when you grant someone access to your OS user account, that they can get at everything. Because in effect, that's really what they get. I believe that some people on the Chrome Security Team may have shifted their opinions since then. I'm not up-to-date with what the Chrome team things here. The "Password Manager Brute Force Vulnerability" thread had many messages. I will only quote my own email, which quotes bits of others. Mike Connor wrote: > On 2012-03-18, at 5:52 PM, Christian Holler wrote: > > On 03/18/2012 10:44 PM, Johnathan Nightingale wrote: > >> On 2012-03-18, at 6:49 PM, Asa Dotzler wrote: > >> > >>> And I'm suggesting that if it's not super easy and quick to fix, > >>> that we don't spend the time fixing it. We have bigger fish to > >>> fry, don't we? I agree! > >> Isn't the typical response to offline attacks to just add multiple > >> rounds (and the old standards, salting, &c)? If so, isn't this a > >> trivial fix? Sort of. I believe that everybody has a master password and people who haven't set it just have a master password of "" or so. This means that if you salt and then iterate the key strengthening operation (PBKDF2) then with the current design, *everybody* (even people who haven't set a master password) would get slower Firefox startup time approximately proportional to the amount of strengthening that you want to do. Making Firefox startup time slower is not something I am eager to do. > > There are two things that seem to make this a non-trivial fix > > (from what I've read so far): > > > > 1) The code is NSS, and I don't know what other components use the > > same code (in fact, I haven't even located the exact position in > > the NSS code yet, where this is implemented because this is some > > generated macro jungle...) > > 2) You need a migration path. If you make the change in NSS, then > > that > > seems hard to me (you would probably have to add fallback code in > > NSS, > > not sure if that is the right way). These are not serious barriers. I can help you figure it out and we can probably figure it out faster with help from Kai and/or Bob and/or Nelson. I have already written a patch for a similar problem in NSS recently. > 3) The reality of the perf overhead of doing the derivation, and the > question of how much entropy we're really adding to a weak key, > means we probably still aren't done even if we do this. Especially > if users are actually thinking like "crypto means my data can't get > accessed." This man is correct on all counts! There is nothing you can do with a key strengthening algorithm that will turn a really weak password into a strong one. For example, let's say you were willing to slow down startup time by 1 minute. If the user chooses "password" as his password, then it will take approximately 1 minute for an attacker to get the user's data. Most estimations of the benefits of key strengthening algorithms that I have seen say that they add the equivalent of, at most, 16 bits of entropy to the user's password. That means the user still needs quite a few dozen bits of entropy in their password--AFAICT, more than most (but not all) people are willing to type into their computer over and over again. > First, we have to agree on what we're actually trying to solve. Is > it "providing industrial strength crypto.for credential stores"? Is > it "giving users enough time (i.e. a few days) to change their > passwords before an attacker can obtain the old ones"? Or is it > simply "not be worse than our competitors"? Or, as Asa said, are we > simply raising the bar past casual snooping? I don't think that's > clear, yet. > Once we know that, if we're going for harder security we should be > objective about our options. I agree! I have always assumed that the master password mechanism was, at best, a barrier to casual snooping. After all, the ease at which one can crack a Firefox master password is well-known and there are well-known tools for doing so. See, for example, this blog post from 2010: http://www.symantec.com/connect/articles/password-management-concerns-ie-a nd-firefox-part-two "Firemaster is a password cracker that was designed to derive the Master Password in Firefox . [ref 29] The tool, written in C++, was released by N. Y. Talekar in early January 2006; the source code is current available online. Other tools written in C with scripting functionality have also been developed . [ref 30] As a result of the development of these tools, the confidentiality of the password database is completely reliant on the Master Password to withstand these attacks." As Mike touched on, the current master password system isn't even particularly good at preventing casual snooping in common real-world situations. E.g. you have a bunch of tabs open and your friend wants to check her Facebook. Our master-password/profile-manager UX for handling that situation is basically unusable. AFAICT, it is, by far, much easier and much more effective to protect your private data using operating system passwords/account mamagenment/encryption than it is to use Firefox's master password mechanism. E.g. on Windows, when you let somebody else use your computer, use Fast User Switching to switch to the low-privilege Guest account for them, put a password on your account (and never use the guest account yourself), and enable BitLocker with TPM support. In an ideal world, we would be able to educate our users about how much better the operating-system-level protections are to what Master Password does or, AFAICT, could be made to do, so that we could remove the master password feature without people throwing fits. However, in the the real world, there are things that push for keeping it around and trying to make it better--e.g. the continued existence of Windows XP, the (new) Persona stuff, the difficulty of getting people to understand why the OS-level protections are better, our unwillingness to tell our users that it is critical for their security that they don't root their Android phone, our desire to usurp traditional operating systems with web apps running in Firefox/B2G by building OS functionality into the browser, the fear of people saying bad things about us for removing such an important security feature despite it (AFAICT) being mostly counterproductive to its aim, etc. So, I agree (again) with Mike that it is important to have the Product team indicate how important this feature is to them and on what timeframe they want to see what level of improvement. And, I agree with Asa and Christian that removing the feature is better than having a poor implementation of it. Cheers, Brian "Agrees with Everybody" Smith ---------------------------------------- Ben Adida wrote: > I think what bsmith is saying is that *everyone* has a master > password, even users who haven't set one: it's set to a default of "". > This makes sense because when someone wants to set a master password, > you don't want to have to encrypt their whole profile, better to just > rewrap the key that encrypts their whole profile. Right. At least, this is what I remember when I dug into it before. > That said, one could also store the work factor for a given stored > wrapped key and keep the iteration count low for the default case, > upping it for when a user actually sets a true master password (not > ""). This logic branch on number-of-iterations would be necessary > anyways for backwards compatibility. Yes. This is not hard to do. The other option is to simply try with one iteration and then, if that fails, try with 10,000 (or whatever) iterations. Then you don't even need to store the work factor. Being able to support the user sharing a profile across multiple channels (Nightly-Release) and/or downgrading to an older release is more problematic. One way to avoid problems here would be to ship the change for Gecko trying more iterations for a few releases, before ever actually increasing the iteration count when writing the file. This way, even if the user downgrades or shares a profile across multiple channels, all the channels will be able to deal with the file. > Since you're assuming device compromise, which is a one-off attack > rather than a large-scale like phishing, does this provide any real > protection? > I don't know exactly how that applies to FF, but I do think the > categorization of attackers is probably something like "attackers who > will use a password cracker" v.s "attackers who won't." I'm not sure > there's a meaningful line between "attackers who will use a password > cracker for 10 seconds" and "attackers who will use a password > cracker for 2 hours." Right. Also, if an attaker can steal the files out of your profile, they can also probably install extensions into your profile, and in particular they can probably install an extension that steals your password(s). Cheers, Brian --------------------------------------------------------------- Christian Holler wrote: > If you do a brute force attack, attempting to find the password, then > the entropy the algorithm adds is irrelevant. It is *only* about the > time the algorithm takes to derive the key, nothing else. Even if the > password is low entropy, it will take a lot of time iterating through > that search space. What is your definition of "a lot of time"? Is the attacker a BitCoin miner with access to hundreds or thousands of ATI GPUs that could all be repurposed for weeks or months to crack the password? How much less/more sophisticated than that is the attacker? > I don't fully understand this argument. We say something is well > known so it surely was designed like that? Kind of a weak argument > to me. Since this tools exists, the bug report exists to close this > vulnerability. And yes, this is a vulnerability to me, and I am > pretty sure it is to most other security researchers as well. I mean: 1. We can discuss this on dev.security, because this isn't any secret. 2. This isn't something we urgently need to fix, relative to many other things. 3. Even regarding things related to the master password, this isn't the most urgent thing to fix. The UX problems (e.g. it is trivial for a website to spoof the master password dialog box and steal your master password) are much more serious. 4. Before we do anything to improve the master password mechanism, we should re-evaluate whether the feature's existence is even a net positive. Recently, all discussions about removing the master password (e.g. in Fennec) have boiled down to "People might feel butthurt and complain a lot if we did that, and call us stupid and say we don't care about security, so let's just keep it because that's easier." (Apparently nobody cares how much *my* butt hurts.) > We don't support key chain, or the windows cryptographic store, nor > the Gnome keychain and whatever else is available on Linux (Chrome > uses the Windows Crypto Storage API btw). It would of course be nice > if we would. But then again it's probably not trivial because it > needs to work with Sync. I do not use the master password feature at all, because I use the operating system's "master password" feature (including using the Guest account for guests, using BitLocker, and password-protecting my OS account) to protect my data. That has better usability and more comprehensive protection. My recommendation to everybody is to stop using the master password and start using the operating system's better features. Note that Android has, or can have, an operating-system-level master password too. Usually this is the connect-the-dots thing. Note that Firefox's master password can only protect some parts of your Firefox or Thunderbird profile. It would never protect your sexting pics on your phone. It would never protect all your financial information you have in Quicken. It would never protect your email in Outlook. It would never protect your AIM history. Operating systems' facilities can protect all of those things. We could make significant improvements to how well the master password / profile manager works, but fundamentally it is limited regarding the information that it can protect. This is why I consider the entire feature to be counter-productive to its aim: if we didn't have the feature, then users who care about such issues would be pushed in the correct direction of using the operating system's facilities, but since we do have the feature, we are confusing users into doing something that is, by far, and at best, suboptimal. That said, I know we want Firefox to be its own operating system of web apps within the operating system, and some of the features needed for that may require some kind of password mechanism. I don't know yet, because I don't know the requirements. Regarding Google Chrome's use of the operating system keychain mechanism: For certain kinds of data, e.g. the cookie store and other transient data, this is a good idea. I am not sure it is a great idea for non-transient data, even including passwords, because it interferes with backup/restore operations (both using real backup/restore software, and backup/restore of the "copy things to a flash drive" variety).

Since the time when I wrote the above email (which was a while ago), some things have changed. In particular, we have built the Firefox Accounts feature and people have been and/or are working on "sign into the browser." With that in mind, it seems like my originally recommendation of "remove the master password feature" makes less than it did before. Regardless, it is totally dumb to do just 1 round of PBKDF. Regarding the cryptography specifically, and ignoring all the more important issues such as the serious usability and security UI issues with the current master password UI, a big unanswered question is whether it is worthwhile to change the number of iterations done so that (a) the password is protected better, and (b) starting up Firefox doesn't become too slow. We should probably consider using GPU-accelerated PBKDF2 and/or a better key stretching mechanism to improve this preformance/security tradeoff. A second unanswered question is "does the rest of the stuff in the profile that isn't encrypted make this moot?"

I think there are still sane reasons to remove MP (ideally with a replacement -- extra points if that's an external-to-the-profile strong system keychain to support SITB). * We don't have a strong place to store FxA credentials (Bug 970167). It would be nice to have such a place. This is very relevant to your second unanswered question, in that if you have FxA set up and syncing your passwords, you might as well turn MP off. I've heard at least one suggestion that MP and FxA/Sync should be mutually exclusive. * MP is a pain in the ass for Sync users. They have to unlock their MP when the browser launches, and/or whenever they sync. When we used to *not* do that, users would wonder why Firefox hadn't synced for two weeks. * It's especially a pain in the ass for Sync users on Android, where we simply don't sync your passwords if you have MP turned on. * It might be a pain in the ass when we reimplement nsILoginManagerStorage in native Java. At the very least we'll have an opportunity to use more rounds, or a more usable implementation, of something akin to "Master Password". * Users continue to believe that it's strong.

See also bug 309807 comment 113 (and the rest of that bug).

I don't know what nsILoginManagerStorage provides or allows, though it looks (to me) like to make MP useful at all is to rewrite the whole credential management thing to allow easy and efficient (plug-in) integration of keychains / password management provided by the OS (and maybe even password managers like LastPass, 1Password, etc.), similar to the notification service in Gecko that was rewritten when WebNotifications were integrated (iirc) – there's a basic service for all platforms (XUL notifications), and e.g. on OS X the native NotificationCenter is integrated as a notification provider. (When I'm referring to "keychain", I mostly mean the way Keychain.app is built and integrated into OS X.) So that essentially means (1) creating a general wrapper (service) for a keychain management service and (2) creating a keychain-like standard service that is used by all platforms unless there is a provider/connector for the OS keychain/-service, in Gecko or NSS. All the Gecko stuff that touches this has to be rewritten to accomodate the new API as well as improve for speed and efficiency. (An advanced feature would be to allow storing profile data in a system's encrypted storage, e.g. the one used by the native keychain service – if that's feasible.) Or is the current infrastructure good enough for easy and efficient integration of OS keychain services, and the MP mechanism itself "simply" has to be rewritten? I guess there's a lot inside Gecko that should be rewritten (wrt MP etc.) to improve speed and efficiency either way (most MP usage is probably MT-blocking and in critical paths) – easiest way here is probably to rip that out completely and start from scratch.

Setting aside all the other concerns for the moment... I think the least-effort and most-narrowly-scoped solution to the specific problem that triggered this, would be to do the following with password manager... 1) Implement a PKCS#5 version of crypto-SDR.js. [SDR == Secret Decoder Ring, the current PSM interfaces to encrypt/decrypt strings.) This isn't too hard, as the crypto bits would mostly be cut'n'paste from WeaveCrypto.js. But a number of details to sort out around recreating the prompting for a pkcs5 password, how to change/reset a pkcs5 password, etc. 2) Teach storage-mozStorage.js about a new encryption type (ENCTYPE_PKCS5 vs ENCTYPE_SDR), and make it use the appropriate crypto module to encrypt/decrypt login data. 3) Write code to convert existing logins from SDR to to PKCS5 upon first trigger of the master password. I think this would be quite similar to the code we added for converting the ancient base64-obscured passwords to SDR-encryption in bug 316084, and recently removed in bug 717490. Ideally #1 and #2 should bake for a release or three so that users who downgrade from a post-#3 Firefox release will still be able to access their logins. ESR makes this a bit painful. Sync also makes this a little tricky, since it syncs the encrypted values (thus we'll have to be mindful of cases where sync brings back SDR-encrypted logins from some other device, which would need another migration done.) This gives us a nearly-identical replacement for the Master Password, but which uses stronger crypto and doesn't require any changes to NSS/PSM. It's not a massive amount of work, so if we get bogged down in resolving the bigger picture concerns around master password this may at least be the "better than doing nothing" option. That said, I think the existing Master Password feature is a UX disaster and nearly useless security-wise, and so it's not clear that even such a least-effort fix does anything more than fix a user perception issue. Of course user perception can be a huge deal, but we should be mindful of the cost/benefit.

(In reply to Justin Dolske [:Dolske] from comment #5) > Sync also makes this a little tricky, > since it syncs the encrypted values (thus we'll have to be mindful of cases > where sync brings back SDR-encrypted logins from some other device, which > would need another migration done.) Sync does not sync the encrypted values. It grabs nsILoginMetaInfo.password (and all of its other fields, too), which some quick poking around confirms is the cleartext password. If you think about it, there's no way Sync could sync encrypted passwords without requiring you to use the same master password on every device. More broadly: On Android we're very likely to implement our separate nsILoginManagerStorage (to solve other issues), backed by an Android-side passwords ContentProvider, likely stored in JSON. If our product managers decide that we want to ship Master Password parity after that change we'll do it entirely independently -- we won't expect nsILoginManager to be layering crypto on top. This will allow us to apply whatever strength we wish, with no Gecko interop concerns, and also provide a much better UX (e.g., notifications requesting unlock, unlock periods independent of GeckoApp lifecycle, using the Android lock screen implementation as a key, etc.).

(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #0) [...] > Sort of. I believe that everybody has a master password and people who > haven't set it just have a master password of "" or so. This means that if > you salt and then iterate the key strengthening operation (PBKDF2) then > with the current design, *everybody* (even people who haven't set a master > password) would get slower Firefox startup time approximately proportional > to the amount of strengthening that you want to do. We already defer this work until the first time a password needs to be decrypted. That may be well after startup. But, yes, it could also be during startup if an add-on wants a password, or if a web page loads during startup (eg, a pinned Gmail tab asking for a login), or if it's part of a "sign in to the browser" kind of feature. [...] > > We don't support key chain, or the windows cryptographic store, nor > > the Gnome keychain and whatever else is available on Linux (Chrome > > uses the Windows Crypto Storage API btw). It would of course be nice > > if we would. But then again it's probably not trivial because it > > needs to work with Sync. > > I do not use the master password feature at all, because I use the > operating system's "master password" feature (including using the Guest > account for guests, using BitLocker, and password-protecting my OS > account) to protect my data. I've been wary of switching to the OS-provided keystores, for a few reasons: * Sync is likely going to need a new backend for _each_ of them. This is a nightmare. * Even ignoring Sync, we'd have to write (and maintain!) each of those backends. We're already stretched ridiculously thin. Lots of work for low value. * As you note, this does nothing for cookies or other sensitive data in your profile. * Some of the OS facilities are crappy to use. Last I looked, the Windows API that was en vogue only let you retrieve data by providing hash(url, fieldname). Which means you can't really see what sites you have data stored for, selectively clear private data, and I've no clue how Sync would work. Also, last I looked, Keychain didn't provide enough flexibility for Chrome, and so they were trying to synchronize it and a Chrome-specific DB that held ancillary data. Yuck. [...] > Note that Firefox's master password can only protect some parts of your > Firefox or Thunderbird profile. [...] > Operating systems' facilities can protect all of those things. One blue-sky thought I've discussed with someone (you?) was to use encrypted profiles. The basic idea is that most modern operating systems have some way to encrypt folders, and so we could try to make use of that (plus some startup glue to prompt for a password). It's not as secure as WDE + user switching, but it's easy for a user to understand. (In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #1) > Since the time when I wrote the above email (which was a while ago), some > things have changed. In particular, we have built the Firefox Accounts > feature and people have been and/or are working on "sign into the browser." It's not clear to me that "sign in to the browser" is any closer than it was when it was proposed a couple years ago. So I wouldn't block on that. FxAccounts gives us the notion of an account/identity, but the functionality to make use of it for such things will be a large undertaking. (And raise a number of the same questions we're asking here.) That said, I think there's been pretty universal agreement that a single login upon startup (which secures your data, and ideally makes it accessible from anywhere) would be preferable to how MP works today.

(In reply to Richard Newman [:rnewman] from comment #6) > Sync does not sync the encrypted values. It grabs nsILoginMetaInfo.password > (and all of its other fields, too), which some quick poking around confirms > is the cleartext password. Hrm, you must be right (as if I would doubt ;). It doesn't sync key3.db, without which the encrypted values are useless.

(In reply to Justin Dolske [:Dolske] from comment #8) > Hrm, you must be right (as if I would doubt ;). It doesn't sync key3.db, > without which the encrypted values are useless. Indeed, on Android we seem to use key4.db (or have in the past), though nobody seems to know exactly why! (Syncing the encrypted values would be convenient, of course -- then we'd be able to sync your data without unlocking your password DB!)

(In reply to Richard Newman [:rnewman] from comment #9) > (In reply to Justin Dolske [:Dolske] from comment #8) > > > Hrm, you must be right (as if I would doubt ;). It doesn't sync key3.db, > > without which the encrypted values are useless. > > Indeed, on Android we seem to use key4.db (or have in the past), though > nobody seems to know exactly why! I believe that the dbm library (security/nss/lib/dbm) doesn't build and/or work correctly on ARM/Android. dbm is the database library used for the key3.db format. Since the sqlite-based format of key4.db was (is) intended to be "the way," and since there were no data migration issues for the brand-new platform, it was decided to use the key4.db format on Android from the start. > (Syncing the encrypted values would be convenient, of course -- then we'd be > able to sync your data without unlocking your password DB!) Especially on Android, the OS should be responsible for data storage security and we shouldn't try to layer our own on top of it. There's too much sensitive data on the phone to not be using FDE for all the user data on the phone, not just Firefox-specific data. I think an argument could be made that a different decision should be made for desktop Windows prior to Windows 8.1 since FDE wasn't widely available on Windows desktop until the very newest version of Windows, Windows 8.1, and even then there are serious issues with it. However, modern desktop Linux and modern Mac OS X (since 2011) seem to have good enough built-in encryption support to make Firefox's encryption superfluous at best and harmfully redundant at worst. (In reply to Justin Dolske [:Dolske] from comment #7) > (In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) > from comment #0) > > I do not use the master password feature at all, because I use the > > operating system's "master password" feature (including using the Guest > > account for guests, using BitLocker, and password-protecting my OS > > account) to protect my data. > > I've been wary of switching to the OS-provided keystores, for a few reasons: > > * Sync is likely going to need a new backend for _each_ of them. This is a > nightmare. I'm not sure what you mean here. With OS-provided encryption, the data is encrypted completely transparently to the application. Just read/write the data like normal, and it is decrypted/encrypted automatically. Even if we wanted to have an extra level of protection for passwords and cookies and other "really sensitive" stuff, the glue between the OS keychain and Gecko would be very little code. I'm not sure there is any advantage to this extra level of encryption though, if the user has FDE. And, if the user doesn't have FDE then they're already screwed in most cases where they would *need* encryption. > One blue-sky thought I've discussed with someone (you?) was to use encrypted > profiles. The basic idea is that most modern operating systems have some way > to encrypt folders, and so we could try to make use of that (plus some > startup glue to prompt for a password). It's not as secure as WDE + user > switching, but it's easy for a user to understand. Yes, we could encrypt the whole profile. But, why not just encrypt the whole computer? What value would we be adding over what the OS could do?

Clearing needinfo.

> One blue-sky thought I've discussed with someone (you?) was to use encrypted > profiles. The basic idea is that most modern operating systems have some way > to encrypt folders, and so we could try to make use of that (plus some > startup glue to prompt for a password). It's not as secure as WDE + user > switching, but it's easy for a user to understand. Encrypted folders of files are protect data only when computer is turned off! When system is loaded and user is logged in, any user can see files unencrypted (available protection is only via file permissions, so root user or system administratyr can see files of any users after user logged in and type encryption password). So this is not too hard to copy unencrypted Firefox password storage file (via virus, mailware app running with user permissions, or via hands - when user go away from computer - copy file to usb drive) and receive all user passwords. Also any system administrator will can get your passwords too. Therefore I use master password on each computer in addition with folder encryption (if needed) and vote for this bug that master password encrytion must be stronger. Also I want note, that in Firefox 29 syncing passwords with master password are broken, here is bug about this https://bugzilla.mozilla.org/show_bug.cgi?id=995268

(In reply to Murz from comment #12) > ... root user or system administratyr ... virus, mailware app ... There is no protection we can provide if another user has admin access on your system, or if you've been pwned by malware. Any of these can easily install a keylogger or read raw memory, and at that point it's game over. This scenario is off-topic for this bug.

Master password is easy to setup protection that protect passwords saved in files, so only keylogger and read raw memory will can get passwords. And setup master password is much easier that encrypt all home directory, and it protection are better that folder encryption, because protect passwords in profile folder copied files too (for example, in backup). So master password is better solution for protect passwords and encryption must me stronger.

As I mentioned in bug 995268, one idea here could be to bring MP and FxA/Sync closer together, either by making passwords protected by the FxA password (if set, or maybe by FxA itself) or maybe going as far as to do it by even just storing the same password-stretched-key-encrypted object in the password store that we also transmit via Sync (which would make Sync's job easier and our storage more secure at the same time).

Please see the Description of bug #1034629 for a possible suggestion.

Excuse me to post here but my issue is simple 'is that this complicated to improve the crypto ?" I mean : a) it should easy to find better than something broke easily by bruteforce in 2006 b) it's not like there is no good crypto function available in gecko or in js (I'm not familiar with the layer where master operates so I don't know which you can use) c) the migration is complicated just wrap arround the new encryption when the user type for the first time is password in the version and then delete the previous file d) I read there's something about strart-up time : I don't understand as master password is required only when a site to login is detected, and I don't think encryption is nowadays a hard task for computers e) FxA is not going to help us because what we want with master password is permanent crypto except when we choose to type our master password to login on to a site and for the remaining time it's kept active(which I'm not sure it even exist and is not that useful) Please explain why I'm wrong here, because if I'm not I don't see what's preventing to be implemented quite rapidly and secure a lot of people passwords which are the core of their digital life. Sorry for my maybe hungry tone, but discovering that master password is 'broken' for so long and that when you read mozilla help it seems to be quite good crypto (3DES even if it's quite old) and it's not mentioned it's that much broken(when I read it didn't check again). This is just insane.

(In reply to David E. Ross from comment #20) > Placing a decrypted password into a file is a very bad idea. If the > application crashes without deleting that file, the user is then exposed to > a potential disclosure of the password. Decrypted passwords should exist > only in memory. I agree however, wasn't the new file with the new encryption scheme the guy was referring to also encrypted? (I believe this should also apply to any scheme container, not just local filesystem files.) > Given that the master password should also exist only in memory, I would > prefer that site passwords be decrypted each time they are needed. Got no question to that if it's only about using the stored key to decrypt the password every time a site would need it (not always asking for a password), but otherwise it should be a user preference. Adding an option to customize the amount of time a stored key can be allowed to stay in memory can also be considered.

Question: Is this about making the master password itself more secure (which seems to reflect the Summary)? Or is this about making use of the master password more secure? If the former, that is really the end-user's responsibility: to choose a character string for a master password that is sufficiently long and obscure to be secure. If the latter, please modify the Summary.

(In reply to David E. Ross from comment #23) > If the former, that is really the end-user's responsibility: to choose a > character string for a master password that is sufficiently long and obscure > to be secure. It should also use cryptography that's not easy to defeat - see comment 0.

(In reply to David E. Ross from comment #23) > that is really the end-user's responsibility: to choose a > character string for a master password that is sufficiently long and obscure > to be secure. It's the end user's responsibility to not pick a stupidly weak password, but our cryptographic implementation is weak against brute-force attacks on even reasonably secure passwords on modern hardware and not at all following best-practice for password storage. See bug 524403.

(In reply to Daniel Veditz [:dveditz] from comment #25) > It's the end user's responsibility to not pick a stupidly weak password, but > our cryptographic implementation is weak against brute-force attacks on even > reasonably secure passwords on modern hardware and not at all following > best-practice for password storage. See bug 524403. But considering the increasing processing speed of CPUs and GPUs this password has to grow over the time. A password considered strong today may be weak tomorrow. But the human brain does not improve like computers and secure passwords are getting unmemorable for common people. Therefore there has to be a mechanism like PBKDF2 with user configurable rounds as a counter measure!

My reply to bug 1311233: Firefox should just have its password encryption system overhauled and use AES256, scrypt (not PBKDF2), and SHA512 (or newer hash functions). Perhaps even better is to use functions specialized for creating hashes of passwords like Argon2. It combines two functions in one. The container should simply be in JSON (if it's not yet in that format) with descriptive parameter names so it can also be easily parsed outside Firefox. It can be compressed by XZ or a faster algorithm like LZ4. Mode of encryption should include authentication (example is GCM). Any necessary non-crypto checksums which can be used for the immediate sanity check of the container, the ciphertext, or other parameters, should be xxH32.

I believe that something should happen here. On the one hand it is claimed that Password Manager is only present in order to discourage casual snooping and if people want decent crypto then they should use the operating system's native encryption but on the other hand it does not seem to be an option to get Thunderbird to store credentials in the Gnome Keyring (whereas on my system, Chrome, for example, does seem to be storing 'stuff' in the Gnome Keyring). In the 4 years since this "bug" was raised, the weakness of the current Password Manager crypto has only got worse. Considering that this issue seems to have stalled, I would like to propose an alternative direction. *** Please create an API and support using a plug-in module to store credentials. Out-of-the-box this should come with a plug-in that is capable of using the existing storage mechanism and use that by default (for compatibility). Perhaps someone will then create a plug-in that instead uses the Gnome Keyring. Perhaps other people will do other things - but it is no longer your problem. Then we don't need to argue about what is the best KDF, how many rounds are appropriate this year, how much salt is too much salt, or what is the best encryption - or about whether a general mechanism like the current Password Manager is even the best. Ideally there would be some means of doing migration, which could involve supporting two plug-in modules simultaneously and traversing the information stored in the source, reading it, and writing it to the destination. (It isn't necessarily appropriate to encrypt the entire home directory tree in order to protect the credentials adequately, although seemingly that would work. That solution is overkill. Also, the credentials typically relate to another computer, so how I want to protect *my* information on my computer may differ from how I want protect to "someone else's" information on my computer.)

@ #28 for what do we need a hash function like SHA512? couldn't we AES256GCM (or AES128GCM (whatever may or may not be better for some or another reason) for crypto with authentication and for key deriv we could go even better than scrypt and go with Argon2id (in the best case even with about:config settings for even higher security than whatever may be the default. 16MB RAM is apparently already enough for many uses, but a client only system can use a lot more ram in the end (at least if the user is aware of that the MP entry will take that RAM, because unlike with servers, a client doesnt have to account for multiple MP validations at the same time). @ #30 regarding not to use passwords for everything I totally agree we dont need passwords for every kind of junk. for some things logging in with a simple email or third party thing (but with the lowest permissions that you can get, where ironically only microsoft really shines out of the common ones) can be a lot better, for one reason obviously not the user having to deal with WAY too many PWs. ever since bugzilla upped their password guidelines again that even simple commenters like me need a 12 char+ password I switched to github. 2FA is better than the best password anyway. regarding supporting password managers, I think different though. I just think there should be some nice standard approaches on how password input should be done on a website (we actually have with HTML), and website makers should NOT make stuff actively worse, then the support of password managers wouldnt be a problem. no one is getting subscriptions or purchases of all semi-common paid password managers just to support them. costs quite a bit money after all and is extra work.

To use ThunderBird you have to store your email passwords within Thunderbird's password repository. Email passwords are fairly high value assets, so I don't understand the reluctance to fix this problem properly? Cryptographic libraries and best practice guides are readily available (https://www.owasp.org/index.php/Cheat_Sheets#tab=Main), why not just go with best practice, such as scrypt or bcrypt for managing the password entry and AES256 for encryption of the actual passwords? I must admit, it's a big draw back to me to have to store sensitive info like email passwords within Thunderbird and have the developers argue that the Master Password "is only there to prevent casual snooping". That sort of makes me think that maybe I should use a different email client that takes my personal on-line security a bit more seriously. If someone gains access to your email credentials they can target one of your on-line accounts, by simply requesting a reset of your password, receive the usual email that is sent out and click on the reset password link, thus taking control of that account. I know that everyone is going to yell 2FA etc, which is a valid point, but why AID the attacker by going into denial about weak/useless protection of passwords in Mozzilla? Why the reluctance to take this issue seriously? I see it was 4 years since it was raised?

(In reply to My1 from comment #31) > for what do we need a hash function like SHA512? I mistakenly thought that scrypt also requires custom algorithms just like in PBKDF2. It does use (PBKDF2-HMAC-)SHA256, but that's constant. > couldn't we AES256GCM (or AES128GCM (whatever may or may not be better for > some or another reason) for crypto with authentication and for key deriv we > could go even better than scrypt and go with Argon2id I already mentioned GCM and Argon2. > (in the best case even with about:config settings Probably better if it's in about:preferences#security. > for even higher security than whatever may be the default. Yes, users should be allowed to configure the time and memory cost for the derivation of the key.

@ comment #32 one cant even go to argue 2FA for thunderbird since for IMAP/POP3 2FA basically doesnt exist and you have to create an application password for TB anyway if you have 2FA on the account, and when they get the PW, well it gets ugly. also this is just the second level of an issue 9 years ago which addressed that there was only 1 iteration of PBKDF2(SHA1) or whatever it may have been. @ comment #33 well you did mention a2 in general but they key point is argon2id, and not any other argon2 (PHP started off with a2i in 7.2 for example) because a2id is relatively strong against both tradeoff attacks and side channels. regarding whether the settings should be in the settings tab, I am not sure, or at least if they are in the settings tab they should be a bit limited especially in regards to memory usage because this can open a REAL can of worms.

Hi folks - glad you're interested in this bug. However, bugzilla is not a discussion forum. Please take this to mozilla.dev.security: https://groups.google.com/forum/#!forum/mozilla.dev.security

(In reply to My1 from comment #34) > @ comment #33 > > well you did mention a2 in general but they key point is argon2id, and not > any other argon2 (PHP started off with a2i in 7.2 for example) because a2id > is relatively strong against both tradeoff attacks and side channels. Argon2id is the obvious variant. > regarding whether the settings should be in the settings tab, I am not sure, > or at least if they are in the settings tab they should be a bit limited > especially in regards to memory usage because this can open a REAL can of > worms. Well it can be limited, but it's important that it's visible even to normal users so use of strong encryption can be promoted, or so the amount of time users have to wait for the encryption/decryption of the passwords can easily be configured. Recommending good parameter values through calibration, and showing informative tips (and warnings to avoid misperceptions) to the user can be helpful. It's also obvious that Firefox shouldn't allow configuration of memory usage that's greater than a huge percentage of the system's memory. It may even cancel the decryption/encryption if reservation of real memory is not granted. Using the can-of-worms phrase here is an exaggeration. OOM also happens everyday.

(In reply to My1 from comment #36) > but why is it a problem to discuss how to attack a bug, or what might be the > best solution? Not necessarily a problem, more of that bugzilla is for tracking code changes to the product, and if there's a long discussion on how to solve a bug, it can drown out the actual steps taken to solve the bug.

@Wayne Mery: Beware of cycle-duplicates - some of your colleagues might accidentially resolve this bug as "duplicated" from the actually unresolved "original" bug 1446947, and the issue might never get resolved, or exist for another 5 years.