[prepend]

I like the approach reduces the risk, but this isn’t sufficient for me to actually trust a third party. The article calls out an example where the five character hash prefix has 477 matches in the password file.

That’s a ridiculously small number of possible values for a powerful actor trying to crack a password.

[leejoramo]

But your password is NOT one of just 477 known passwords. It is one of 2^(8*11) possible passwords that share the same first 5 bytes of a 16 byte hash.

[prepend]

The way I understand their implementation [0] is that the client sha256s their password and sends the first 5 characters, not bytes. The server then responds with all the matching hashes. In the article the example was 477 matching hashes.

So it’s not all possible hashes with that prefix, it’s only the hashes of entries in the known passwords.

If the server was compromised, it would be able to know which users requested which hash prefixes and compare that to the “known hashes” that match that prefix. Not all passwords submitted are matches, but some are. And it’s likely that a users pattern of testing particular hash prefixes could make it much easier to crack a password.

[0] https://blog.cloudflare.com/validating-leaked-passwords-with...

[snailmailman]

The password isn’t necessarily in the list, and if it is it should be changed. The service just returns the list and you check locally. The server only gets the first few characters of the hash.

Knowing the hash prefix of someone’s password doesn’t help you guess it. You can’t plan your guesses to have a matching prefix or anything. If your password is in the list, then the full hash is already out there and you should stop using it, because it’s probably been brute forced by someone or people are trying to guess it somewhere.