1271851 - Decouple Master Password from PSM

Status: NEW

(Toolkit :: Password Manager, task, P3)

Description

[Justin Dolske [:Dolske]]

The Master Password prompt/UI has _lots_ of issues. Ideally we'd rip it out and start from scratch, but there are many entangled issues, and it is too large a project to do all at once. We've also been doing _nothing_ for long enough that we really need to make some incremental progress towards improving things so that future improvements don't also get stuck in this hopeless logjam.

So I'd like to decouple master password from PSM (i.e., not have it be equivalent to the PKCS#11 softtoken PIN). This eliminates the the complexity of working with PSM from improving password manager and actually gives us a few immediate benefits.

There are a few steps to doing this:

1) First we need to understand how much the MP (aka token PIN) is used outside of password manager. The specific issue that always comes up is the existence of client certificates, and that the MP/PIN is used to control access when signing data. I'm not sure anyone really understands exactly how this works (if at all!), or how common it is. Telemetry and testing is the main work here. This doesn't strictly block the rest of the work, per se, but it guides how much UX investment we want to make for that stuff as part of the split.

2) Implement a new nsILoginManagerCrypto component (similar to the existing crypto-SDR.js), using modern crypto for encrypting logins, and PKCS#5 PBKDF2 for deriving an encryption key from a user-supplied master password. (NSS/PSM is still used way under the hood for the actual crypto algs, but no master password prompting is involved). This will immediately fix bug 973759.

3) Migrate existing master password users over to this new crypto module. The simple-but-dumb way would be to prompt for a master-password (via a new prompt), use that to login to the softtoken, decrypt all the existing logins, and then reencrypt them all using the new crypto module. But it would be better to do this lazily (ie, wait until the user actually needed to enter the master password anyway). We did a vaguely similar migration a long time ago in bug 316084, but that's not terribly relevant now.

The end result of this is that password manager's logins are encrypted with a process password manager is actually involved in, thus enabling future improvements without having to re-engineer PSM, NSS, and softtoken.

EXPLICIT NON-GOALS of this work are: changing the overall UX, converting to OS storage, or fixing the multiple-prompting. All that can happen in the future, and should be much easier as a result of this untangling work. Also an explicit non-goal is supporting edge-case PSM/NSS usage (like replacing the softtoken with a smartcard, having password-manager's master password deal with certificates, or other bizarre NSS/PSM features I don't know about and only a tiny minority of users actually make use of).

Comment 1

[kjell]

What are the plans for a fix here? I have this multi-login-dialog problem here with fresh Thunderbird + Lightning with ~10 synced Google calendars. I get ~10 dialogs every time I start TB.

Comment 2

[Matthew N. [:MattN]]

(In reply to kjell from comment #1)
> What are the plans for a fix here? I have this multi-login-dialog problem
> here with fresh Thunderbird + Lightning with ~10 synced Google calendars. I
> get ~10 dialogs every time I start TB.

Please file that as a Thunderbird bug as it can be avoided with the current master password.