Thanks! I hate it even more. I installed it fresh on a VM and this means to say I have to disable password management in chrome regardless if I ignore using it, because my data and password in whatever form they care to describe it, is sent away from my computer and away from the destination I intended it. I hate it.
> "In order to inform signed-in users about leaked credentials this "
"service uploads a prefix of the hashed username, as well as the "
"encrypted username and password following a successful password "
"form submission. The former is a 3 bytes of the hash and doesn't "
"reveal the username to the server in any way. The latter is "
"completely opaque to the server. The server responds with a list "
"of encrypted leaked credentials matching the prefix of the hashed "
"username, as well as with a re-encypted version of the uploaded "
"username and password. Chrome then reverses its encryption on the "
"re-encrypted credential and tries to find it in the list of "
"leaked credentials. If a match is found, Chrome notifies the user "
"and prompts them to change their credentials. Re-encryption part "
"is for the privacy reason. The server can't read the user's "
"password. At the same time the client can't read the "
"usernames/passwords of other leaked accounts but only can check "
"the current one.";
....Sounds like an awesome opportunity to fuzz that API, and dump the entirety of Google's "compromised credential" DB.
For research purposes only of course. I'm sure they provisioned enough instance to handle a rather aggressive fuzzing as well seeing as this thing is surely built to stand up to the entire Chrome using internet logging in at the same time, right?
And surely there is no way whatsoever one could use this data to potentially compromise other accounts...
Or use it as a basis for birthday attacks on unreported compromised accounts. Or, set up some unique credentials in compromised systems, then checking the googleapi call for it to see if the intrusion has been reported/caught yet.
If you look at the link provided by this thread’s parent you’ll see the credential database / API is encrypted, and the input is 3 bytes of the username hash.
None of what you’re describing is possible. Even if it was, it would not be as useful as you think as the only leaks in that database will be public leaks that everyone can easily find if they know where to look.
Looking through my query logs it appears that Android phones do this as well even if Chrome is not explicitly launched. Perhaps it is the Google Play Store or some related service which I believe is Chrome.
The actual name I see is "passwordsleakcheck-pa.googleapis.com" passwords vs password.
> "In order to inform signed-in users about leaked credentials this " "service uploads a prefix of the hashed username, as well as the " "encrypted username and password following a successful password " "form submission. The former is a 3 bytes of the hash and doesn't " "reveal the username to the server in any way. The latter is " "completely opaque to the server. The server responds with a list " "of encrypted leaked credentials matching the prefix of the hashed " "username, as well as with a re-encypted version of the uploaded " "username and password. Chrome then reverses its encryption on the " "re-encrypted credential and tries to find it in the list of " "leaked credentials. If a match is found, Chrome notifies the user " "and prompts them to change their credentials. Re-encryption part " "is for the privacy reason. The server can't read the user's " "password. At the same time the client can't read the " "usernames/passwords of other leaked accounts but only can check " "the current one.";