1562687 - Stronger KDF for Thunderbird master password

Status: NEW

(Thunderbird :: Security, enhancement)

Description

[Kai Engert (:KaiE:)]

I suggest to use this bug to discuss a potential increase of the iteration count used for the master password protection for the NSS key database.

Because of Firefox the NSS default might remain at a lower and weaker value.

Because Thunderbird stores secrets used for email encryption, having a stronger protection in Thunderbird seems justified.

This will require the API from bug 1562672. See also background discussion in bug 524403.

Comment 1

[Kai Engert (:KaiE:)]

See bug 1562671, environment variables can now be used to control the iteration count used for the master password.

We need to decide if Thunderbird accepts the NSS default, or wants to further increase it.

Comment 2

[Jorg K (CEST = GMT+2)]

Kai, can you please clarify this a bit. It all started off at bug 524403 and bug 973759. The former was fixed a duplicate of bug 1562671 and that got fixed in the end, so there is a higher iteration count used now and the MP is indeed safer than it was or even considered safe? Or are there more tweaks required?

Comment 3

[Kai Engert (:KaiE:)]

Jörg, yes we improved the situation. Instead of an iteration count of 1, latest NSS uses an iteration count of 10000 by default.

(It still uses the same underlying mechanism for protecting the master password, that's why there's still room for improvement, and why bug 973759 is still open.)

What does this mean? For example, if a certain master password previously required 1 days for brute force cracking it, now cracking it would need 27 years. However, if the user selects a very trivial password, for example one that could previously be found in 1 minute, now you could still do it within a week.

IMHO, the new situation is an improvement. Note that just running the new code isn't sufficient. In order to get the increased protection, users must change their master password once they'll be running the new code.

The increase to 10000 was chosen as a middle ground, to see if the Firefox developers complain about any slowness as a result. I haven't heard any complaints.

Thunderbird could decide to override the default value 10000, and use an even higher iteration count. That's the topic of this bug.

When using TB 72+, try to change the master password, and you might notice a delay. If it feels like a longer delay is acceptable, we can further increase the iteration count.

Comment 4

[Jorg K (CEST = GMT+2)]

Thanks for the detailed answer (as always). Is there any intention of backport the higher iteration count to mozilla68 so Firefox and Thunderbird could profit? Any indication how a "27 years to crack" password would look like?

Using TB 72 beta 3, I set a password of 11 characters (incl. upper/lower, digits and special chars.) for which the password meter showed a 100% green bar. When clicking OK, I noticed a, well, maybe 500ms delay, or that's what it took to pull down the panel. So what would be an increased iteration count? Five times, ten times? Should I try that? What's your recommendation? After all, you're the security expert. Why don't we just do some experiments with higher counts and go for the one which either you consider "safe enough" or one that brings the delay to up to one second on a more or less current processor.

Comment 5

[Kai Engert (:KaiE:)]

This article
https://palant.de/2018/03/10/master-password-in-firefox-or-thunderbird-do-not-bother/
claimed:
"a single Nvidia GTX 1080 graphics card can calculate 8.5 billion SHA-1 hashes per second".

Here's my understanding:

A very simple password might use only 7 lowercase characters
26^7 => 8031810176
1 iteration: can be cracked in one second
With 10000 iterations: one week

A password that uses 8 alphanumeric characters, case sensitive (both upper and lower):
62^8 => 218340105584896
1 iteration: 7 hours to crack at most.
10000 iterations: 8 years

If you select 11 alphanumeric charcters, all lowercase:
36^11 => 131621703842267136
1 iteration: 179 days.
10000 years: 4904 years

The above numbers are based on a brute force cracking strategy that tries all possible password.

However, the above article also claims that users are bad at selecting passwords, so if you have smart heuristics, you don't need to try all the passwords.

It claims that the real security of passwords is lower, if you're able to make use of those heuristics (but that requires a tool that's smarter than doing brute forcing, it must have the heuristics built in).

I've played with: https://ae7.st/g/test.html

MyHouseIsBlack. -> 40 bits entropy
2^40 => 1099511627776
1 iteration: at most two minutes (or one minute on average)
10000 iterations: at most 11 months

r4hnt0hmb4ssw0lt -> 52 bits entropy
2^52 = 4503599627370496
1 iteration: 6 days
10000 iterations: 168 years

Comment 6

[Kai Engert (:KaiE:)]

(In reply to Jorg K (GMT+1) (PTO to 19th Jan 2020, sporadically reading bugmail) from comment #4)

Is there any intention of backport the higher iteration count to mozilla68 so Firefox and Thunderbird could profit?

No. The change is inside the NSS library, and some Linux distributions use NSS from a separate system package. To ensure it gets picks up, we'd have to release an NSS point release with this new feature, and have ESR depend on it. We usually don't do that.

So what would be an increased iteration count? Five times, ten times? Should I try that? What's your recommendation?

When creating pkcs#12 files, which are e.g. used for backups of personal S/MIME certificates, NSS uses iteration count: 600000

For testing with this value, you could set the following environment variable. NSS 3.48+ in TB 72+ will use when it sees it:
NSS_MIN_MP_PBE_ITERATION_COUNT=600000

Comment 7

[Jorg K (CEST = GMT+2)]

I've changed the line here
https://searchfox.org/mozilla-central/rev/9b99e1d9c6cf83539674cb016c7373f549ba59ca/security/nss/lib/softoken/sftkpwd.c#37
to 600000 in a local build. Setting the password, I used r4hnt0hmb4ssw0lt, well, I didn't expect a long delay, so I just started counting, it took around a minute. Starting TB and then entering the password made the system unresponsive for a while, also in the vicinity of a minute. I was better prepared with a stop watch when removing the password, it took about 30 seconds.

Using 60000 iterations, I came to 5 seconds when setting it, no real noticeable delay when starting TB, and around 3.5 seconds when removing the password. So somewhere between 10000 and 60000 should be a good value. With 30000 I saw under 3 seconds for setting and 2 seconds for removal.

Comment 8

[Kai Engert (:KaiE:)]

Jörg, thanks for testing. Please delay this for a little bit. We discovered an inefficiency/slowness in bug 1606992, which we've worked to improve.

We should repeat the tests after bug 1606992 has been fixed in NSS, and a respective NSS version has been uplifted to FF/TB.

Comment 9

[eric.engstrom]

It's always struck me as a bit odd that the NSS (and therefore TB and Firefox) don't use OS native methods of storing encrypted information. For Thunderbird especially, this would be a VAST improvement over the current NSS roll-your-own. If you can't trust the OS to do it right (KeyChain on macOS, [gnome-]keyring on most *NIX, Credential Manager on Windows), there's no real benefit to a Master Password managed by an individual tool. In fact, it's arguably EASIER to recover passwords out of TB's store with access to the disk than it is to get them out of one of the OS managed approaches.

Has this sort of shift been discussed? Ressult?