1223185 - Discuss a replacement for master password

Status: RESOLVED DUPLICATE of bug 1608835

(Toolkit :: Password Manager, task, P2)

Description

[Ryan Feeley [:rfeeley]]

What can feasibly replace master password? Must it work consistently across all platforms? Must it encrypt the local password file? Can it take advantage of technologies like Touch ID?

Comment 1

[Richard Newman [:rnewman]]

A summary of what we do on iOS:

* We store logins in a database, because we need to do three-way merge in Sync. (Bug 1098501 etc.)
* We use sqlcipher as our storage layer to encrypt the entire logins sqlite database.
* We put the key in the iOS Keychain. (We use SecAttrAccessibleWhenUnlocked, IIRC.)

This gives us full schema control over the data we store, with a key that's stored safely, and stronger crypto for all users than MP provides.

That's one half of the master password story -- crypto. The other half is access control.

Robin is working on integrating TouchID (and the required PIN fallback) into our password manager, so we can get the same kind of access restrictions for which people use MP.


I've been in conversations with people about killing master password for at least four and a half years, so there is quite a lot of history here. A few highlights:

* The meta bug:                     Bug 570421
* Android Sync support:             Bug 711636, particularly Bug 711636 Comment 15 in which bsmith voices his desire to kill MP
* Weak crypto:                      Bug 973759
* Pattern lock support for Android: Bug 993077
* Java-side login storage:          Bug 946857.

Comment 2

[Justin Dolske [:Dolske]]

Oh hey, it's bug 496660 again. (We're allowed to change our minds? :)

Another issue to think about here is what happens to certificates. The current "master password" is really just a glorified PKCS#11 token PIN, and AIUI other things that can be stored in the softtoken (like certs) are protected by the same "master password".

[Some telemetry would be a really good idea here, because I don't think anyone really understands how much client certs are used. Most people's first reaction (including mine!) is "no one uses that!", but a few people have claimed it's widely used in certain countries. So whatever we end up doing, we should make sure we actually have a handle on end-user impact.]

Some possible end-states:

1) lolcerts, kill that feature.
2) Leave certs using the current NSS goop (perhaps with some light string changes), and decouple password manager from NSS/PSM. This means some users would have 2 "master passwords". This would be a fair compromise if enough users need client certs that we can't drop it, but they're few enough that we don't need to strongly support it.
3) Update all the NSS/PSM cert goop so that it no longer relies on the PKCS#11 token "master password", and instead protect client certs with the next-gen master password/crypto we're discussing here. I believe this would be a major undertaking and poor cost/benefit.
4) Some hack to keep the softtoken cert storage, but make the next-gen master password handle token logins so it's mostly invisible. Less work than #3, but this is all ancient fragile code that no one understands well.

(I would love to just kill client certs, I think they're based on 1990s PKI thinking, and are unlikely to ever evolve beyond a niche feature. I also fear it's going to be a rathole like <keygen>.)

Comment 3

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

The end result of this bug is documentation of what you have decided to do with the Master Password.

Comment 4

[(no longer active)]

(In reply to Justin Dolske [:Dolske] from comment #2)
> Another issue to think about here is what happens to certificates. The
> current "master password" is really just a glorified PKCS#11 token PIN, and
> AIUI other things that can be stored in the softtoken (like certs) are
> protected by the same "master password".

Based on a cursory look, I can't find another consumer of nsISecretDecoderRing which is not related to the master password.

> [Some telemetry would be a really good idea here, because I don't think
> anyone really understands how much client certs are used. Most people's
> first reaction (including mine!) is "no one uses that!", but a few people
> have claimed it's widely used in certain countries. So whatever we end up
> doing, we should make sure we actually have a handle on end-user impact.]

Given the above, perhaps this is a non-issue?

> Some possible end-states:
> 
> 1) lolcerts, kill that feature.
> 2) Leave certs using the current NSS goop (perhaps with some light string
> changes), and decouple password manager from NSS/PSM. This means some users
> would have 2 "master passwords". This would be a fair compromise if enough
> users need client certs that we can't drop it, but they're few enough that
> we don't need to strongly support it.

No matter what we do for certs, we can change what we do for the password manager, right?

Comment 5

[Justin Dolske [:Dolske]]

(In reply to :Ehsan Akhgari from comment #4)
> (In reply to Justin Dolske [:Dolske] from comment #2)
> > Another issue to think about here is what happens to certificates. The
> > current "master password" is really just a glorified PKCS#11 token PIN, and
> > AIUI other things that can be stored in the softtoken (like certs) are
> > protected by the same "master password".
> 
> Based on a cursory look, I can't find another consumer of
> nsISecretDecoderRing which is not related to the master password.

Other consumers wouldn't be going through nsISDR, they've be using the PKCS#11 APIs (well, their NSS/PSM equivalents) directly, or it would be triggered within NSS/PSM itself.

Comment 8

[Matthew N. [:MattN]]

We had a meeting about Master Password this morning to figure out requirements across all our products that save/fill logins.