Create a proposal on how the burner-wallet can prevent its private key from leaking when signing an external dapp's transactions

[TimDaub]

Scope

• Currently burner-wallet's private keys are stored unencrypted in local storage
• In its current form, this doesn't pose too much of a risk for users as we're enforcing strict reviews to ensure that these keys are not being stolen by the burner-wallet itself.
• Our goal with the burner-wallet is eventually however to make it a platform for dapps and as such we'll have to import code into the burner-wallet that is not necessarily subject to the same strict reviews we practice on our repositories
• Audius's Hedgehog also uses localStorage to store their keys
• Recently it was noted on Twitter how easy an attack against a user using hedgehog is: https://twitter.com/miguelmotah/status/1134533908861661184
• As we'd like to keep gatekeeping of burner-wallet dapps to a minimum, but as we'd also like our users' private keys to be securely stored we'll have to find a way to handle this kind of attack

Deliverables

• E.g. Do some research on how we can prevent the leak of a burner-wallets user's private key
• E.g. Do some research if and how sensitive information can be stored on the browser
• Enumerate various technical approaches and rate them based on how likely it is for a key to get stolen
• Check if there's technology/browser standards that allow to store sensitive information securely in a browser
• If that's not the case, explore other techniques that could help reducing the risk of a private key getting stolen
  • Crazy idea, but could EME, Java Applets or Adobe Flash (lol) help us store private keys?
  • Are techniques applied in Gnosis Safe and/ custodial smart contracts applicable?
  • IFrames + signing via postMessage?

The deliverable should be a document or a demo covering the points above and more.

Gains for the project

• Secure users' money and allow them to use burner-apps

Notes

This issue has a 30% reviewer share.

Roles

bounty gardener: @TimDaub / 15% bounty worker: name / 55% bounty reviewer: name / 30%

[lebed2045]

I thought quite a lot about that, one idea is the is to use one-time passwords (as a deterministic sequence of some unique long user id) from the server, and keep rotating and re-encrypting times to time. Even is localStorage gets compromised it's worthless without the password, an attacker won't able to get it, no degrading of UX because of the user doesn't type it either. The problem is npm attack when you can read all variables, here's the only way is to reduce amount in dependencies.