Google's Password Checkup Feature Coming To Android (zdnet.com) 34
Android users can now take advantage of the Password Checkup feature that Google first introduced in its Chrome web browser in late 2019, the OS maker announced today. From a report: On Android, the Password Checkup feature is now part of the "Autofill with Google" mechanism, which the OS uses to select text from a cache and fill in forms. The idea is that the Password Checkup feature will take passwords stored in the Android OS password manager and check them against a database containing billions of records from public data breaches and see if the password has been previously leaked online. If it has, a warning is shown to the user.
Re: Can I get that database of pwds? (Score:3, Insightful)
They probably presume it's only uploading the hashes.
As if rainbow tables & co weren't a thing. (If you get the hashes, you also get the salt.)
It's the LCN (large corporate nanny) delusion again. Where corporation automatically assume they themselves are to be blindly trusted, and that big nanny knows better what's good for you.
(Q: Hey, I trust me, so why don't you? | A: Because "you" is a 135,301 often badly paid multiple-personality-disorder entity that literally feeds on privacy?")
Re: (Score:2)
Re: (Score:2)
If they can decrypt the hash upload then you are screwed anyway, they can just intercept your passwords and cookies and the whole session when connecting to the target site anyway.
Ok, if the salt is long enough... (Score:2)
It may become urealistic to cache cracked hashes (Which is what I meant with "rainbow table". I didn't suggest downloading a SHA-512 rainbow table for 32 character password+salt combinations. ;).
But the argument that it is crazy to trust Google with this, still stands.
Then again, if you willingly (*willingly*! Not made-to-want-by-manipulative-PR!), "accept Google into your life", and make an account, with a password, then they already got your password, by definition. And hence full access to your phone's O
And thus put all your passwords online. (Score:2)
The idea is that the Password Checkup feature will take passwords stored in the Android OS password manager and check them against a database containing billions of records from public data breaches and see if the password has been previously leaked online.
Thus sending all your passwords to Google over a radio link. (After all, they're not going to send that whole database to your cellphone to be checked locally: It wouldn't fit and would eat your phone's data plan.)
What could POSSIBLY go wrong...
Re: (Score:2)
Re: (Score:2)
probably just hash value but even so there is now record of you having a password that is leaked, that could be dangerous info.
this propeller heads at google have no common sense, they make increasingly stupid decisions about UI, security, capabilities of apps. They need adult supervision.
Re:And thus put all your passwords online. (Score:4, Interesting)
probably just hash value ...
Which, to anyone with the database, is as good as the UNhashed value.
Now they know:
- Your phone address,
- That you used THIS password (somewhere) on it.
You're no longer an anonymous cellphone in a sea of cellphones that MIGHT have used one of the terrabytes of "weak/broken" passwords. They no longer have to try everything in the database against all your accounts. Just try THAT password against everything they can find that you might use - it will open SOME door.
Re: (Score:2)
More seriously, you realistically just need a local database (or just a plaintext list really) of the top 10,000 or so terrible passwords that should never be used and an online database that contains a list of credentials that have been compromised. Odds are that someone else has probably used the same password that you have for some other account which was breached, but why anyone w
Re: (Score:3)
I wonder if there's a method that could be used so that the password isn't sent in plain-text over an insecure connection.
Even if the transport can't be cracked, Google now has the fact that you used that particular password from the giant database. Even if they don't log it in that or another database, the data is there at least temporarily. In addition to Google itself, if some threat actor has infiltrated their servers it's there to grab.
However, now you also have the passwords (or a token identifying
Re: (Score:2)
What could POSSIBLY go wrong...
Probably far less than actually is going wrong by people having their passwords leaked online through breaches and reused.
Re: (Score:2)
The purpose of this is to make sure people are not using the leaked password.
The lesson from Apple is you have to have to balance threat and alarm blindness. You have to balance information and the fact that some just do not care.
Re: (Score:2)
This is exactly what I want password manager to do (Score:3, Funny)
Re: (Score:2)
It only sends hashes.
Re:This is exactly what I want password manager to (Score:5, Interesting)
If it sends full hashes, i.e. enough information to identify a single password, it's doing it wrong. It should only send a very short hash or a small part of a bigger hash, have the full hashes which match that short hash returned from the database and locally compare the full hash against the returned list of hashes. That way the information sent over the internet is not enough to identify an individual password. Even if there is only one password matching the short hash in the breach database, the user could have a completely different password. This protocol does not allow an observer to conclude that a client has found a match in the password leak database, because the final comparison can still fail if matches are returned. This is how HaveIBeenPwned checks for leaked passwords. [troyhunt.com]
Re:This is exactly what I want password manager to (Score:4, Informative)
That is indeed what it does, and the system is based on the work of HaveIBeenPwned. Google worked with Troy Hunt as I recall.
Re: (Score:2)
It should only send a very short hash or a small part of a bigger hash, have the full hashes which match that short hash returned from the database and locally compare the full hash against the returned list of hashes.
Down side: A bad guy hearing both halves of the exchange gets a small set of full hashes which contains the password IF there's a match.
Now, presuming he also has the database, he can look up the/a corresponding password for each of the (necessarily) small set of maybe-matches. This gives hi
Re: (Score:2)
Yes, please take my plaintext password, send it as a part of query to an external database to see if it was leaked before. If it was leaked before, notify the user. If it was not leaked before, notify the user it is about to be leaked as the result of this check.
Oh look, someone who knows nothing about the topic has commented! Outstanding! I suppose you think I can still use a 45 MHz VFO radio to listen to your cell phone conversations, too?
Re: (Score:1)
does it check usernames or actual passwords ? (Score:2)
It'd be nice if Apple ported theirs to macOS (Score:2)
There's something similar on iOS' built-in password manager, but for some reason at Apple macOS has become the bastard child and a lot of the useful iOS features only make it over only years later.
Re: It'd be nice if Apple ported theirs to macOS (Score:2)
It is available on macOS: go in to the preferences in Safari
Re: (Score:2)
Missed that somehow (was expecting it in Keychain Access) - thanks!
I Wish More People Understood This Feature (Score:2)
Re: (Score:2)
Unless your site stores personal data (Sorry name and email don't count for this, not that you are getting my name) then it has no reason to have a password and I will continue to use the compromised ones.
Sites that need passwords use 2FA anyway. Stop making me have pointless accounts to exploit me.
Re: (Score:2)
and I will continue to use the compromised ones.
Fine with me. Just don't claim that Chrome told you my site was hacked.
Re: (Score:2)
The problem is there is no good 2FA system that exists and is widely available.
how this works (Score:1)
Re: (Score:1)
Was the article stealth-edited? Or did no one RTFA (Score:2)
Why the hell is every single comment here speculating about how this is done when the article plainly says that only the first two bytes of the password are uploaded, and then if there is a match the full hash is compared locally on the phone without sending the answer to Google. Mind you, I'm sure collisions are more rare than positives—Google can probably infer that if the first two bytes match then a user has been pwned—but if it's positive than everyone else has your password anyway.
Did any