How should I store user's password in a smart contract?

Question

First I thought I could easily use private like:

mapping (address => bytes32) private userPassword;

and so just check if the entered password is right:

function enter(bytes32 password) {
   if (password == userPassword[msg.sender])
      //do smth
}

But then I read this in solidity docs:

Everything that is inside a contract is visible to all external observers. Making something private only prevents other contracts from accessing and modifying the information, but it will still be visible to the whole world outside of the blockchain.

So if I got it right, even if I use "private" visibility still everyone can see values of stored passwords. Then how should I store information that shouldn't be for public?

Answer 1

Users (contracts, trusted machines, other contracts) are identified by their Ethereum address.

Instead of storing their passwords, use msg.sender to authenticate.

Since you don't want anyone participating without authorization, you need a list of addresses that are authorized. You create add/remove user functions and you ensure that only the authorized admin (usually called owner) is allowed to access those contract functions.

The access control list would be a list of ethereum addresses.

Some organizational ideas here: Are there well-solved and simple storage patterns for Solidity?

And here: https://medium.com/@robhitchens/solidity-crud-part-1-824ffa69509a

Hope it helps.

Answer 2

If I understand correctly your requirements you may implement the following approach:

1. Generate passwords for all of the invited users and send them out.
2. Store in your contract hashed values of these passwords using keccak256 algorithm (you may do so with javascript library ). Remember to hash them off-chain and send final values to the contract.
3. Ask invited users to reveal the received password. Hash it on-chain using keccak256() solidity method and if the hashes are equal allow a user to join your contract.

Answer 3

Don't store passwords as advised use msg.sender to authenticate instead

Answer 4

As Jakub pointed out you can use keccak256 to store and verify secret passwords. Two problems with this method:

1. Supplying the plaintext password during access will reveal it to anyone monitoring the pending transactions pool. An attacker can then race your user and use the password by generating a corresponding transaction and specifying a higher gas price which will get executed earlier than that of your legitimate user.

2. Once the password has been used it is no longer secret.

There is nothing you can do to mitigate 1. aside from using a prohibitively high gas price to begin with when using the password.

To mitigate 2. you can require the user to generate and specify a new password hash that has to be send along with the password creating a new one use password for next time. Rinse repeat.

Answer 5

If I understood your question correctly,

Contract Deploying account should know the allowed users, well in advance or after deployment.

For your case knowing all the users while deployment is rolled out.

Other option is to allow everybody to requestRegister, have a eventTrigger from that, run your one time authentication logic and register the sender address in the list of allowed users.

With this further tracking of allowed users are ease and any time user addition also possible.