I'm relying on Firefox to remember my passwords, using a Master Password of more than 25 characters. How secure is this set-up?
In short - Firefox uses triple DES in CBC mode with Master Password.
More details: nice article about this topic is here: http://luxsci.com/blog/master-password-encryption-in-firefox-and-thunderbird.html and if you want some more details, here is mozillaZine article: http://kb.mozillazine.org/Master_password. This article gives you a detailed comparison between the major browsers.
It is believed that it is safe to store passwords in such a way, however, I do not trust any software. Maybe it sounds too paranoid, but we can never know where the vulnerability hides.
Additional information as of 2023: See further pertinent information here, from a later discussion around this topic at Mozilla, suggesting that the number of iterations be increased. Also important, the Lastpass breach, which significantly ups the recommended lower limit on iterations.
In order to answer "How secure are my passwords in the hands of Firefox using a Master Password?" If Firefox has any exploitable bug, then it is not secure no matter how much encryption is wrapped around your passwords. Had the question started with "Assuming Firefox is the most secure browser available in terms of exploits and ignoring any plugins..." then i would agree the answer may be irrelevant. If a click interface that is not susceptible to keystroke logging is used, then the passwords may still be safe even with a keystroke-logger in the browser. If there is a "man-in-the-browser", physically typing in a password can be intercepted and if Mozilla emulates key-presses then these would also be intercepted. If Firefox uses more direct memory access, i still would not be surprised if it could be intercepted.
"Man-in-the-browser" is not a machine level rootkit, but at the application level. Most common is malicious AJAX which can easily listen to every keystroke -- that is AJAX 101. Or could be malicious binary code injected remotely into the browser or into a plugin.
To mitigate "man-in-the-browser", use several different firefox profiles siloed for banking, email accounts, ClipperZ, and others or just use Qubes-OS.
If there is a "man-in-the-machine" or system level rootkit, then all your passwords are owned no matter if they are stored in KeePassX or ClipperZ or Firefox.
For clarity: current versions call it a "primary password". This was simply a name change from "master password", not a change in technology. Do not @ me about this.
There are two possibilities:
- If you have not changed your Firefox primary password since around ?Firefox 55?, you should still have a key3.db file which uses your primary password. This was very weak against brute-force attacks, as described by Palant .
- If you change your primary password on ?Firefox 55? or above, it should not be used in key3.db. The old key3.db file may still exist, but you can ignore it. Of course you didn't re-use your old primary password anywhere :-).
Following Palant's article and his comment on the bug tracker, the protection was slightly improved. For new passwords, the protection was upgraded to 10,000 rounds of ?something?. Note this is at least one or two generations out of date. It does not provide strong protection for short primary passwords.
It was worth improving this IMO. Specific cracking tools were available for download. It will increase the time required in some attack scenarios, such as domestic abuse or pranking.
This answer is out-of-date; please see https://security.stackexchange.com/a/268880/180358
Firefox uses a fairly weak hashing method: just one iteration of SHA-1. You could use a more secure password to compensate for this, but it's less secure than what something like something like LastPass would offer.
Wladimir Palant (creator of Adblock Plus) wrote a post about this in March 2018:
It is common knowledge that storing passwords there without defining a master password is equivalent to storing them in plain text. While they will still be encrypted in logins.json file, the encryption key is stored in key3.db file without any protection whatsoever.
when I looked into the source code, I eventually found the sftkdb_passwordToKey() function that converts a password into an encryption key by means of applying SHA-1 hashing to a string consisting of a random salt and your actual master password. Anybody who ever designed a login function on a website will likely see the red flag here. This article sums it up nicely:
Out of the roughly 320 million hashes, we were able to recover all but 116 of the SHA-1 hashes, a roughly 99.9999% success rate.
The problem here is: GPUs are extremely good at calculating SHA-1 hashes. Judging by the numbers from this article, a single Nvidia GTX 1080 graphics card can calculate 8.5 billion SHA-1 hashes per second. That means testing 8.5 billion password guesses per second. And humans are remarkably bad at choosing strong passwords. This article estimates that the average password is merely 40 bits strong, and that estimate is already higher than some of the others. In order to guess a 40 bit password you will need to test 239 guesses on average. If you do the math, cracking a password will take merely a minute on average then. Sure, you could choose a stronger password. But finding a considerably stronger password that you can still remember will be awfully hard.
There is a ten-year-old bug for this, which is still open as of August 2019.