yasdary greatness leonirez
Danny Hosford
From what I read so far Google "Chrome Password Checkup" extension ( -checkup/pncabnpcffmalkkjpajodfhijclecjno) checking the password that you use for login (regardless it saved in chrome or not) with known data breaches databases that available online.based on google explanation it's also used for google services passwords even without "Chrome Password Checkup" extensions.
Now answering your question, "how good is "Chrome password checker "comparing to other similar programs like haveibeenpwned.com or "dark web" checking credit report subscriptions etc.". Google Chrome Password Check-up fares worse compared to the likes of HIBP, Firefox Monitor, etc... Here's why I came to that conclusion
On February 5th, for Safer Internet Day, our team launched its first public-facing system, called Password Checkup. Password checkup allows users to check, in a privacy-preserving manner, whether their username and password matches one of the more than 4B+ credentials exposed by third-party data breaches of which Google is aware. This launch success vastly exceeded our wildest expectations, with over 650,000 users installing our chrome extension in the first three weeks following the release.
Accounts which are exposed via data breach are 11.6 times more likely to be compromised, in part because many Internet users reuse the same credentials on multiple sites. Password Checkup help users mitigate this threat through a one-click, install and forget Chrome extension that warns them at login time if the username/password used for that site was publicly exposed in a breach (as shown above).
Proactive breached password reset is just one layer of Google defenses but an important one, because without it Google accounts exposed in third-party breaches would be 11.6 times more likely to be compromised. Over the last two years alone we were able to proactively re-secure over 110M accounts that had their passwords exposed in a breach.
Given the scale and effectiveness of proactively resetting passwords at Google it was clear that users would benefit of such protection across the Internet. This is why we started researching how to empower users to be notified in case any of their credentials was breached regardless of the site they were used for so they can reset them.
Drawing inspiration from the widely successful Safe Browsing malware and phishing API, we started researching how to develop a somewhat similar API to check for compromised passwords back in 2017. Talking to the Safe Browsing team and doing user research quickly led us to understand that if we were to be successful, we needed to create something that had a very clear value and a single purpose, and be privacy preserving. This section discusses the design decisions we made to achieve this objective.
Having zero configuration means that we had to err on the cautious side and offer very strong privacy guarantees by default. While I am sure this was the right decision for our initial release, it has the serious downside that Password Checkup does not work on mobiles as it consumes too much resources (network, CPU, RAM). Moving forward there are tradeoffs, discussed in the protocol description section, that can be made if we later decide to bring Password Checkup to low-power devices.
Actionable information: Warning fatigue is a real problem, and leads users to ignore important messages. To avoid exhausting our users, we decided that the API will report a match only when the exact credentials are in a data breach.
Keep it focused: As a corollary to the previous design choice, while having a strong password is important, we decided against covering this use-case as it is not as clear-cut as telling users their credentials are breached, and that they are in immediate danger. We felt that covering this use-case (and a related one) would dilute the message.
Release early: The protocol security and privacy rely on making the right tradeoffs in terms of what is shared (anonymous dataset size), how much computation is required, and what information is retrieved. There is no perfect answer and the right balance for those tradeoffs requires a conversation with the security community. This is why we decided to go with on an early release of an experimental Chrome extension, to get the much-needed feedback.
Argon2: The slow hashing function Argon2 is used to prevent hackers brute-forcing the API, and to protect passwords at rest along with encryption. Argon2 was selected because it allows us to finely tune the computational cost required to protect against CPU bruteforce and the memory used to prevent GPU brute force independently.
Canonicalization: We normalize usernames to dedup the credentials and address the fact that sites use either the full email address or a username. This is done by lowercasing the username and stripping any email provider information. For example us...@gmail.com becomes user1.
Blinding: Each of the hashed credentials is then blinded with a 224-bit secret key b by mapping the hash to the elliptic curve NID_secp224r1 and raising the resulting point to the power b. Blinding is mostly used to ensure requester anonymity and password secrecy via private set intersection, as detailed in the next section. The private set intersection protocol also serves as an additional layer of defense in the event that the Password Checkup database is breached.
Sharding: We use the first two bytes of the (unblinded) hashed credentials as sharding keys, to partition the database into evenly distributed buckets of randomly distributed hashed/blinded credentials. Sharding on the hashed credentials ensures client k-anonymity over all the valid credentials in the universe, because by construction as a cryptographic hash function is not invertible and leaks no statistical information about the data that was hashed. As a result, no-one knows or can infer which credentials will be hashed to a given prefix unless they know the credentials and hash them themselves, which is a very slow process thanks to Argon2.
In practice, this tradeoff maintains a strong user k-anonymity while making the protocol practical by reducing the computation and network traffic to something reasonable, at least for desktops; the client still has to download 1MB for each lookup, which is already too much for a mobile. This is why increasing the k-anonymity by using a single byte prefix is possible in practice, and we believe that two bytes is the best possible balance between strong privacy and network usage.
Overall, Password Checkup, including its cryptography, is fully implemented in WebASM/Javascript both on the client side and server side. On the server side we use the public Google Cloud stack, including Firebase cloud function, BigQuery and Cloud Storage. The Argon2 implementation is based on libsodium and we use a transpiled version of OpenSSL in web assembly.
Overall, as reported in the table above, it takes a median time of 8.6 seconds for a client to perform a lookup according to our anonymous telemetry. Half of this time is spent performing the Argon2 hashing, while the rest is mostly spent downloading data. This clearly shows that increasing the size of the shards or computation difficulty would be problematic for performance.
Besides allowing us to check that Password Checkup behaves correctly in the wild, the most important lesson we have learned from the telemetry so far is that we must add to the extension an in-page form detection. This is because some popular sites, mainly in China, hash the password on the client side in javascript before sending it, which causes the extension not to work in those cases. This is a very important finding, that we are actively investigating, as some of the largest data breaches mostly affect Chinese users and are actively weaponized by cyber-criminals.
The answer is yes! Of the 6M credentials checked every week, 85k of them are detected as compromised (1.8%) and users reset about 25% of those. Moreover, 94% of the new passwords are as strong or stronger than the compromised one, as can be seen in the chart above. It shows the strength of the compromised password and the strength of the new password, according to Password Checkup anonymous telemetry that reports the strength scores given by the strength meter embedded in the extension (zxcvbn) upon password change.
This quest for simplicity explains why, in my view, the main challenge we overcame was not the technical implementation (even though the crypto is clearly complex) but how to provide the best possible user experience to our users. It took many iterations to get this experience right and we axed many features along the way in order to make the system as simple as we wanted it to be.
Password Checkup is far from perfect and there is a lot to do before it reaches its full potential. Hopefully, one day passwords will be a thing of the past, but until then proactively resetting compromised credentials will remain an important defense that users need.
How secure are your passwords? You probably know that you should create strong passwords and never re-use them across different websites and services. If you store passwords in Chrome on the desktop you may know that your browser has a password checkup tool built in. Google has now added the Password Checkup tool to Android as well.
Google's Password Checkup is built into your Android phone as long as you are running Android 9 or higher, and it is built into the Autofill with Google settings, which means if you are using a different service to autofill passwords (such as Dashlane or Bitwarden) it won't work.
The Password Checkup is designed to keep you safe by comparing your stored passwords against an online database of known data breaches and exposed passwords. Whenever you enter or save a password, it tests your entry and if a match is found, your phone will show you a warning and advise you to change the password. You can also manually review all your stored passwords and perform a password checkup as well.
c01484d022