When Troy Hunt blogged about the adoption of HIBP’s Pwned Password, it got me thinking about what a general approach should be and how it should be implemented to avoid obstructing with the current setup.
Let’s first talk about what this service is about.
Troy has been collecting and verifying data from many headline-worthy breaches. Over the years, he has accumulated a considerable database of compromised email and password hashes.
Originally, he created an API for developer to query breaches associated with an email address. However, with such information, you could only warn users about the breach and there are not many constructive actions that could be taken.
In August 2017, Troy implemented “Pwned Passwords” which allows the querying of a breached password.
Now that developers have access to breached passwords, we are able and we should prevent users from using them even if it means to annoy them.
Pwned Passwords was implemented using the k-anonymity model. This means that it is difficult to correlate the requested password to an individual.
It is crucial for Troy to find the optimal value of k. If k is too small, then the response size would be large which leads to bad performance. And if k is too large, then it reduces the level of anonymity.
Now that we have the background covered. I’ll move on to the considerations of implementing Pwned Passwords.
Troy has given developers two choices.
- Pwned Passwords API
- Downloadable Pwned Passwords
Here are some considerations that may be useful if you are thinking of utilising Pwned Passwords.
- When using API, the pwned passwords are updated whenever HIBP’s database update. Therefore you won’t have to download the offline version and keep it updated.
- When using API, you do not have to store the pwned passwords on the server which equates to more storage space. However, you are trading off bandwidth which brings me to the next point.
- Calling API on client’s browser instead of server
- There is no interference with the current setup. Pwned passwords check is performed as an additional check and other validation can still be performed on the server.
- Currently there is no rate limit for pwned password, but in the future if rate limit were to be implemented, we won’t have to worry if it is implemented on client’s browser.
- While you could argue that the submission could be bypassed using browser proxy, it does not actually compromise any security.
- Since the API uses SHA1, we are required to perform a hash on the plaintext password before requesting for API. Since the calculation is done on the client’s browser, we have offloaded this calculation to the user’s device.
Above is an example of such implementation. The form uses the onsubmit eventhandler. If a breached password was entered, the form would not be submitted.
You can try this by clicking the result tab and enter a simple password like ‘123’.
Now try to fat finger the password field and the form should be submitted to # which leads to the refreshing of the frame.