20Nis
Using Proof of Work to slow down login attempts
For a while I've been pondering a user authentication protocol that aims to ensure that a client does some computational work before the server will attempt to authenticate the password.
The reason for this is to remove some of the asymmetry involved when a bad actor hits a login endpoint. The server has to perform an expensive password hash operation, while the client just sends a request. This means that the server will be using a lot more resources than the clients.
To dissuade bad actors, I had the following idea, inspired by bitcoin, for a login protocol:
- Client sends request to server, stating that they would like to do a login attempt.
- Server responds that the client may proceed. It also includes some random string and asks the client to produce a string such that the random string appended with the string generated by the client will have X number of 0s at the end of its SHA1 hash.
- Client generates random strings and SHAs them until a string matching the condition is found. and sends that string with the login request, along with the user's credential
- Server validates the string does in fact generate such a SHA when appended to the initially returned random string. Then performs a (much more expensive than SHA) hash check on the user's password.
Is there a good reason that such a pattern is not being used today, or would such a process achieve the goal?