Using keccak256 to password protect functions, similar to a commit-reveal setup

Hello friends,

I am looking for opinions and potential pitfalls to this idea.

I want to mint ERC-720 tokens and give each one a unique password in order to interact and function with that induvial NFT. I would generate passwords outside of the blockchain, those would be encrypted using Keccak256 and stored in the NFT contract as a // mapping(uint256 => bytes32) public passwords; where uint is token ID and bytes32 is the hash. I would likely store the initial password hash mapping as part of the minting process.

From there i would password protect certain functions by requiring the the user enters a string of characters which is hashed in Keccak256 and checked against the bytes stored in the mapping of the token you are trying to interact with.

SIMILAR to this article about making a voting commit-reveal setup.

Is this more or less secure? What about adding "Salt" or "Pepper"? I appreciate any help or suggestions.

Thanks

1 Like

I don't see a particular problem with this approach. It's a straightforward password storage pattern. It does, however, require that people remember their passwords, some hygiene for not sharing them, a setup for resetting etc.

2 Likes

Thanks for the input and the forward-thinking about resetting passwords. It is much appreciated.