Assume I have a public API endpoint which I'd like to protect against abuse. I'd like to implement a solution that ensures that the client spends some computational time before allowing the request to succeed.
What would be the problem with having the server choose a random hash and a variable cost of say 200,000, wherein the server would send the hash and the cost to the client, and the client would be required to run the hash through PBKDF2 200,000 times, which should take some number of seconds. The client would then send the result back to the server with their request, and the server verifies that 200,000 iterations of the hash indeed matches the client result.
This would in theory seem to severely limit the number of requests a spammer can execute.
But the idea sounds too simple to be effective. Am I missing something, or would this be a viable solution?
There are two potential problems I can think of:
The spammer can force our own server to waste computational time on calculating these hashes, but we can precompute certain hashes with certain costs and dish out a random entry from our table to any requester.
Client devices may be less powerful than a potential abuser's machine, and thus we might require a cost of say 2,000,000 to be an effective deterrent, but that cost would be too high for an average client device.