Toolkit:Password Manager/2015/Master Password
This is a proposal for revamping the Master Password feature currently found in the Firefox Password Manager, as part of the Cloud Services Password Manager work.
Contents
Goals
The main goal is to have a password manager that is:
- safe from local attackers (e.g. nosy family members can't get to it)
- available online and offline (i.e. no need to be online to unlock it)
- recoverable by email in case the master password is forgotten
User Interaction
Description
There are three different modes that users can choose from:
- no master password: passwords are stored in plain text on the local machine
- separate master password: the contents of the password manager are encrypted using a key derived from a separate password that users choose, and they must enter this password to unlock the password manager
- Firefox Accounts password: a new encryption key derived from the FxA password is used to encrypt the password manager, and that key is backed up on the Firefox Accounts server to enable recovery should users forget their FxA password
The first two modes reflect what is currently implemented in Firefox, only the third one is new.
Interaction with Sync
In all three modes, users can choose whether or not to use Firefox Sync to synchronize the contents of the password manager across their multiple devices. This is completely orthogonal to whether or not the user chooses to encrypt the password manager locally.
No changes to Sync will be required. Changes to Firefox Accounts (which is a separate product from Sync) will probably be required.
Implementation
The first two modes will not change in any significant way. Therefore, this is a sketch of the third case ("Firefox Accounts password").
Two passwords internally
In order to make it possible to unlock the password manager while offline, the implementation will need to handle two different passwords:
- the password used to encrypt the data locally (i.e. used to derive the encryption key that will be stashed on the Firefox Accounts server)
- the password used to access Firefox Accounts
We will however hide that internal detail from users and will only expose a single password to users.
Here's an example scenario:
- I sign up with Firefox Accounts on my desktop with password FirefoxRocks2015 and choose to use it as my master password.
- A key (let's call it key1) is derived from FirefoxRocks2015 and used to encrypt my local password manager.
- Key key1 is backed up on the Firefox Accounts server under my username and my device identifier.
- I add my Firefox Account to my laptop so that I can use Firefox Hello. I don't use the password manager there.
- At some point, I forget my Firefox Account password and need to reset it by email. My new password is Mozilla4Ever.
- I open my desktop Firefox and try to unlock the password manager with Mozilla4Ever which fails because the key derived from that new password (let's call it key2) is not the same as key1'.
- Because Mozilla4Ever is now my Firefox Accounts password, Firefox will be able to silently recover key1 and use it to decrypt the local password manager.
- Once it's decrypted, the password manager is re-encrypted with key2 and key2 is sent to the Firefox Accounts server to replace key1, which is no longer used for anything.
In short, the local password on the desktop was silently changed from FirefoxRocks2015 to Mozilla4Ever without the user having to do anything.
Key backup per device
Because we need to use two different passwords internally, as described in the previous section, we could get into a temporary situation where our three devices have a different local password each and then our FxA password is also different from these 3. So 3 devices and 4 different passwords.
All three "local" passwords will eventually be replaced with the FxA password, as per the procedure sketched in the previous section, but the fact that they can theoretically exist for a short period of time means that we need to store a different recovery key for each device inside a user's Firefox Account.
They should be keyed using a yet-to-be-defined device identifier.