It is storing your passwords in plaintext locally, since this is about passwords that are saved by the user in Firefox's password store (the Saved Logins feature). These can (and should) be protected with a master password, but you obviously need to unlock the store before logging into a website.
They're not storing your passwords remotely, though. They're asking haveibeenpwned which maintains a list of leaked login information from past breaches.
Mozilla are using k-anonymity in their FirefoxMonitor service[0]. This feature syncs from FirefoxMonitor to a local browser DB and checks against that DB. However, I'm not 100% sure what data it syncs from FirefoxMonitor (obviously a subset, but I don't know how that's chosen. I'm not sure if they're using k-anon for requests between the Firefox browser and their own service).
From that ticket, the comments discussing the domain and time of the breach are about adding that filtering to the existing feature, not about those being the only checks. The article is not false.
Firefox has a built-in password manager, so plaintext passwords are necessarily stored in that database. The backend comparison service they're using supports a near-zero-knowledge protocol that allows clients to check for compromised passwords in the database efficiently without ever sending the password (or even a hash of the password) to the backend.
Also they can just query all the usernames (email addresses) of the accounts and get notifications if any of those usernames have appeared in breaches.
But... will mozilla or the people behind haveibeenpwned know I am using a pwned password? Basically, by checking if you are under risk, do you leak info to 3rd parties that can be used against you, before having the opportunity to protect yourself? Is there any info aobut the near-zero knowledge protocol somewhere? It's a fascinating topic for sure.
Essentially, the client hashes the password and then only sends the first 5 characters of the hash to HIBP. HIBP then returns the hashes of every password whose hash begins with the same characters (approx 477 matches, according to the article), and then it's up to the client to determine if there's a match.
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.
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.
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.
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.
No they don't. The browser hashes the password, then sends the first 5 hex digits of the hash to haveibeenpwned. HIBP replies with all the hashes of leaked passwords that start with these 5 digits and the browser then checks to see if the hash is in the list.
