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.

  • Looks to be a duplicate of ethereum.stackexchange.com/questions/68437/….
    – user19510
    Commented Mar 17, 2019 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
    Commented Mar 17, 2019 at 14:50

1 Answer 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
  • Thanks @goodvibration ! A well thought out solution.
    – socket_var
    Commented Mar 17, 2019 at 15:09
  • any specific reason why client is doing the encryption and decryption, server can do it if we send the password to the server right? This way I can just send a single post request. If I do it as above I would be storing private key when logged in, signing in client which means 2 post requests one to login other after signing. Do you want to avoid sending password to the server ?
    – socket_var
    Commented Mar 17, 2019 at 22:10
  • 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). Commented Mar 18, 2019 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? Commented Mar 18, 2019 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
    Commented Mar 18, 2019 at 6:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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