spesmilo
qt: lightning payments don't require password
I noticed that lightning payments don't require the user to enter a password even if the wallet is password protected. This behavior is different than with on-chain payments which always require the password. The same applies for https://github.com/spesmilo/electrum/pull/10303. Is this intentional design or is this just not implemented yet?
If the wallet has a password, usually keystore-encryption is enabled, which protects the onchain keys, even in RAM, but the lightning xprv is stored unencrypted in the wallet db. (There might be also the storage-encryption on top of all this, but if the wallet is already open, that's irrelevant.)
If the lightning keys were encrypted in memory, you could not even receive without entering your password.
On Android, the password is stored in memory, on desktop Qt, IIRC the password is only stored in memory if the wallet is "unlocked", right?
Anyway, the crucial point to note is the Console. If something is stored unencrypted in memory, you can get access to it via the Console.
- One idea is to password-protect the Console. Ok but with what password?
- It can't be the wallet password, as then one could just create another wallet and use the Console there, as there is no security boundary between wallets.
- I guess we could password-protect the Console with the plugin password if we wanted to. (and if there was no plugin password set yet, the Console would be disabled)
We could for example just ask for the password in the GUI when initiating a lightning payment without actually doing any encryption of lightning key material. Someone could still use the console to initiate a lightning payment without password but it could prevent the 80% non-technical attackers (e.g. someone just walking by the open wallet) from quickly sending out money and unify the UX with onchain payments. However it could also be considered as false sense of security and might even lead users to riskier behavior (leaving wallet open assuming nothing can be sent without password), probably better to keep it as is.