search

JoinColony / purser

Interact with Ethereum wallets easily
https://joincolony.github.io/purser
MIT License
84 stars 21 forks source link

Software Wallet shouldn't expose the `privateKey` #71

Open rdig opened 6 years ago

rdig commented 6 years ago

There's an argument to be made that we should withhold the privateKey (or the mnemonic, or the keystore) from the end user, from the standpoint of security.

The user will be able to interact with the wallet normally, but to prove his/her identity it must sign and verify a message (like all other wallet types expect you to do)

This will provide a more consistent mode of operation between all the wallet types.

On the other hand, the user already used one of those methods to open the wallet, so there's also the reverse argument that they are already known, so what's the point of hiding them?

NeoBeum commented 4 years ago

What about Salt?

rdig commented 4 years ago

The original idea here intended for the wallet instance to not allow you direct access to the private key or mnemonic at all.

Basically the same way Metamask functions.

You would still be able to sign tx's or messages, but only using the instance's static functions (signTx, signMessage), which would internally access that value.

I don't really understand how hashing the values would help in this particular instance.

Also, for this to work, it would need so sort of confirmation mechanism. Ie: ask the user before signing using the particular wallet instance.