When Troy Hunt blogged about the adoption of HIBP’s Pwned Password, it got me thinking about an ideal general approach that anyone can take to implement this feature without obstructing the current setup.
Let’s first discuss 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 amount of compromised email and password hashes.
Originally, he created an API for developers to query breaches associated with an email address.
In August 2017, Pwned Passwords was implemented. It is an API which allows the querying of a breached password.
With access to such information, developers across the internet are able to warn their users if their current password is found in the database.
Pwned Passwords is not just a database of breached passwords. It’s ingenuity comes from how the API was implemented.
This means that it is difficult for the API provider to correlate the requested password to an individual.
A typical request looks like this:
\‘21BD1’ is the first five character of a SHA-1 hash.
By requesting for a range, it eliminates the uniqueness to an individual’s password since there are at least a dozen of SHA-1 hashes prefixed with ‘21BD1’.
But there is a catch. It is crucial for Troy to find the optimal value. If the number of characters is too small, then the response size would be large which leads to bad performance.
On the other hand, if the number of character increases, then it reduces the level of anonymity.
The implementation is fairly straightforward. There are 2 ways of getting a breached password.
- Pwned Passwords API
- Downloadable Pwned Passwords
However, I favour using API more than the latter and here is why.
- When using API, the pwned passwords are updated whenever HIBP’s database update. Therefore you do not have to download the offline version and keep it updated.
- In addition, you do not have to store the pwned passwords on the server which translate to more storage space (yay!). However, you are trading off bandwidth which brings me to the next point.
- Calling API on client’s browser instead of server
- No interference with the current setup. The check for breached password acts as an additional check and validation could still be performed on the server.
- Currently there are no rate limits for the API. However, in the future if rate limit were to be implemented, we would not have to worry since the request is from the user’s IP address.
- It could be argued that the check could be bypassed using browser proxy. This however does not actually compromise any security. Our main purpose is to warn users that the password that they are using is found on other breaches. If they are tech-savvy enough to use a browser proxy, they would have understood the risk.
- Since the API uses the first characters of a SHA-1 hash, we are required to perform a hashing function on the plaintext password before requesting for API. And since the calculation is performed on the client’s browser, we have offloaded this calculation to the user’s device.
Proof of Concept
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.