Better password protections in Chrome

The solution to the scenario is (spoiler alert) to attach multiple locks.

Alice attaches her lock.

Alice sends the locked package to Bob.

Bob attaches his lock.

Bob sends the twice locked package to Alice.

Alice removes her lock.

Alice sends the package, locked with only Bob's lock, to Bob.

Bob removes his lock and opens the package.

----

The scheme you discussed is really similar to this, but I guess with one key difference; in the scheme you describe the locks themselves contain information and are hidden by a second lock.

I don't think there is a good extension to the solution I posted above, but it's as if when Bob attaches his lock it is hidden until Alice removes her lock, and at that point Alice only cares about what Bob's lock looks like.

I'd like to add that (IIUC) this scheme doesn't require Google to retain plaintext credentials or even password hashes. (They still might of course, but they don't have to.) If implemented as described in the linked paper, it only requires storing the hash of the combined username-password (in encrypted form). It's difficult to imagine a less useful form from the perspective of an adversary.

Regarding costs, the one-time hash performed on intake is indeed computationally expensive. However, for queries the only cryptographic operation required is a single elliptic curve computation (using secp224r1) on the hashed record sent by the client. Computationally, that should be in the same ballpark as establishing a single TLS connection.

The primary expense (detailed in the paper) is bandwidth, on account of sending out an entire hash bucket with each response. The analysis in the paper assumes a 2 byte prefix, but they're using 3 bytes here to reduce bandwidth at the expense of privacy; for every query made, they have to send back ~250 values instead of just one.

I don't agree with 1.

This "But Google's Password Checkup doesn't just use public sources" is infering that Google's db is bigger and better. You don't know and this is example of magic lotion marketing.

"Our magic lotion for hair grow is muuuuch better, as it have secret formula".

Actually I suspect that Troy's db as for now is better/bigger.

I guess I assumed the logic was that you take a sha256 of, say 32501257be4512a04a184fed989fd5e46cd4d30f6ef7c8d20d07d90f82e83aaf and say give me all entries from the 4B that begin with 325 (or end with aaf) which would take your 4B and divide it by 16 3 times giving you about 1M?

he told you, in the search console. Yo have to register your site and verificate it before you could appeal something.

There is no hardcoded whitelist. It's all based on the browser user's use of websites. See chrome://media-engagement/

It's not about how popular the website is, rather how video-centric it is.

Why even mention that?

Using Firefox makes a difference in many ways.

That said I wish Mozilla would allow other forms for income and just be honest about it (unlike Pocket which I think is a good idea destroyed by them being sneaky about it.)

Is there a widely supported alternative not already based on Blink or Webkit?

Do you see any other alternative than trust for such a system?

- Building a fully local system will not provide the same coverage and doesn't allow sharing findings across users (which means that when a new phishing page appears, it will appear as "new" for every single user, instead of being new for N users and then known bad for the rest of users). It also heavily reduces what kind of analysis can be done since you can't just store large datasets on every single device and/or run expensive algorithms on every single web page load on a mobile phone.

- Making it open source would not help. You can't know whether the code you can see is what is deployed remotely, so in the end you just end up trusting a different assertion instead (if you can't trust a privacy policy, why could you trust that the deployment is not backdoored?). It also has some significant cons: malware / phishing / abuse detection is in essence a cat-and-mouse game, and secrecy is unfortunately a key requirement in how everyone is building anti-abuse systems across the industry (not necessarily because they want to, but because nobody knows how it could work otherwise).

- You could even go all the way and have e.g. remote attestations, reproducible builds, etc. that allow proving that indeed the code running remotely is the open source code you want and can audit. This is barely doable with available technology these days, and even if someone was to do it there would maybe be 1K people on this planet able to understand why this is trustworthy. A prime example of this is looking at people in this very thread not understanding the differential privacy scheme for detecting compromised passwords.

Not trusting Google is a personal opinion, and I completely respect that. But implying that there is an alternative to trust for this kind of system is IMO misleading. Using DDG or Protonmail or any other service doesn't change the fact that you have to trust someone, it's just a different someone. You might personally believe their word more than Google's word, but if e.g. DDG started logging your identity and log requests and sell that to ad companies you would have very little way of learning about it either.

Disclaimer: I work for Google, not on Chrome, but I have worked on anti-abuse systems in the past.

Google does not have a very good record of maintaining their non-core projects.

> ... do not make it explicitly clear that the final solution sends a hash-prefixed password

I'm not sure if you're actually talking about something else, but the paper says: "Post-canonicalization, the server calculates a computationally expensive hash of both the canonical username and credential password... This 2-byte prefix—while leaking some bits of password material—provides the client with k-anonymity over the universe of all username and password pairs."

IOW, the 3-byte hash prefix sent is of the username and password concatenated. (Note that Google seems to have added another byte to the prefix versus the paper).