Minimise key persistence, secure password entry

[kyranjamie]

Working on implementing Ledger support, I've been thinking about the way we manage keys in the wallet, and how this might be improved for software wallet users.

The wallet was implemented with a pattern that uses the background script to cache the seed phrase, once unlocked with the user's password. When a user opens the wallet, the popup script asks the background script if there are any keys, and—if there are—returns the entire wallet state object, which includes the plaintext private key. This practice is not dissimilar to Metamask.

The wallet's UI, a the React app ran in the pop up script, is the part of the software most susceptible to XSS attacks, supply chain attacks etc. As such there's a greater risk having the key there, than in the background script, for similar reasons to why the background script has access to browser APIs the popup does not.

Ideally, then, we should design the wallet in such a way where the plaintext key is only ever in memory of a single script's context (the background), as this would limit the opportunities for such attacks. Could the background script, the more isolated context, function like a hardware wallet: accepting unsigned transactions, asking for the password, decrypting the key, signing and returning the transaction?

Consider that the only time the plaintext key is needed is when:

• Viewing the seed phrase
• Signing a message
• Signing a transaction

This has left me wondering if it'd be possible to create separate, dependency-free pop up windows with tight content security policies, that communicates only with the background script, to accept the password needed to decrypt the key. This way, the main package-heavy app would never have access to any of the information needed to steal funds.

If it's possible to securely send messages only to the background script, this would make for a much more secure design. The flow would look something like this:

graph TB
    A(User initiates send STX request in popup script) -->|Bg receives unsigned tx msg| B(Secure password entry field opens asking for password)
    B -->|User submits password| D(Password back to background script)
    D -->|Background script decrypts key & signs transaction| E(Bg script sends signed tx back to popup script)
    E --> F(Popup script broadcasts tx)

Loading

Curious to get everyone's feedback. Started this as a discussion as I'm not 100% this type of message passing is possible.

---

Edit 2022-01-24
Had another look into this and validated this could work.

1. Popup script sends sign transaction message, and payload, to background script
2. Background listens for this msg and opens a password popup window, noting the new window's tabId
3. Password window listens for request-password method from background
4. Background sends request-password message immediately
5. Password window receives request-password message & validates senders origin
6. Password window now has access to sendResponse method of the event, which is returned only to the message's sender (the bg script). User's password is returned directly to bg script

More handling would be needed for wrong passwords etc, but overall this would allow the main app's code to never need to know the secret key.

Edit 2022-08-09
Rephrased discussion for clarity, added diagram

[igorsyl]

How would secure password entry field authenticate the background script prior to forwarding the clear text password?

[kyranjamie]

Yeah good question. I suppose any frame could trigger the popup window, mock the same requests, and listen for the password response.

Perhaps authentication of the script's context could work in a way where a uuid/key is generated for each background-initiated password request. Which could then be validated before sending the password.

This'd require a mechanism to have a shared secret between the bg script & the single popup window, though. Not sure how this would work. It could be passed as a url param, though with the tabs permission this can be read. We don't use this currently, so maybe it's safe, or perhaps there's another way to pass a secret. Will research further.

Edit: the sender param from the onMessage listener also describes the origin url, which for the background script (mv2) is chrome-extension://eecnpiikplhmnkkfjdnlmhjfhalcnohl/_generated_background_page.html. It might also work to just verify this.

[Hero-Gamer]

Is 2FA an option for browser extension as additional security measure?
An idea which came across on a Twitter as I was searching for topic related to this GH issue: #2628
https://twitter.com/simonb03jan2009/status/1442505315203829762?t=hvSABv7NEWMv6lY8cKG3lw&s=19

[kyranjamie]

Vaild points made by this guy on Twitter. I'm not against 2FA, though can't help but think it's a better idea to instead focus on improved hardware wallet support, than further encouraging use of software wallets.