4

To explain myself, what I need is to be able to have a way so that the central server can only interact with the contract only with valid identification from a user? This identification provided by the user may be a password or anything else that isn't too inconvenient for the user. However, most importantly, there should be no way for someone to hack the system into authenticating an invalid authentification. So ideally the contract would have to verify that the user has provided identification that allows the server to perform a certain task such as changing the user's balance value in the contract.

The goal is that a user can interact with the decentralized contract through the server which can then send additional information to the contract, if and only if a certain authentification that can not be forged and can be verified by the contract is provided.

To give a concrete example for my use case: I have a web app that users can access from their browser. However, I want users to be able to easily interact with a smart contract without having to set up anything on the client side. Therefore I want to be able to have a user which has an account on the web app to be able to click a simple button that sends a post request to the server. This post request will for instance transfer a user's balance into another user's balance in the contract. However, the server has to know to only call the smart contract if this is a legitimate and verified call. And the smart contract needs to be able to distingue between a legitimate call and a forged call. As to not have someone send a user's funds to his account on the smart contract without authorization. Which would be undesirable since what happens on the contract is out of my control.

Is there any smart way to do this?

||improve this question
  • Can you elaborate the use case a bit more? I answered it in terms of offline transactions but that may not be what you wanted. – JackWinters Dec 2 '16 at 21:36
  • @JackWinters I have added a bit of extra information, I don't know if it makes it any clearer. If it doesn't let me know, and I will try and be as concrete as possible. – Pabi Dec 2 '16 at 23:00
  • It sounds like they trust your server so why is this not just normal server side authentication (username & password/ two factor) ? – JackWinters Dec 2 '16 at 23:05
  • @JackWinters although they might trust the server, dealing with money, I want to make sure not all the security or contract call relies on the security of my server. – Pabi Dec 2 '16 at 23:34
3
  1. Pre-Approve The user could sign transactions offline for example using ethereumjs-tx. The service then broadcasts the signed transactions. These could either modify the contract directly or they could set permissions within the smart contract so that the service is allowed to perform certain operations. For example consider how according to the ERC: Token standard #20 you "can authorise an other Allow _spender to withdraw from your account, multiple times, up to the _value amount"
  2. Post-Approve Conversely the service could perform an operation. However changes are then staged. The user then signs an offline transaction that calls a function to approve the operation and allow staged changes to be written to the sensitive part of the contract.
||improve this answer
  • Is there any way to post-approve a contract call while preventing the user from going back on his decision of making the call by simply not approving the contract call at a later time. Otherwise, would there be a way for a pre-approved contract call to work without having the user put in his private key every time to sign it? Timing is essential in what I am doing. I need the server to be able to broadcast the transaction adding some data as soon as the user clicks on a button in the web app. – Pabi Dec 3 '16 at 22:07

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.