1

I would like to develop an app on an EVM compatible L1, however MetaMask currently does not have it on its list of supported networks. Hence the only alternative I can think off would be to manage private keys directly as follows.

On initial load:

  1. Prompt connect wallet
  2. Prompt existing privateKey input or new key-pair generation and store in sessionStorage
  3. Prompt password input and store hash(password) in localStorage
  4. Encrypt privateKey with password and store in localStorage

On subsequent loads:

  1. Prompt passwordAttempt input and if hash(passwordAttempt) matches hash(password) in localStorage decrypt privateKey and store in sessionStorage
  2. Retrieve privateKey from sessionStorage for signing transactions when required.

I'm also looking to develop the frontend in Create React App which to the best of my knowledge is resistant to certain attacks such as XSS. But I'm not sure of other security vulnerabilities of directly managing the private keys in the app, other than the web app being compromised by for example a malicious actor deploying malicious code to a production environment.

Could someone please shed light on the pros and cons of using a browser wallet extension and managing private keys directly in app? Also if such vulnerabilities exist would a native app implementing similar privateKey management solve the shortcomings of its web app counterpart?

Improve this question
7
  • If it's an EVM derivative, I think MetaMask might work just fine if you provide a RPC endpoint for the network. Or?
    – Lauri Peltonen
    Dec 29, 2021 at 18:44
  • The network is EVM compatible, but it isn't listed on chainlist.org so to the best of my knowledge I can't specify an RPC endpoint since I don't have at least 1 mandatory field i.e. the Chain ID
    – MShakeG
    Dec 29, 2021 at 18:55
  • Ah, right. I wonder why it doesn't have chainId, but you're correct, it's mandatory info - can't add without it. Unsure if it's mandatory for it to be listed somewhere (for example chainlist)
    – Lauri Peltonen
    Dec 29, 2021 at 18:57
  • I don't see why it would be mandatory to register a Chain ID, but I can see the advantages of doing so such as MetaMask compatibility.
    – MShakeG
    Dec 29, 2021 at 19:03
  • It's mostly useful for replay protection. A transaction is only for that chainId, so it can't be replayed in other networks
    – Lauri Peltonen
    Dec 29, 2021 at 19:05

1 Answer 1

Reset to default
0

There's an even simpler implementation called Burner Wallets for Ethereum that doesn't even store a password hash: see https://burnerwallet.co/ -- it seems so far that there haven't been any attacks. I wouldn't use just password hashes, as then you are vulnerable to a rainbow attack if localstorage is compromised (and that seems like the whole point of your decryption method). Metamask also stores its keys in the browser storage (different for different browsers, can verify in source code here: https://github.com/MetaMask/metamask-extension), so it's not more secure for that reason (again, varies by exact implementation of your application).

Improve this answer
6
  • My understanding is that burnerwallet is an npm package that pretty much implements what I proposed except it stores the private key unencrypted in localStorage which would be less secure than my proposal and would still suffer from the same security vulnerabilities which may not exist using a browser wallet extension. Even if MetaMask does store keys in browser storage it would still be more secure as I would imagine it being more difficult to deploy malicious code changes to MetaMask in the Chrome Web Store than to a small startups frontend that would compromise keys.
    – MShakeG
    Jan 2, 2022 at 7:34
  • Also rainbow table attacks can easily be mitigated by storing a random salt in localStorage that's hashed along with the password.
    – MShakeG
    Jan 2, 2022 at 7:41
  • Yup -- if you salt your passwords, your implementation should be secure; there's thousands of burner wallet accounts with hundreds to thousands of dollars each, so one would imagine any easy hack on localstorage already would have been exploited -- I'm trying to say that burner wallet's current security means that you are likely fine.
    – John Targaryen
    Jan 2, 2022 at 7:56
  • Fair enough, but since I'm not looking to build on Ethereum burnerwallet wouldn't work well, so I might as well build my own implementation suited to that network. Also using burnerwallet directly is still susceptible to malicious code changes being deployed to production, so unless there's a way to cache an entire frontend(FE) in browser and only allow manual FE updates that clears storage and requires the user to re-enter and trust the updated FE with their keys I don't see how this potential vulnerability can be avoided.
    – MShakeG
    Jan 2, 2022 at 8:11
  • Right, a re-implementation for your network sounds best. Well, a user always has to trust that the website owner is not maliciously stealing their keys; if you have your own implementation it sounds like you dont have to rely on a third party.
    – John Targaryen
    Jan 2, 2022 at 23:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.