oasisprotocol
Refactor to not store password in memory
Related to https://github.com/oasisprotocol/oasis-wallet-ext/issues/31
Searching for getStore().password, it seems that password is stored in memory so that it can be used in the following methods:
- createAccount
- checkPassword
- addHDNewAccount
- addImportAccount
- addLedgerAccount
- addObserveAccount
- setCurrentAccount
- changeAccountName
- deleteAccount
- getMnemonic
- getCurrentPrivateKey
How different scenarios can be handled without keeping password:
checkPassword: use hash to compare, or just try to unlockaddImportAccount, changeAccountName, ..: asymmetrically encrypt, and only keep public key in memory for continuously encrypting changesgetCurrentPrivateKey: ask for password
How does metamask do this?
MetaMask does keep password in memory, which makes sense because MetaMask supports the feature of adding new accounts without requiring re-entry of the password or secret recovery phrase, and does not appear to use asymmetric encryption.
This stands in contrast to Harmony which is not as user friendly (requiring password and passphrase on account creation), but also does not store the password in memory.
What is best practice for wallet extensions?
I do appear to see a consensus that in memory storage is the only acceptable location for sensitive information, and don't see anything less secure than that used. I recall seeing that MetaMask uses RAM extensively and otherwise backups (browser feature) up an encrypted vault to disk.
I currently think that going to asymmetric is a good sized feature that will require non-trivial amount of change. This is part of our feature vs password storage simplicity tradeoff.
How different scenarios can be handled without keeping password:
Agree. One alternative path would be to require password re-entry on the UI interactions that require re-encryption. Another would be to asymmetrically encrypt such that only decryption would require password entry.