Breach and hash checks
ยท Shipped
Two surfaces in this network already deal with passwords, and both are live.
Breach
Breach checks whether a password appears in the Have I Been Pwned Pwned Passwords corpus.
The interesting property is how that can possibly be safe, because on the face of it "type your password in to see if it leaked" is the single worst instruction on the internet.
The k-anonymity range query
The Pwned Passwords API is built so the service never learns which password was checked:
- The client hashes the password with SHA-1, locally.
- It sends the first five hex characters of that hash and nothing else.
- The service returns every hash suffix it holds that begins with those five characters, typically several hundred of them.
- The client looks for its own suffix in that list, locally.
The password never leaves the browser. Neither does its full hash. The service sees a five-character prefix shared by hundreds of hashes and cannot tell which one was being asked about, or whether the asker even had a match.
That is the whole design, and it is worth understanding rather than trusting, because "it is hashed" on its own is not a security property. A plain hash lookup would tell the service exactly which password was checked. The prefix range is what makes the difference, and SHA-1 being cryptographically broken for collisions does not matter here: this is a lookup, not a signature.
What it still assumes
The client does the hashing and only sends the prefix. That is checkable by reading the source or by watching the network tab, and a user who cannot do either is taking it on trust.
Cipher Score
Cipher Score analyses password strength in real time with entropy-based crack time estimates.
It sends nothing at all. The analysis is arithmetic on the string in the page: character classes, length, and patterns, turned into an entropy estimate and a crack time at an assumed guess rate.
The honest caveat on any tool of this kind is that an entropy estimate is a model of an attacker, not a measurement of one. A password that scores well against a generic model can still be the first guess against an attacker who knows the person. The number is a floor on effort, not a guarantee.
The pattern both follow
Neither tool has somewhere to send anything, which is what makes the claim checkable rather than a promise. That is the same constraint behind the whole network, written up in the threat model.
What is not shipped
otp and redact are planned and not live, so they are not linked. When they are, they get the same treatment: what the tool does, what it sends, and how you can check that for yourself.