Pwned Passwords

Over recent weeks, I've begun planning the release of the 3rd version of Pwned Passwords. If you cast your mind back, version 1 came along in August last year and contained 320M passwords. I made all the data downloadable as SHA-1 hashes (for reasons explained in that post) and stood up a basic API to enable anyone to query it by plain text password or hash. Then in Feb, version 2 landed and brought the password count up to just over half a billion whilst also adding a count to each password indicating how many times it had been seen. Far more significantly though, it introduced the k-anonymity search model that Cloudflare worked on and that's when things really took...

Back in August, I pushed out a service as part of Have I Been Pwned (HIBP) to help organisations block bad passwords from their online things. I called it "Pwned Passwords" and released 320M of them from real-world data breaches via both a downloadable file and an online service. This was in response to NIST's Digital Identity Guidelines and in particular, the following recommendation: When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to: Passwords obtained from previous breach corpuses. Seen a password in a data breach before? Then...

A couple of months ago, I launched version 2 of Pwned Passwords. This is a collection of over half a billion passwords which have previously appeared in data breaches and the intention is that they're used as a black list; these are the "secrets" that NIST referred to in their recent guidance: When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. In other words, once a password has appeared in a data breach and it ends up floating around the web for all sorts of nefarious parties to use, don't let your customers use that password! Now, as I...

When I launched Pwned Passwords in August, I honestly didn't know how much it would be used. I made 320M SHA-1 password hashes downloadable and also stood up an API to query the data "as a service" by either a plain text password or a SHA-1 hash. (Incidentally, for anyone about to lose their mind over SHA-1, read that launch post as to why that hashing algorithm is used.) But the service did become quite popular, although that was just the beginning... I launched V2 in February and pumped the number of passwords up to just over half a billion. The big difference, however, was the introduction of the k-Anonymity model developed by Cloudflare (special hat-tip to Junade...

In the immortal words of Ricky Bobby, I wanna go fast. When I launched Pwned Passwords V2 last week, I made it fast - real fast - and I want to talk briefly here about why that was important, how I did it and then how I've since shaved another 56% off the load time for requests that hit the origin. And a bunch of other cool perf stuff while I'm here. Why Speed Matters for Pwned Passwords Firstly, read the previous post about k-Anonymity and protecting the privacy of passwords to save me repeating it all here. I've been amazed at how quickly this has been adopted since I pushed it out very early on Thursday morning my time....

Last August, I launched a little feature within Have I Been Pwned (HIBP) I called Pwned Passwords. This was a list of 320 million passwords from a range of different data breaches which organisations could use to better protect their own systems. How? NIST explains: When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. They then go on to recommend that passwords "obtained from previous breach corpuses" should be disallowed and that the service should "advise the subscriber that they need to select a different secret". This makes a lot of sense when you think about it:...

Edit 1: The following day, I loaded another set of passwords which has brought this up to 320M. More on why later on. Edit 2: The API model described below has subsequently been discontinued in favour of the k-anonymity model launched with V2. Last week I wrote about Passwords Evolved: Authentication Guidance for the Modern Era with the aim of helping those building services which require authentication to move into the modern era of how we think about protecting accounts. In that post, I talked about NIST's Digital Identity Guidelines which were recently released. Of particular interest to me was the section advising organisations to block subscribers from using passwords that have previously appeared in a data breach. Here's the...