• caglararli@hotmail.com
  • 05386281520

Using Proof of Work to slow down login attempts

Çağlar Arlı      -    2 Views

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:

  1. Client sends request to server, stating that they would like to do a login attempt.
  2. 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.
  3. 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
  4. 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?