Threat Modeling Firefox

(Don’t want to read? Jump to the end - there’s a tldr)

Recently a post was written about Firefox’s local password database encryption.

The post is appropriately titled Master password in Firefox or Thunderbird? Do not bother!, which I’ll certainly be getting back to soon.

The tl;dr is that Firefox will SHA1 your master password and use that to encrypt your local database. This is purported to be bad because a single round of SHA1 is extremely fast to calculate so weak passwords will be trivial to bruteforce.

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.
[..]
The problem here is: GPUs are extremely good at calculating SHA-1 hashes. 

There is an interesting point made here - we certainly know that using a single round of SHA1 for web auth is bad. But can we then assume that the same thing applies to this situation?

Fundamentally what the author is doing here is applying a threat model for websites to a local database. There actually is no other evidence that what Firefox is doing is bad, just some numbers about bruteforcing - really, the argument hinges on the threat model.

In my opinion this is simply a case of poor threat modeling.

Let’s Do Some Threat Modeling!

Let’s take a step back and do a few exercises. Let’s imagine we are in charge of keeping Firefox users safe, we are Team MozSec; so who are we worried about?

• Attackers who control malicious webpages
• Attackers who control malicious 3rd party webpages
• Attackers who abuse our various services (sync?)

If I were in such a position those would be my really big ones. Only the first two really apply to this situation.

Now let’s ask what exploitation of this ‘vulnerability’, weak hashing, would take.

The attacker:

• Must be able to exfiltrate the encrypted database file
• Can’t just access Firefox’s memory to dump the passwords
• Can’t just keylog the user/ Firefox
• Is not interested in higher value data, such as session tokens

Let’s take our threat model - attacker controls malicious website - and try to see if we can come up with an attacker…

Can you? Because I can’t. An attacker with such insane limitations and requirements simply doesn’t exist in my mind. Perhaps an attacker who compromises a terribly configured sandboxed application that somehow has read access to the encrypted database file…. I’m not too worried about that.

Within Mozilla’s threat model, as I would design it, there is no reasonable attacker we can imagine.

What would an attacker who can exploit this vulnerability look like? I’d say there are two:

• An attacker has execution on the local system
• An attacker has unlimited offline access to the system

So now we’ve got two attackers who are outside of our threat model, but let’s think it through.

Local Execution

OK, so we have an attacker who can locally execute. They see the encrypted file is using super-hash, which uses a trillion rounds of argon2, or whatever. “Well, screw that” our attacker says - they know better than to attempt bruteforcing.

What does the attacker do? Well, they have many, many options.

The most likely attacker (who has the mission of compromising your websites) will just grab existing Firefox session tokens. These should exist offline as well as online (becuase you can close the browser, open it, and still be logged in, right?) so they grab those. They use them on your local system to perform requests to websites, get the info they need, etc.

OK, well that was easy. Let’s imagine you clear all of your sessions because you’re nuts.

“Huh, ok” our attacker says. They sit around, wait for you to open Firefox, and dump the passwords straight from memory. Or just hijack the live sessions.

I am unconvinced, given this straw man scenario I’ve whipped up, that super-hash is making me safer.

Unlimited Physical Access

You’re fast asleep - computer turned off. An attacker takes your laptop.

They scrape the database off of the hard drive. “Damn” the attacker says - “super-hash!”.

So they grab all of your other files and data, sessions, cookies, extension info, etc and leave.

Well, that sucks, but it is in fact true that super-hash saved the password database here.

We’re well outside of the reasonable threat model I’ve set out, but super-hash had some impact.

Let’s further imagine that now local attackers, such as the one described here, are in our threat model. Is ‘encrypt this one set of data’ a good mitigation? Are users really safer?

Really, local attackers with this sort of access are more reasonably in the threat model of your operating system and hardware manufacturer. And they have a great solution for you! It’s called Full Disk Encryption and you probably have it enabled if you’ve bought your computer in the last two years - both Windows and OSX enable this by default.

So Why Encrypt At All?

Master password in Firefox or Thunderbird? Do not bother!

This is the title of the post I’m responding to, and I really think it’s the best part.

Why bother at all indeed - we’ve shown that encryption of the password db really isn’t meaningful at all, and that the issue is better solved elsewhere.

Turn on the encryption if you like, or don’t, I’d say it makes absolutely no different, regardless of your hashing algorithm.

Anyways

Would super-hash, or bcrypt, or argon2, or anything else make users safer? Is it raising the bar for the attackers? Is it a problem best solved by Firefox? Is it worth the issue of users believing they are safer than they are?

In my opinion the answer to all of these question is a clear “no”.

Threat modeling is an extremely important part of security - all good mitigation techniques start with a threat model. Otherwise what we end up with are a bunch of trivial-to-bypass half measures, a poor understanding of where we’re weak, and users who are confused about how safe they really are.

I wrote this up in a few minutes via github - apologies for what I’m sure is terrible formatting on a rushed post. I want to be clear that what I’ve done here lacks rigor - this is more an off the cuff way to do a risk assessment. This is not really a great representation of threat modeling (and actually conflates some aspects of risk assessment with having a threat model), but I hope it makes it clear that asking these sorts of questions is important.

TL;DR

• Comparing local password storage to web-auth is erroneous, entirely different world.
• Comparing local password storage to password managers that sync is erroneous.
• Bcrypt would make no difference for any attacker reasonably in Firefox’s threat model.
• People are convinced that Bcrypt would make them safer, which is why implementing it woudld be irresponsible.
• If you are concerned about offline attackers, or attackers running as separate users, consult your OS/Hardware whose threat models certainly include that attacker.