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.

There's already discussion in bug 524403. It's currently undecided if this bug here will be implemented, or how, or if it will be wontfix.

If a decision is made to implement it, it could use new APIs suggested in bug 1562672 to define the product specific security level for Firefox.

Note that bug 524403 is about a default for NSS in general.

This bug is specific to what Firefox developers want to do.

Firefox will probably switch over to nsIOSKeystore.

The implementation for nsIOSKeystore falls back to NSS based storage in some environments.

Ah, good point.

See bug 1562671, environment variables can now be used to control the iteration count used for the master password.
It's up to Firefox developers to decide if they want to use a higher count, or accept the NSS default.

Thank you very much for the KDF iteration increase and switching to AES256! Now that bug 1606992 has shipped, it would be great if we could silently migrate existing MP users to the new iteration count upon unlocking. Is this just a matter of setting environment variables or would this need code in NSS in order to do this?

Btw. https://searchfox.org/mozilla-central/rev/9e45d74b956be046e5021a746b0c8912f1c27318/security/nss/lib/softoken/lgglue.c#198,204-205 looks fishy to me but maybe I'm misunderstanding the meaning of "LegacyIterationCount".

Thanks

I don't think we switched to AES256, saved logins still use DES-EDE3-CBC. Potentially using stronger crypto is the topic of bug 973759. I think it would require changes at the NSS file format level.

Currently there is no mechanism to request automatic migration to the higher iteration count.
Let's track your suggestion in new bug 1609189.

(This bug here is to investigate if an even higher iteration count should be used by Firefox, which is higher than the current NSS default.)

BTW, do you have telemetry data on what percentage of Firefox users has enabled the master password?

(In reply to Matthew N. [:MattN] (PM me if request are blocking you) from comment #6)

Btw. https://searchfox.org/mozilla-central/rev/9e45d74b956be046e5021a746b0c8912f1c27318/security/nss/lib/softoken/lgglue.c#198,204-205 looks fishy to me but maybe I'm misunderstanding the meaning of "LegacyIterationCount".

You shouldn't have to worry about legacy.

It refers to the previous file format of file "key3.db", which used a DBM database. Because of backwards compatibility requirements, we didn't enable iteration count for that old file format by default.

Starting with Firefox 58 the new file format key4.db has been used.

(In reply to Kai Engert (:KaiE:) from comment #7)

I don't think we switched to AES256, saved logins still use DES-EDE3-CBC. Potentially using stronger crypto is the topic of bug 973759. I think it would require changes at the NSS file format level.

I understand that the algorithm to encrypt saved logins didn't change but from bug 1585189 it sounds like AES256 is now used for the DB entries. Did I misunderstand?

(This bug here is to investigate if an even higher iteration count should be used by Firefox, which is higher than the current NSS default.)

OK, I didn't think we would do that now so I figured we could use this bug. That's fine though.

BTW, do you have telemetry data on what percentage of Firefox users has enabled the master password?

Yes, but only for pre-release channels where it's less than 1% e.g. https://mzl.la/2QRKkk8

(In reply to Matthew N. [:MattN] (PM me if request are blocking you) from comment #9)

(In reply to Kai Engert (:KaiE:) from comment #7)

I don't think we switched to AES256, saved logins still use DES-EDE3-CBC. Potentially using stronger crypto is the topic of bug 973759. I think it would require changes at the NSS file format level.

I understand that the algorithm to encrypt saved logins didn't change but from bug 1585189 it sounds like AES256 is now used for the DB entries. Did I misunderstand?

Thanks for correcting me, I had not noticed that recent change!

Given the slow decryption time on older hardware as mentioned in bug 1606992 comment 90 and earlier comments, I don't think we will be increasing the iteration count above the new default of 10,000. If anything, I would slightly reduce it to help those users.

Let's close this for now as some are confused thinking that this bug being open implies Firefox isn't using the new iteration count. We can open a new bug in some years from now if we want to increase the iteration count again.