1

I hope this question is not a duplicate. Since I'm using Infura as a full node, I need to send raw transactions by signing them.

In a multi-user application how would my application on the server-side sign transactions on the respective user's behalf. Saving every user's private key sounds unsafe. Would appreciate any concrete examples or sample source code on how to do this. TIA.

Improve this question
2
  • Looks to be a duplicate of ethereum.stackexchange.com/questions/68437/…. – user19510 Mar 17 '19 at 5:16
  • @smarx Sorry about that. I asked that question focusing on using metamask and I didn't get a usable solution. So I wanted to diverge and focus on the general solution for signing with private keys on the server and I got an answer below. – socket_var Mar 17 '19 at 14:50
1

When a user registers:

  1. The user enters a memorable password
  2. The client encrypts the private key with the password, and sends it to the server
  3. The server receives the encrypted private key, and saves it into the database

When a user logs-in:

  1. The server sends the encrypted private key to the client

When a user performs a transaction available on client's web-page:

  1. The user enters the password
  2. The client decrypts the private key using the password
  3. The client signs the transaction with the private key
  4. The client sends the signed transaction to the server
  5. The server sends the signed transaction to the node
Improve this answer
10
  • Thanks @goodvibration ! A well thought out solution. – socket_var Mar 17 '19 at 15:09
  • @socket_var: You're welcome! – goodvibration Mar 17 '19 at 15:34
  • 1
    @socket_var: Do you want to avoid sending password to the server ? - exactly. As for https - possibly, but I'm not a security expert, so may I suggest that you post it as a separate question on Stack Overflow (since it is not specific to Ethereum, and due to the relatively small community on this website, you're not likely to get an answer here as fast as you would on SO anyway). – goodvibration Mar 18 '19 at 5:20
  • 1
    @socket_var: BTW, the custom standard is that you ask the user to enter a password before every transaction (not just once), for security reasons. And in any case, I don't see how the current scheme yields more post requests from client to server. It is 1 for login and 1 for every transaction. How else would you reduce this? – goodvibration Mar 18 '19 at 5:27
  • 2
    Having a decentralized app that saves user information (keys) in a server sounds contradictory. The wallet can be kept on the client side encrypted. The question is if letting the key in memory in the browser is safe, then the password should be requested only one. This of course require that the website is open source (like myetherwallet) so that users can be assured that there is no malicious code. – Jaime Mar 18 '19 at 6:11

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.