0

We are planning to have some of the smart contract functionality available to external users, but only if they go via our website. (Eventually, they will be accessible via usual contract calls directly on the blockchain). So workflow is like this -> User-logs into our website - provides some information that we can validate against external sources - once validated, we invoke the corresponding smart contract functionality from the backend.

While I can use web3.js to call out from my website to the blockchain, how exactly would my account/wallet be secured by the website itself? As in, if our website is hosted on aws, should we have the secret key stored in our db and use it to sign our calls to the block chain? Or, is the only option to use mist/metamask from a locally secured computer to call the restricted external functions on the contract?

If anyone has done something similar, it would be great if you could share the list of tools you have used to secure and the list of tools you used to access the block chain.

Any thoughts on how multi-people organizations can effectively and securely handle access to smart contracts is also appreciated.

closed as off-topic by Nicolas Massart, flygoing, Richard Horrocks, Achala Dissanayake, Roman Frolov Feb 9 '18 at 19:18

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "You should only ask practical, answerable questions based on actual problems that you face. Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page." – Nicolas Massart, flygoing, Richard Horrocks, Achala Dissanayake, Roman Frolov
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    For AWS you may try something like AWS Key Management Services. I think the proper way to handle security is to define policies, enforce them and periodically make auditories. – Ismael Feb 7 '18 at 3:14
1

This depends on the trust model you're working with.

Normally the thinking behind Ethereum applications is that the user doesn't have to trust the people who developed the contract, and they are fully in control of their own data. On this model there is usually no trusted server-side code, and no priviliged party holding traditional username and password credentials. This is why we have things like MetaMask, that give the user control of their own credentials and ask them to approve requests that the application thinks it should make with them. These are usually client-side-only apps, where the user users your static html/js code, and there is no server-side code.

If your users have to trust you to store their username and password, you can keep a single key on your server and use that for all your users. Instead of using MetaMask, your users can interact with your server-side application, and that application sends requests to the blockchain by making requests from your server to your node's JSON-RPC interface. Contracts would be designed to rely on a (trusted) caller to provide the ID of the user who has logged into your server as a parameter. Although this is easy to set up technically, it's often sign that you may want to consider just using a normal database instead of a blockchain, since your users already have to trust you, and you or whoever hacks your server will be in charge of their assets and data. A normal database is simpler, cheaper and more efficient.

If the model is that it's possible for users to interact with the blockchain directly but you also allow them to use your website for convenience, then you may want to design the contracts to expect each user to have their own key, and keep a per-user key on the server. The obvious way to do this is to keep a lot of different accounts on your Ethereum node.

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