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.