Keep User Logged In: Export key for encrypted key login #152

darkwing · 2022-09-30T20:46:52Z

This is an alternative to #147 , whereby we create an encryption key based off of the derived key of browser-passworder

Depends on: MetaMask/browser-passworder#20

index.js

package.json

Gudahtt · 2022-10-26T04:44:34Z

How will this work with mobile? Mobile's encryptor doesn't have any equivalent function to encryptWithDetail/decryptWithDetail, nor does it have any need for it.

index.js

legobeat · 2022-11-01T09:20:39Z

index.js

+
+    if (this.password) {
+      const { vault: newVault, exportedKeyString } =
+        await this.encryptor.encryptWithDetail(


An alternative approach (which should not require API changes to browser-passworder) would be to generate the key itself here (if it does not exist) and use the existing encryptWithKeyMethod. That would reduce the code complexity and reduce the number of potential states.

Was this considered, and if so, why is it not preferred?

This package has to work across both mobile and extension, and they use entirely different encryption methods. Mobile uses a native AES API, whereas extension uses the web crypto API. This is managed by keeping all cryptography in the "encryptor" instance, which is injected into this class.

Could you elaborate on how that would reduce the number of potential states? I don't follow that part.

@Gudahtt I was loosely referring to branching complexity. Inlining the logic in encryptWithDetail could reduce the call sites into encryptor, parallel logic, and code surface area. Consider:

___ _______/ \______________ \___/

vs

_____ ________ ____/ \__/ \____ \_____/ \________/

Conversely for decrypt.

Does that make sense?

It's not a large number of codes we're talking about here, but when juggling passphrases and exposed private keys around it's prudent to be more picky IMO.

Ah I see. I don't think it would reduce branching complexity overall, but it would shift some steps from that package into this one.

Either way, we will have to persist the keyring state with a password and no key, or with a key and no password. And the same goes for unlock: sometimes we'll have a password but no key, and sometimes we'll have a key but no password. That's two paths each, for unlock and persist.

Handling mobile as well is more complex, as their encryptor doesn't yet support returning a key (it has no immediate need to support this). So that's an additional path for unlock and persist (where a password is supplied, but we don't want to ask for a key and cache it).

Even if we inline some of the encryptor changes here, we would still have those 6 branches, the same as we have now.

We could eliminate two of those branches by updating the mobile encryptor to also support encryptWithDetail.

But it's unclear to me how that would benefit mobile. I guess it would let them keep the key in-memory and let the garbage collector cleanup the password, which.... seems preferable but it's hard to argue it has any tangible benefit to security beyond allowing us to simplify some of this code. Postponing that change for later makes sense to me, especially given that a lot of things are waiting on this change (a lot of MV3 bugs surrounding the restart of the service worker are linked to this work).

If we just wanted to reduce the API surface of the encryptor, that would be a bit easier to accomplish. We could update encrypt and decrypt to return an object, and add the details to that rather than adding the new encryptWithDetails/decryptWithDetails functions.

That'd make the extension encryptor act differently from the mobile encryptor for those methods, so we'd need to handle that difference or change the mobile one as well. But that wouldn't be too difficult either way. I expect we'll want to do this eventually.

index.js

Gudahtt · 2022-11-02T13:52:58Z

index.js

+
+    this.store.updateState({ vault });
+
+    // The keyring updates need to be announced before updating the exportedKeyStrings


What is the relationship between these two updates? It's not clear to me why this order is important.

Grrrr. It's a weird extension issue. If I call this.memStore.updateState({ encryptionKey: newExportedKeyString }); before _updateMemStoreKeyrings, the account is created in the keyring but somehow isn't being propagated to the extension before the Preferences controller tries to syncAddresses.

The visual side effect is that the new account wouldn't be selected in the extension -- Account 1 would be selected. When you open up the accounts menu, however, it's there.

This comment could be covering the why insteadof/alongwith the what

Also, could a test cover this to guarantee it's not undone?

If I call this.memStore.updateState({ encryptionKey: newExportedKeyString }); before _updateMemStoreKeyrings, the account is created in the keyring but somehow isn't being propagated to the extension before the Preferences controller tries to syncAddresses.

Is this also why the calls to _updateMemStoreKeyrings were removed in a number of places? I was curious about that as well.

Edit: Oh nevermind, I see now. This line is within persistAllKeyrings, so it was removed from those other places to not be redundant with this addition. Sorry got mixed up for a moment.

Huh this is pretty tricky. I think I follow though.

Whenever memStore is updated, it'll trigger some other things to run (including syncAddresses). By setting the encryption key here before calling _updateMemStoreKeyrings, these state update get triggered with an outdated set of keyrings and associated accounts.

An update with stale keyrings/accounts is a problem because it has side-effects like choosing a new selected address in some cases. Whereas a stale (i.e. unset) encryption key is not a problem at all. It just gets set in the next update.

Gudahtt · 2022-11-02T13:54:36Z

The cacheEncryptionKey option looks good! Simpler than I thought it would be

naugtur · 2022-11-06T10:00:52Z

index.js

@@ -131,7 +141,7 @@ class KeyringController extends EventEmitter {
      throw new Error('KeyringController - First Account not found.');
    }

-    await this.persistAllKeyrings(password);
+    await this.persistAllKeyrings();


Why does this need to be called twice? Looks like the initial call is redundant or there's not enough separation of concerns for addNewKeyring to work regardless.

Good question. I suspect that it was originally called here for the side-effect of setting this.password. Now that we're setting this.password sooner, this might not be required.

Heh, it's from the first ever commit:

naugtur · 2022-11-06T10:05:04Z

index.js

+  async persistAllKeyrings() {
+    const { encryptionKey } = this.memStore.getState();
+
+    if (!this.password && !encryptionKey) {


What's the difference between holding something in memory store vs class field? Why do we use/need both?

Putting the encryptionKey in the memory store bubbles it up to the extension, which allows us to store it in session storage each time it changes: https://github.com/MetaMask/metamask-extension/pull/15558/files#diff-6fbff2cfe97ac01b77296ef2122c7e0a5b3ff6a84b584b4d1a87482f35eea3d6R3941

We don't generally have a use for public class fields; the password field should be private. That's a change I was going to make in a separate PR at some point; it would be a breaking change because @metamask/controllers uses this field today, but it does not need to.

naugtur · 2022-11-06T10:08:48Z

index.js

+    } else {
+      vault = await this.encryptor.decrypt(password, encryptedVault);
+      this.password = password;
+    }


(nit) This if structure looks similar across both functions. I'd be tempted to create a function that accepts state and descriptively named functions as reactions to certain states.

naugtur

Left some comments, but none of them are blockers.
Please consider addressing them before merging, but you have my approval already. This is Fiiiine!

package.json

…tion via key

* origin/main: Set password sooner to avoid redundant persistance (#154) Ensure newly created vaults are unlocked (#155)

index.js

Co-authored-by: Mark Stacey <[email protected]>

index.js

Co-authored-by: Mark Stacey <[email protected]>

Gudahtt · 2022-11-08T00:05:21Z

test/lib/mock-encryptor.js

  }),

-  decrypt(_password, _text) {
+  encryptWithDetail: sinon.stub().callsFake(function (_password, dataObj) {


It'd be nice to have test coverage for a mobile encryptor as well. Maybe we can leave this as-is, and move these modifications to a new mock encryptor module? Or set two up here, and return them as named exports rather than as the default export.

Then we can ensure things blow up properly if cacheEncryptionKey is enabled with an encryptor that doesn't support it.

Converting this to a class might make that easier, as was done here: https://github.com/MetaMask/controllers/blob/main/tests/mocks/mockEncryptor.ts

Then we can extend the base encryptor to create the one with the browser-passworder additional methods.

test/index.js

index.js

…on key is set

Gudahtt · 2022-11-08T16:29:36Z

test/index.js

+
+      expect(keyringController.password).toBe(password);
+      expect(keyringController.memStore.getState().encryptionSalt).toBe('SALT');
+      // eslint-disable-next-line jest/no-restricted-matchers


Nit: In these cases where w want to ensure we have a non-empty string, we can use expect(...).toStrictEqual(expect.stringMatching('.+')). This is a bit more specific than the truthy check in that it ensures it's a string, and it avoids the need for this ignore comment.

Excellent, I had no idea!

There is one more place you could use this (on this line 😅 )

Gudahtt

LGTM! Still a lint failure to resolve, but this all looks great and I can re-approve after that's fixed.

Gudahtt · 2022-11-08T20:22:54Z

test/index.js

+    it('unlocks the keyrings with valid information', async function () {
+      keyringController.cacheEncryptionKey = true;
+      const returnValue = await keyringController.encryptor.decryptWithKey();
+      const stub = sinon.stub(keyringController.encryptor, 'decryptWithKey');


Nit: IMO this would be a better test with this removed. The keyrings-based assertion is enough to show this works; this part just makes the test more fragile by tying it to internals.

test/index.js

darkwing requested a review from a team as a code owner September 30, 2022 20:46

darkwing marked this pull request as draft September 30, 2022 20:46

darkwing mentioned this pull request Sep 30, 2022

Provide extracted key with encryption MetaMask/browser-passworder#20

Closed

darkwing force-pushed the export-key branch 4 times, most recently from 189f85b to 12f4526 Compare September 30, 2022 20:56

darkwing marked this pull request as ready for review October 14, 2022 14:55

darkwing commented Oct 17, 2022

View reviewed changes

index.js Outdated Show resolved Hide resolved

darkwing commented Oct 17, 2022

View reviewed changes

index.js Outdated Show resolved Hide resolved

danjm mentioned this pull request Oct 19, 2022

Fix #15050 - MV3: Keep the user logged in when service worker restarts MetaMask/metamask-extension#15558

Merged

6 tasks

naugtur reviewed Oct 24, 2022

View reviewed changes

index.js Outdated Show resolved Hide resolved

Gudahtt reviewed Oct 26, 2022

View reviewed changes

package.json Outdated Show resolved Hide resolved

darkwing mentioned this pull request Oct 31, 2022

Provide exported key with encryption MetaMask/browser-passworder#29

Merged

legobeat reviewed Nov 1, 2022

View reviewed changes

index.js Show resolved Hide resolved

legobeat reviewed Nov 1, 2022

View reviewed changes

index.js Outdated Show resolved Hide resolved

Gudahtt reviewed Nov 2, 2022

View reviewed changes

naugtur reviewed Nov 6, 2022

View reviewed changes

naugtur previously approved these changes Nov 6, 2022

View reviewed changes

legobeat reviewed Nov 7, 2022

View reviewed changes

package.json Outdated Show resolved Hide resolved

darkwing dismissed naugtur’s stale review via 3c02979 November 7, 2022 16:18

darkwing added 4 commits November 7, 2022 10:23

Export key for encrypted key login

c25efe0

Progress

e239774

Delete encryption data upon lock

3c4e88d

Progress: Ensure addAccount and removeAccount work by allowing encryp…

eb8b357

…tion via key

darkwing and others added 2 commits November 7, 2022 15:15

Restore _updateMemStoreKeyrings call to forgetDevice

37af169

Merge remote-tracking branch 'origin/main' into export-key

4021e0c

* origin/main: Set password sooner to avoid redundant persistance (#154) Ensure newly created vaults are unlocked (#155)

Gudahtt reviewed Nov 7, 2022

View reviewed changes

index.js Outdated Show resolved Hide resolved

index.js Outdated Show resolved Hide resolved

index.js Show resolved Hide resolved

Remove redundant verifyPassword call

81cd50a

Co-authored-by: Mark Stacey <[email protected]>

Gudahtt reviewed Nov 7, 2022

View reviewed changes

index.js Outdated Show resolved Hide resolved

index.js Outdated Show resolved Hide resolved

darkwing and others added 3 commits November 7, 2022 17:36

Remove default value for opts with addNewKeyring

12d8365

Co-authored-by: Mark Stacey <[email protected]>

Remove unnecessary memstore keyring update

a7a7bc7

Avoid parsing the encryptedVault twice

2d4b51d

Co-authored-by: Mark Stacey <[email protected]>

Gudahtt reviewed Nov 8, 2022

View reviewed changes

darkwing added 6 commits November 7, 2022 19:17

Ensure encryptionKey is set, rename test set to cacheEncryptionKey

78412cb

Add test coverage for attempting to persist without key or password

9a0343e

Improve 'cleans up login artifacts upon lock' test to ensure encrypti…

0071c04

…on key is set

Lock keyringcontroller before submitting encryption key

7907b34

Move encryptionSalt to memStore

9178496

Rename newExportedKey to newEncryptionKey

88299ef

Gudahtt reviewed Nov 8, 2022

View reviewed changes

darkwing added 5 commits November 8, 2022 11:28

Validate freshness of encryption key by validating salt

3848e04

Use string equality matcher for expect

c137eae

Ensure the encryption key method is used in tests

83e0973

await setLocked

a5fe207

Fix missing string matcher

aacd2a1

Gudahtt previously approved these changes Nov 8, 2022

View reviewed changes

Fix lint

ad5169d

darkwing dismissed Gudahtt’s stale review via ad5169d November 8, 2022 20:39

Gudahtt approved these changes Nov 8, 2022

View reviewed changes

Merge branch 'main' into export-key

cc7ff86

darkwing merged commit 27507b0 into main Nov 8, 2022

darkwing deleted the export-key branch November 8, 2022 23:02

legobeat mentioned this pull request Sep 10, 2023

Update eth-simple-keyring to v6.0.0 #264

Closed

9 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Keep User Logged In: Export key for encrypted key login #152

Keep User Logged In: Export key for encrypted key login #152

darkwing commented Sep 30, 2022 •

edited

Loading

Gudahtt commented Oct 26, 2022 •

edited

Loading

legobeat Nov 1, 2022

Gudahtt Nov 1, 2022

Gudahtt Nov 1, 2022

legobeat Nov 2, 2022 •

edited

Loading

Gudahtt Nov 3, 2022 •

edited

Loading

Gudahtt Nov 3, 2022 •

edited

Loading

Gudahtt Nov 3, 2022

Gudahtt Nov 2, 2022

darkwing Nov 2, 2022

darkwing Nov 2, 2022

naugtur Nov 6, 2022

naugtur Nov 6, 2022

Gudahtt Nov 7, 2022 •

edited

Loading

Gudahtt Nov 7, 2022

Gudahtt commented Nov 2, 2022

naugtur Nov 6, 2022

Gudahtt Nov 7, 2022

darkwing Nov 7, 2022

naugtur Nov 6, 2022

darkwing Nov 7, 2022 •

edited

Loading

Gudahtt Nov 7, 2022 •

edited

Loading

naugtur Nov 6, 2022

naugtur left a comment

Gudahtt Nov 8, 2022

Gudahtt Nov 8, 2022

Gudahtt Nov 8, 2022

darkwing Nov 8, 2022

Gudahtt Nov 8, 2022

Gudahtt left a comment •

edited

Loading

Gudahtt Nov 8, 2022


		this.store.updateState({ vault });

		// The keyring updates need to be announced before updating the exportedKeyStrings

Keep User Logged In: Export key for encrypted key login #152

Keep User Logged In: Export key for encrypted key login #152

Conversation

darkwing commented Sep 30, 2022 • edited Loading

Gudahtt commented Oct 26, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

legobeat Nov 2, 2022 • edited Loading

Choose a reason for hiding this comment

Gudahtt Nov 3, 2022 • edited Loading

Choose a reason for hiding this comment

Gudahtt Nov 3, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Gudahtt Nov 7, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Gudahtt commented Nov 2, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

darkwing Nov 7, 2022 • edited Loading

Choose a reason for hiding this comment

Gudahtt Nov 7, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

naugtur left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Gudahtt left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

darkwing commented Sep 30, 2022 •

edited

Loading

Gudahtt commented Oct 26, 2022 •

edited

Loading

legobeat Nov 2, 2022 •

edited

Loading

Gudahtt Nov 3, 2022 •

edited

Loading

Gudahtt Nov 3, 2022 •

edited

Loading

Gudahtt Nov 7, 2022 •

edited

Loading

darkwing Nov 7, 2022 •

edited

Loading

Gudahtt Nov 7, 2022 •

edited

Loading

Gudahtt left a comment •

edited

Loading