Skip to content
Naked Security Naked Security

Nine years on, Firefox’s master password is still insecure

A researcher has uncovered a big security weakness in the way Firefox secures browser passwords behind a master password.

Developer Wladimir Palant (of Adblock Plus fame) has uncovered a big security weakness in the way Firefox secures browser passwords behind a master password.
Firefox users who save browser passwords without a master key are, in theory, protected from attackers with access to their computer by encryption. The problem is the key to unlock the logins.json file used to store these passwords can be found in a file called key3.db.
This design is secure from only the most casual attacks, as Palant notes:

It is common knowledge that storing passwords there without defining a master password is equivalent to storing them in plain text.

Which is why Mozilla offers users the option to protect passwords behind a master password set through Tools > Privacy & Security > Use a master password.
In Firefox’s case, this turns the master password into a hash value by adding a random string to the password (a ‘salt’) and applying the SHA-1 algorithm. Thereafter, when the user enters the master password, the software simply compares a hash of the password you enter with your master password’s hash – if the two match, the user has entered the correct password.
The first problem is that using the aging SHA-1 is considered weak because, as Palant says, “GPUs [Graphics Processing Units] are extremely good at calculating SHA-1 hashes.”
This is called brute forcing, where the attacker uses a commodity graphics card to calculate huge numbers of possible hashes until a match with the target hash generated by SHA-1 is found.


It sounds like an impossible task, but GPUs can churn through billions of these per second.
The standard technique to increase the time it would take an attacker to brute-force a password hash is by re-applying (or iterating) it.
So, having generated a hash, you add a salt to it and make another hash. Then you add some some salt to the resulting hash and make a hash of that, and so on and so on until you hit a target number of salt+hash iterations (for an in-depth look at this read our article on how to store your users’ passwords safely).
Any attacker wanting to crack your password hash will have to perform exactly the same number of iterations, with the same salt, to find a match.
Choosing an iteration count is a matter of balancing the inconvenience you’re prepared to inflict on users when they log in against the amount of obstruction you want to put in a password cracker’s way.
The good news is you don’t have to pick one iteration count and stick to it – you can increase the iteration count over time to keep pace with improvements in hardware.
Unfortunately, Palant noticed, Firefox performs just one iteration.
By comparison, password managers such as LastPass (which also uses SHA-256 rather than SHA-1) defaults to 5,000 iterations, with some software taking that to 100,000 if speed is less of a concern.

However, the most extraordinary part of this story is that it the inadequate iteration count was first reported to Mozilla nine years ago in a Bugzilla report.
Developer Justin Dolske:

A higher iteration count would make this more resistant to brute forcing (by increasing the cost of testing password), the PKCS#5 spec suggests a “modest value” of 1000 iterations. And that was 10 years ago. :).

Mozilla acknowledged the issue, which was followed up by senior manager Brendan Eich around 2014 who stated simply: “need an owner for this.” Somehow, the issue fell through the cracks.

Solutions?

An update could up the iteration count of the hashing, although this will require users to immediately reset their master password. Mozilla also recently announced a project to build a native password manager extension called Lockbox, but that does require Firefox users to create an account.
For most users, the easiest alternative is to use an independent password manager and abandon Firefox’s integrated manager entirely.
Mozilla and its loyal users can at least console themselves with one thought: if Firefox wasn’t open source, and therefore open to scrutiny, the issue might have sat out of sight indefinitely. It is always better to know than not.

13 Comments

Does this mean Thunderbrid is also vulberable?

Well there is a key3.db file in my Thunderbird directory – so I expect so!
I wish the major password managers would integrate into Thunderbird.

Thunderbird uses the same design so it is also vulnerable, yes.

So, this would mean that email server logins are potentially exposed at on the client host, meaning a compromised client host could lead to compromised email server credentials… Am I understanding this?

(shrug) The password database is not partitioned from the logged in user anyway, so a casual attacker almost certainly has the session key and master password anyway. You don’t need root for that. It’s only an issue if the same master password / session key approach is used for cloud sync. :(

“An update could up the iteration count of the hashing, although this will require users to immediately reset their master password.”
I dont see the need to reset password if just to up the interation? Technically no need right? The only reason it may be needed is because if the old hash database are compromised and if hacker bruteforce that database, it will also get the “rehashed” password.

The old password will still be weak, so it needs to be rotated to be secure in future.

I have only read the “palant.de” article partially, yet, but I think there is a thinking mistake:
To judge the security of a hashing algorithm we have to look at the use case.
For email signing using the “plain text” as “hash” would be the most secure “hashing” algorithm which is conceivable because collisions are impossible;
for a challenge-handshake password authentication it would be the least secure one because the plain text password is transmitted.
If I understood the argumentation on “palant.de” correctly, they have mixed up two different use cases when judging the security of the master password algorithm.

I use 2FA if it’s important. I back my 2FA up into a encypted text file. Probally be better if I did it on a linux computer never put online (RaspPi, for example). I think some sites have a lock put on accounts with reset 2FA so if the backup was used by attacker the target would notice if they attempted login during the lock period. If the attacker can get in far enough to mess with Firefox could they just drop a keylogger in and wait? Maybe more likely detection, as it has to stay there awhile.

wait doesn’t it mean one could put the key file on a stick and symlink? that should increase the security quite a bit

Hi,
does anyone know if there have been changes recently? Just found this article and looked for the key3.db. But what I find is key4.db.
Did Mozilla maybe fix this lately?
Thanks!

Comments are closed.

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?