Verifying OTP on-chain (keccak vs ecdsa)

Question

I am looking to build a smart contract that enables a user to withdraw the contract funds via a one-time-password provided by the creator. My idea was to hash a password off-chain and store that through the constructor of the contract. To withdraw the funds, a user is then required to provide the password which is hashed on-chain and verified against the hash that was initially provided. Of course after a valid password would be provided, it would not be secret anymore. That however would not be an issue as its only intended to work one time.

From what I understood is that using keccak would run into frontrunning issues, but ECDSA might work. I have only very basic understanding of cryptography, so I wonder if thats true and - if so - why.

Long story short:

• Would using ECDSA solve the frontrunning issue?
• Are there any other/better approaches that I should consider?

Thank you so much!

Answer 1

Unfortunately, it doesn't really matter what kind of encryption or hashing you use - you will always face front-running issues.

Basically the only secure way to restrict access in a smart contract is based on the knowledge of a private key. The private key can be used to sign a transaction or a message - ECDSA is the method how the signature is applied. ECDSA signatures can be validated in contracts with ecrecover.

Unfortunately, I don't see how message signing helps here, since any sent message can be front ran. Therefore, the only secure way to check access in a contract is checking the transaction sender's address.

You may, however, consider some sort of a multi-phase protocol. For example something like:

1. Someone sets up the contract with some sort of OTP
2. Someone with knowledge of the OTP sends first transaction which sets a value "this sender address claims he knows the OTP, but hasn't revealed it yet"
3. The same sender sends the OTP in a future block and gets the reward. The reward is given only if the sender address matches. There must be at least X blocks between these two operations. This way this transaction can't be front ran.