Google uploading your plain text passwords
Howdy, My gmail account prompted me today to change a compromised password. It wasn't compromised; it was an offline system where I intentionally used a generic password. But in the process... It turns out that every password I allowed Chrome on Android to remember, it uploaded to Google. In plain text!! And it could prove it by displaying the plain text passwords for me on my laptop. And I can't turn the upload off! To the google folks on here: Are you INSANE!? Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
That's wrong, you CAN turn it off. I believe it's encrypted between Google and your Chrome browser, it says so but I haven't confirmed this myself. Chrome Settings, Password, disable "Offer to save passwords" Josh Luthman 24/7 Help Desk: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Jun 11, 2021 at 12:03 PM William Herrin <bill@herrin.us> wrote:
Howdy,
My gmail account prompted me today to change a compromised password. It wasn't compromised; it was an offline system where I intentionally used a generic password. But in the process...
It turns out that every password I allowed Chrome on Android to remember, it uploaded to Google. In plain text!! And it could prove it by displaying the plain text passwords for me on my laptop. And I can't turn the upload off!
To the google folks on here: Are you INSANE!?
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Fri, Jun 11, 2021 at 9:06 AM Josh Luthman <josh@imaginenetworksllc.com> wrote:
That's wrong, you CAN turn it off. I believe it's encrypted between Google and your Chrome browser, it says so but I haven't confirmed this myself.
Chrome can be configured to not remember passwords at all (makes a browser pretty useless), but it won't keep them only on the local device. If allowed to remember passwords, it uploads them to Google. No knob to turn sync off. -Bill -- William Herrin bill@herrin.us https://bill.herrin.us/
Disable "auto sign-in" and "Save and fill addresses" and there's more for payment methods, too. Josh Luthman 24/7 Help Desk: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Fri, Jun 11, 2021 at 12:12 PM William Herrin <bill@herrin.us> wrote:
On Fri, Jun 11, 2021 at 9:06 AM Josh Luthman <josh@imaginenetworksllc.com> wrote:
That's wrong, you CAN turn it off. I believe it's encrypted between Google and your Chrome browser, it says so but I haven't confirmed this myself.
Chrome can be configured to not remember passwords at all (makes a browser pretty useless), but it won't keep them only on the local device. If allowed to remember passwords, it uploads them to Google. No knob to turn sync off.
-Bill
-- William Herrin bill@herrin.us https://bill.herrin.us/
Hi, I use Firefox and saved its profile inside a VeraCrypt disk, inside a Bitlocked disk, inside a Surface3 used only for that purpose =D. ( Yeah that include a few physical MFA device and Shutdown instead of Sleeping, and yadi yada ) So GL with Chrome =D. ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 6/11/21 12:12 PM, William Herrin wrote:
On Fri, Jun 11, 2021 at 9:06 AM Josh Luthman <josh@imaginenetworksllc.com> wrote:
That's wrong, you CAN turn it off. I believe it's encrypted between Google and your Chrome browser, it says so but I haven't confirmed this myself. Chrome can be configured to not remember passwords at all (makes a browser pretty useless), but it won't keep them only on the local device. If allowed to remember passwords, it uploads them to Google. No knob to turn sync off.
-Bill
William Herrin <bill@herrin.us> wrote:
It turns out that every password I allowed Chrome on Android to remember, it uploaded to Google. In plain text!!
Chrome does not store your passwords in plain text. It encrypts them locally, on e.g. macOS using, I think, a secret stored in the keychain under "Chrome Safe Storage", on Windows using a similar API and secret probably unlocked via your login credentials. If you use your favorite internet search engine to look for "how does Chrome store passwords", you'll find the local sqlite file and more detailed explanations. -Jan
On Fri, Jun 11, 2021 at 9:38 AM Jan Schaumann via NANOG <nanog@nanog.org> wrote:
William Herrin <bill@herrin.us> wrote:
It turns out that every password I allowed Chrome on Android to remember, it uploaded to Google. In plain text!!
Chrome does not store your passwords in plain text. It encrypts them locally, on e.g. macOS using, I think, a secret stored in the keychain under "Chrome Safe Storage", on Windows using a similar API and secret probably unlocked via your login credentials.
Hi Jan, I'm fine with Chrome encrypting them locally. That's what I want it to do. I'm not at all fine with it uploading them to my Google account. I don't want any trace of my non-google passwords present in my google account. I'm very very not fine that it happened behind my back without my express consent. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
I think you have only found the tip of the iceberg of things that Chrome and Google does without your express consent. On Fri, Jun 11, 2021 at 9:48 AM William Herrin <bill@herrin.us> wrote:
On Fri, Jun 11, 2021 at 9:38 AM Jan Schaumann via NANOG <nanog@nanog.org> wrote:
William Herrin <bill@herrin.us> wrote:
It turns out that every password I allowed Chrome on Android to remember, it uploaded to Google. In plain text!!
Chrome does not store your passwords in plain text. It encrypts them locally, on e.g. macOS using, I think, a secret stored in the keychain under "Chrome Safe Storage", on Windows using a similar API and secret probably unlocked via your login credentials.
Hi Jan,
I'm fine with Chrome encrypting them locally. That's what I want it to do. I'm not at all fine with it uploading them to my Google account. I don't want any trace of my non-google passwords present in my google account. I'm very very not fine that it happened behind my back without my express consent.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
Google stores encrypted passwords. By default it uses your own Google Account password as part of the key to decrypt your other synced passwords. But you can change that and use a custom "sync passphrase". Once you're logged in your device can decrypt your passwords and compare them against databases of known compromised passwords. Google does not have access to your plain-text passwords in either case. More info: https://support.google.com/accounts/answer/6208650 https://security.googleblog.com/2020/10/new-password-protections-and-more-in... Regards, César On Fri, Jun 11, 2021 at 1:05 PM William Herrin <bill@herrin.us> wrote:
Howdy,
My gmail account prompted me today to change a compromised password. It wasn't compromised; it was an offline system where I intentionally used a generic password. But in the process...
It turns out that every password I allowed Chrome on Android to remember, it uploaded to Google. In plain text!! And it could prove it by displaying the plain text passwords for me on my laptop. And I can't turn the upload off!
To the google folks on here: Are you INSANE!?
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Fri, Jun 11, 2021 at 9:42 AM César de Tassis Filho <ctassisf@gmail.com> wrote:
Google does not have access to your plain-text passwords in either case.
If they can display the plain text passwords to me on my screen in a non-Google web browser then they have access to my plain text passwords. Everything else is semantics. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
It appears that William Herrin <bill@herrin.us> said:
On Fri, Jun 11, 2021 at 9:42 AM César de Tassis Filho <ctassisf@gmail.com> wrote:
Google does not have access to your plain-text passwords in either case.
If they can display the plain text passwords to me on my screen in a non-Google web browser then they have access to my plain text passwords. Everything else is semantics.
I tried it in Firefox. I can log into my Google account with my Google password and see the saved passwords but unless Firefox is doing some impressively sophisticated content snooping, it can't do anything with them. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[sorry meant to send this to the list] Isn't that what lots of password managers do? I understand that one of them syncs point to point, but that has the downside that it probably needs to be on the same subnet. The actual problem here is that sites only allow a single password. if you could enroll more than one password you wouldn't need to sync at all. Better: use asymmetric keys and enroll public keys so the secret never leaves your device. Mike On Fri, Jun 11, 2021 at 9:53 AM William Herrin <bill@herrin.us> wrote:
On Fri, Jun 11, 2021 at 9:42 AM César de Tassis Filho <ctassisf@gmail.com> wrote:
Google does not have access to your plain-text passwords in either case.
If they can display the plain text passwords to me on my screen in a non-Google web browser then they have access to my plain text passwords. Everything else is semantics.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Fri, Jun 11, 2021 at 10:27 AM Michael Thomas <mike@mtcc.com> wrote:
Isn't that what lots of password managers do? I understand that one of them syncs point to point, but that has the downside that it probably needs to be on the same subnet.
It's exactly what lots of password managers with browser extensions do. I don't personally use them because I don't want my passwords reversibly stored on a computer that I don't directly control. I have no great philosophical problem with their existence and use by those who want them, I just don't want them for myself. My problem was suddenly finding Google in possession of passwords I never intentionally allowed it to have. This sneak around behind my back stuff means I wasn't in control of my passwords. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On Fri, Jun 11, 2021 at 12:01 PM William Herrin <bill@herrin.us> wrote:
Isn't that what lots of password managers do? I understand that one of
On Fri, Jun 11, 2021 at 10:27 AM Michael Thomas <mike@mtcc.com> wrote: them syncs point to point, but that has the downside that it probably needs to be on the same subnet.
It's exactly what lots of password managers with browser extensions do. I don't personally use them because I don't want my passwords reversibly stored on a computer that I don't directly control. I have no great philosophical problem with their existence and use by those who want them, I just don't want them for myself.
Well, browser extensions in and of themselves scare the living hell out of me. It really surprises me that they aren't a major attack vector and in the news all of the time. But yes, I agree that even encrypted they are a *very* tempting target for hackers, and especially foreign governments. A breach would mean that everybody is instantly screwed since they don't have to break into individual computers, install malware, etc. Mike
On Fri, 11 Jun 2021, William Herrin wrote:
On Fri, Jun 11, 2021 at 9:42 AM César de Tassis Filho <ctassisf@gmail.com> wrote:
Google does not have access to your plain-text passwords in either case.
If they can display the plain text passwords to me on my screen in a non-Google web browser then they have access to my plain text passwords. Everything else is semantics.
Untrue. If you have a key on your computer, such as was mentioned that the Google key may be stored locally in the MacOS Keychain, and you unlock your MacOS Keychain with your local laptop login password, which is also stored on an encrypted disk volume, that does not mean those passwords have left your computer in plain text, or that Google has this key that lives in your keychain. I agree, if they do, that's terrible. But I haven't seen any evidence that they do. You can have multiple keys to encrypted data, and it is still stored in a cryptographically secure way, assuming it is implemented well, despite those multiple keys having the ability to decrypt your data. I use 1Password. There are multiple keys that can unlock the other key that can unlock my encrypted data. But just because I can see my passwords in the app, and that there is a mechanism/code that can do the same without the 1Password app to unlock and view my data, this does not mean that 1Password has my keys, nor access to all my passwords. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
On Fri, Jun 11, 2021 at 12:32 PM Peter Beckman <beckman@angryox.com> wrote:
On Fri, 11 Jun 2021, William Herrin wrote:
On Fri, Jun 11, 2021 at 9:42 AM César de Tassis Filho <ctassisf@gmail.com> wrote:
Google does not have access to your plain-text passwords in either case.
If they can display the plain text passwords to me on my screen in a non-Google web browser then they have access to my plain text passwords. Everything else is semantics.
Untrue. If you have a key on your computer, such as was mentioned that the Google key may be stored locally in the MacOS Keychain, and you unlock your MacOS Keychain with your local laptop login password, which is also stored on an encrypted disk volume, that does not mean those passwords have left your computer in plain text, or that Google has this key that lives in your keychain.
I agree, if they do, that's terrible. But I haven't seen any evidence that they do.
However, if the password is entered on one device (Android device, for example, as mentioned in the original post), and then is visible in clear-text on a different browser on a different device (laptop, for example, again, from the original post), then clearly the password has left the original device in a form which is reversible to the original clear text. You can argue that it may be stored "in the cloud" in encrypted form; but it's clearly being stored in a manner which can be reversed to gain access to the original clear text, and using a key which is known to both devices involved, and to the cloud system validating that authentication. This isn't about seeing the passwords in clear text on the same device upon which they were entered; this is about a *separate* device having visible access to the clear text of a password that was not entered via that device. If the laptop had required Bill to enter a decryption key first in order to see the clear text, and that decryption key was one he had manually configured on both devices, stored only locally on each device, then you might be able to argue that the cloud never has visibility into the passwords; but if the keys are encrypted using a gmail login credential, which is itself stored and verified within the same cloud environment as the encrypted password strings it is protecting, then your two factor security has collapsed back down into a single point of compromise; compromise the google password, and you have access to all the passwords that were uploaded and stored in the system unbeknownst to the user. That's the part that would leave me concerned. Having my email password compromised? That's a bit of a "meh" moment. Suddenly discovering that one password now gave access to potentially all my financial accounts as well? That's a wake up in the night with cold sweats moment. :( Matt
Google uses your Google Account's password to encrypt passwords synced to the cloud. That is why passwords saved on Android and synced to the cloud can be read elsewhere (including passwords.google.com). As I mentioned before, if you want to avoid this behavior Google offers you a way to use a different sync passphrase (which inhibits access to passwords.google.com and also disables other features). Instructions here: https://support.google.com/chrome/answer/165139#passphrase César On Fri, Jun 11, 2021 at 4:50 PM Matthew Petach <mpetach@netflight.com> wrote:
On Fri, Jun 11, 2021 at 12:32 PM Peter Beckman <beckman@angryox.com> wrote:
On Fri, 11 Jun 2021, William Herrin wrote:
On Fri, Jun 11, 2021 at 9:42 AM César de Tassis Filho <ctassisf@gmail.com> wrote:
Google does not have access to your plain-text passwords in either case.
If they can display the plain text passwords to me on my screen in a non-Google web browser then they have access to my plain text passwords. Everything else is semantics.
Untrue. If you have a key on your computer, such as was mentioned that the Google key may be stored locally in the MacOS Keychain, and you unlock your MacOS Keychain with your local laptop login password, which is also stored on an encrypted disk volume, that does not mean those passwords have left your computer in plain text, or that Google has this key that lives in your keychain.
I agree, if they do, that's terrible. But I haven't seen any evidence that they do.
However, if the password is entered on one device (Android device, for example, as mentioned in the original post), and then is visible in clear-text on a different browser on a different device (laptop, for example, again, from the original post), then clearly the password has left the original device in a form which is reversible to the original clear text. You can argue that it may be stored "in the cloud" in encrypted form; but it's clearly being stored in a manner which can be reversed to gain access to the original clear text, and using a key which is known to both devices involved, and to the cloud system validating that authentication.
This isn't about seeing the passwords in clear text on the same device upon which they were entered; this is about a *separate* device having visible access to the clear text of a password that was not entered via that device.
If the laptop had required Bill to enter a decryption key first in order to see the clear text, and that decryption key was one he had manually configured on both devices, stored only locally on each device, then you might be able to argue that the cloud never has visibility into the passwords; but if the keys are encrypted using a gmail login credential, which is itself stored and verified within the same cloud environment as the encrypted password strings it is protecting, then your two factor security has collapsed back down into a single point of compromise; compromise the google password, and you have access to all the passwords that were uploaded and stored in the system unbeknownst to the user.
That's the part that would leave me concerned. Having my email password compromised? That's a bit of a "meh" moment. Suddenly discovering that one password now gave access to potentially all my financial accounts as well? That's a wake up in the night with cold sweats moment. :(
Matt
On Fri, Jun 11, 2021 at 1:05 PM César de Tassis Filho <ctassisf@gmail.com> wrote:
Google uses your Google Account's password to encrypt passwords synced to the cloud. That is why passwords saved on Android and synced to the cloud can be read elsewhere (including passwords.google.com).
As I mentioned before, if you want to avoid this behavior Google offers you a way to use a different sync passphrase (which inhibits access to passwords.google.com and also disables other features). Instructions here: https://support.google.com/chrome/answer/165139#passphrase
Hi César , This would be fine had I intended this behavior. That it magically happened because I told my phone it could sync my gmail is very very disturbing. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
On Fri, Jun 11, 2021 at 12:48 PM Matthew Petach <mpetach@netflight.com> wrote:
That's the part that would leave me concerned. Having my email password compromised? That's a bit of a "meh" moment. Suddenly discovering that one password now gave access to potentially all my financial accounts as well? That's a wake up in the night with cold sweats moment. :(
Just a note about security threat modeling: your email password can generally be used to reset all your other passwords, so actually having your email password compromised is one of the most terrifying situations of all. Unless, of course, you use a security key with gmail, in which case compromise of your password may not get the attacker very far. ;) The Chrome password manager is convenient, and the sync can be incredibly handy (I can sign into stuff on different computers or even my phone without needing to copy over the passwords), but you might consider leaving your highest-value passwords out of that system, or really any system. Personally, my financial passwords are not known by Chrome, myself, or even my password manager. (Yes, you heard that right -- no single entity knows the passwords. How? By using a simple secret-splitting scheme -- I memorize part of the password, and my password manager stores the rest.) Damian
On 12/06/2021 08:31, Damian Menscher via NANOG wrote:
The Chrome password manager is convenient, and the sync can be incredibly handy (I can sign into stuff on different computers or even my phone without needing to copy over the passwords), but you might consider leaving your highest-value passwords out of that system, or really any system. Personally, my financial passwords are not known by Chrome, myself, or even my password manager. (Yes, you heard that right -- no single entity knows the passwords. How? By using a simple secret-splitting scheme -- I memorize part of the password, and my password manager stores the rest.)
Or: https://doubleoctopus.com/ -Hank
Damian
On Fri, Jun 11, 2021 at 12:51 PM Matthew Petach <mpetach@netflight.com> wrote:
Having my email password compromised? That's a bit of a "meh" moment. Suddenly discovering that one password now gave access to potentially all my financial accounts as well? That's a wake up in the night with cold sweats moment. :(
Thanks for articulating the issue so well. And glad I saw this discussion because I had no idea that if my gmail account was compromised all my financial accounts would become accessible. The issue is discussed quite nicely here: https://www.howtogeek.com/174312/can-google-employees-see-my-saved-google-ch...
Encryption != plain text, just because it's not a hash doesn't mean it's problematic (if done correctly). This is the exact same method that every single password management system uses and all are far better for the average user than trying to reuse a single password or write them down. Scott Helms On Fri, Jun 11, 2021 at 12:53 PM William Herrin <bill@herrin.us> wrote:
On Fri, Jun 11, 2021 at 9:42 AM César de Tassis Filho <ctassisf@gmail.com> wrote:
Google does not have access to your plain-text passwords in either case.
If they can display the plain text passwords to me on my screen in a non-Google web browser then they have access to my plain text passwords. Everything else is semantics.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Sat, Jun 12, 2021 at 5:11 AM K. Scott Helms <kscott.helms@gmail.com> wrote:
Encryption != plain text, just because it's not a hash doesn't mean it's problematic (if done correctly).
Scott, Google's computer is able to compose an html document which contains my passwords in plain text. Whatever dance they do to either side of that point in their process, at that point they possess my passwords in plain text. Why is this concept a mystery to anyone?
This is the exact same method that every single password management system uses and all are far better for the average user than trying to reuse a single password or write them down.
If I had authorized it, it would indeed be just like any other password managing web site. I did not knowingly authorize it. They snuck it on me. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
They snuck it on me.
"I didn't notice this until now" != "They snuck one by the goalie." On Sat, Jun 12, 2021 at 10:30 AM William Herrin <bill@herrin.us> wrote:
Encryption != plain text, just because it's not a hash doesn't mean it's
On Sat, Jun 12, 2021 at 5:11 AM K. Scott Helms <kscott.helms@gmail.com> wrote: problematic (if done correctly).
Scott, Google's computer is able to compose an html document which contains my passwords in plain text. Whatever dance they do to either side of that point in their process, at that point they possess my passwords in plain text. Why is this concept a mystery to anyone?
This is the exact same method that every single password management system uses and all are far better for the average user than trying to reuse a single password or write them down.
If I had authorized it, it would indeed be just like any other password managing web site. I did not knowingly authorize it. They snuck it on me.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Sat, Jun 12, 2021 at 1:21 PM Tom Beecher <beecher@beecher.cc> wrote:
They
snuck it on me.
"I didn't notice this until now" != "They snuck one by the goalie."
actually, i was wondering while reading this thread... (I mean this for clarity sake, not in a 'blame the victim' sort of way" "Did William think that password data, which had to be in plaintext to auto-fill forms/etc, was stored on the local device(s) only?" I suppose some scheme like: 1) keep local copies in hashed/encrypted store 2) upload said store to 'cloud' periodically (on change?) 3) download on new device / clear-all-browser-data events If the hashed pile of data is 'simply' encrypted with 'gmail/google account password' (or that and some token from 'cloud') and decrypted in some form of javascript functions... Then only the local browser really knows the content of the hash-file, right? NOTE: I have no idea how chrome does it's thing here... but I expect the code is visible on chromium.org ? Perhaps even here: https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/pass... would be a good place to go digging into the code / hows / whys / where-fores ?
On Sat, Jun 12, 2021 at 10:30 AM William Herrin <bill@herrin.us> wrote:
On Sat, Jun 12, 2021 at 5:11 AM K. Scott Helms <kscott.helms@gmail.com> wrote:
Encryption != plain text, just because it's not a hash doesn't mean it's problematic (if done correctly).
Scott, Google's computer is able to compose an html document which contains my passwords in plain text. Whatever dance they do to either side of that point in their process, at that point they possess my passwords in plain text. Why is this concept a mystery to anyone?
This is the exact same method that every single password management system uses and all are far better for the average user than trying to reuse a single password or write them down.
If I had authorized it, it would indeed be just like any other password managing web site. I did not knowingly authorize it. They snuck it on me.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Sat, Jun 12, 2021 at 1:31 PM Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Sat, Jun 12, 2021 at 1:21 PM Tom Beecher <beecher@beecher.cc> wrote:
They
snuck it on me.
"I didn't notice this until now" != "They snuck one by the goalie."
actually, i was wondering while reading this thread... (I mean this for clarity sake, not in a 'blame the victim' sort of way"
"Did William think that password data, which had to be in plaintext to auto-fill forms/etc, was stored on the local device(s) only?"
I suppose some scheme like: 1) keep local copies in hashed/encrypted store 2) upload said store to 'cloud' periodically (on change?) 3) download on new device / clear-all-browser-data events
If the hashed pile of data is 'simply' encrypted with 'gmail/google account password' (or that and some token from 'cloud') and decrypted in some form of javascript functions...
Then only the local browser really knows the content of the hash-file, right? NOTE: I have no idea how chrome does it's thing here... but I expect the code is visible on chromium.org ? Perhaps even here:
https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/pass...
would be a good place to go digging into the code / hows / whys / where-fores ?
The source.chromium site is neat, this query, for instance, finds where ' passwords.google.com' is in the code tree: https://source.chromium.org/search?q=passwords.google.com&sq=&ss=chromium%2Fchromium%2Fsrc:chrome%2Fbrowser%2Fpassword_manager%2F as a method to help track down the wherefores...
On Sat, Jun 12, 2021 at 10:30 AM William Herrin <bill@herrin.us> wrote:
On Sat, Jun 12, 2021 at 5:11 AM K. Scott Helms <kscott.helms@gmail.com> wrote:
Encryption != plain text, just because it's not a hash doesn't mean it's problematic (if done correctly).
Scott, Google's computer is able to compose an html document which contains my passwords in plain text. Whatever dance they do to either side of that point in their process, at that point they possess my passwords in plain text. Why is this concept a mystery to anyone?
This is the exact same method that every single password management system uses and all are far better for the average user than trying to reuse a single password or write them down.
If I had authorized it, it would indeed be just like any other password managing web site. I did not knowingly authorize it. They snuck it on me.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Sat, Jun 12, 2021 at 12:33 PM Christopher Morrow <morrowc.lists@gmail.com> wrote:
[....] If the hashed pile of data is 'simply' encrypted with 'gmail/google account password' (or that and some token from 'cloud') and decrypted in some form of javascript functions... Then only the local browser really knows the content of the hash-file, right?
It seems that in this case, anyone who has any way of knowing the content of the 'gmail/google account password' can know the content of the hash-file. Can you show that their servers don't also record anybody's account password or keys derived from it? If you login to their services, then you directly send them the necessary piece of information to create that record, and often, so even If they don't retain the browser account password in plaintext... there are still ways for them to discover what that is: by adjusting their login process at a later date to store some extra info. on successful login, they would not even need to brute force whatever hashing scheme they use to protect passwords. This could be more expedient to them "for Support purposes" if they later find many users Ask for help recovering their password vaults from a forgotten account password - saving a copy might be more convenient for their support than not saving a copy of keys. If they don't store the key today in a way accessible to them, then it's most likely 1 minor code change to some of their server(s) to mke and save a copy of that key derived from the authentication password on the server side you just auth'd against, at some point Such change could be made happen at any time, or intermittently, and since it's code that would reside entirely on the servers, there would be no possible means on the client of detecting that the server's now keeping a copy of a login hash: when you just filled out the login form in your web browser, etc. Doesn't matter whether that would be a deliberate update in the future due to a change in priorities and policies by management, Or some rogue/misguided dev trying to solve a problem, or an actual malicious actor; the result is the same -- They would have no obligation to tell people that they're now saving the key; the servers can in theory possess both the data and the keys used to decrypt it both pieces of info pass through systems completely administered by the same provider at some point. The end user has no visibility and lacks so much as a contract they would breach by deploying the update.
NOTE: I have no idea how chrome does it's thing here... but I expect the code is visible on chromium.org ? Perhaps even here: -- -Jim
Jim, I'd direct you to the bottom of my 1st message that says: "I have no idea how this works, but..." On Sat, Jun 12, 2021 at 2:35 PM Jim <mysidia@gmail.com> wrote:
NOTE: I have no idea how chrome does it's thing here... but I expect the code is visible on chromium.org ? Perhaps even here:
-chris
On Sat, Jun 12, 2021 at 10:36 AM Max Harmony via NANOG <nanog@nanog.org> wrote:
On 12 Jun 2021, at 10.29, William Herrin <bill@herrin.us> wrote:
They snuck it on me.
By hiding it right on the "browser features" page?
By silenting defaulting it to enabled, damn right. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Scott, Google's computer is able to compose an html document which contains my passwords in plain text. Whatever dance they do to either side of that point in their process, at that point they possess my passwords in plain text. Why is this concept a mystery to anyone? Because it's wrong, they don't have your passwords you do (more accurately your device does). They don't combine the decryption keys with the encrypted data, your device does. This is the case whenever something is encrypted rather than hashed. It's literally impossible to provide a password saving mechanism that hashes the credentials. If I had authorized it, it would indeed be just like any other password managing web site. I did not knowingly authorize it. They snuck it on me. You did authorize, you just didn't read the fine print. Having said that, this part of your complaint is definitely the one that has the most merit IMO since if you enable it on mobile it directs you to a web page that you can't see at that time. If you're concerned then I'd recommend setting a synch phrase, which makes it impossible for Google to decrypt the credentials without you inputting it and they do not store it. https://support.google.com/chrome/answer/165139?visit_id=637591216572649483-884903087&rd=1 Scott Helms On Sat, Jun 12, 2021 at 10:29 AM William Herrin <bill@herrin.us> wrote:
Encryption != plain text, just because it's not a hash doesn't mean it's
On Sat, Jun 12, 2021 at 5:11 AM K. Scott Helms <kscott.helms@gmail.com> wrote: problematic (if done correctly).
Scott, Google's computer is able to compose an html document which contains my passwords in plain text. Whatever dance they do to either side of that point in their process, at that point they possess my passwords in plain text. Why is this concept a mystery to anyone?
This is the exact same method that every single password management system uses and all are far better for the average user than trying to reuse a single password or write them down.
If I had authorized it, it would indeed be just like any other password managing web site. I did not knowingly authorize it. They snuck it on me.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Sat, Jun 12, 2021 at 12:10 PM K. Scott Helms <kscott.helms@gmail.com> wrote:
Scott, Google's computer is able to compose an html document which contains my passwords in plain text. Whatever dance they do to either side of that point in their process, at that point they possess my passwords in plain text. Why is this concept a mystery to anyone?
Because it's wrong, they don't have your passwords you do (more accurately your device does). They don't combine the decryption keys with the encrypted data, your device does.
Look buddy, I'm not lying. Google's server at passwords.google.com composed an html web page containing my plaintext passwords and sent it to me. Not decrypted by my browser after combining it with a locally stored key. Decrypted on and by Google's server. It's not wrong. It's not false. It happened just like that.
You did authorize, you just didn't read the fine print.
I always read the fine print. I'm that guy. I don't always go searching the menus for bad defaults but I always read everything they bother to tell me I'm agreeing to. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Bill, I don't think you're lying, but you are mistaken. "I'm not lying. Google's server at passwords.google.com composed an html web page containing my plaintext passwords and sent it to me. Not decrypted by my browser after combining it with a locally stored key. " So, you're not describing all of the possible ways to decrypt data. What's happening is that the keys to decrypt the passwords are handed to your client (with some checks like a local admin password or pin) when you attempt to decrypt a given password. The passwords _are_ decrypted on your device and you did not get a HTML page with your passwords. Please, go look at the source yourself. What you got was a page that's almost entirely javascript and that includes the functions that handle the decryption. Don't take my word for it, "When you log in to a website while signed in to Chrome, Chrome encrypts your username and password with a secret key known only to your device. Then it sends an obscured copy of your data to Google. Because the encryption happens before Google’s servers get the information, nobody, including Google, learns your username or password." https://support.google.com/chrome/answer/10311524?hl=en#zippy=%2Chow-passwor... If you want the technical details, please take a look at this paper. It goes into detail about the process for Chrome, Firefox, and LastPass. https://courses.csail.mit.edu/6.857/2020/projects/6-Vadari-Maccow-Lin-Baral.... Scott Helms On Sat, Jun 12, 2021 at 5:51 PM William Herrin <bill@herrin.us> wrote:
Scott, Google's computer is able to compose an html document which contains my passwords in plain text. Whatever dance they do to either side of that point in their process, at that point they possess my passwords in plain text. Why is this concept a mystery to anyone?
Because it's wrong, they don't have your passwords you do (more accurately your device does). They don't combine the decryption keys with
On Sat, Jun 12, 2021 at 12:10 PM K. Scott Helms <kscott.helms@gmail.com> wrote: the encrypted data, your device does.
Look buddy, I'm not lying. Google's server at passwords.google.com composed an html web page containing my plaintext passwords and sent it to me. Not decrypted by my browser after combining it with a locally stored key. Decrypted on and by Google's server. It's not wrong. It's not false. It happened just like that.
You did authorize, you just didn't read the fine print.
I always read the fine print. I'm that guy. I don't always go searching the menus for bad defaults but I always read everything they bother to tell me I'm agreeing to.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
So, you're not describing all of the possible ways to decrypt data. What's happening is that the keys to decrypt the passwords are handed to your client (with some checks like a local admin password or pin) when you attempt to decrypt a given password. The passwords _are_ decrypted on your device and you did not get a HTML page with your passwords. Please, go look at the source yourself. What you got was a page that's almost entirely javascript and that includes the functions that handle the decryption.
This. Takes about 5 mins to figure out in the developer console. On Sat, Jun 12, 2021 at 6:56 PM K. Scott Helms <kscott.helms@gmail.com> wrote:
Bill,
I don't think you're lying, but you are mistaken.
"I'm not lying. Google's server at passwords.google.com composed an html web page containing my plaintext passwords and sent it to me. Not decrypted by my browser after combining it with a locally stored key. "
So, you're not describing all of the possible ways to decrypt data. What's happening is that the keys to decrypt the passwords are handed to your client (with some checks like a local admin password or pin) when you attempt to decrypt a given password. The passwords _are_ decrypted on your device and you did not get a HTML page with your passwords. Please, go look at the source yourself. What you got was a page that's almost entirely javascript and that includes the functions that handle the decryption.
Don't take my word for it, "When you log in to a website while signed in to Chrome, Chrome encrypts your username and password with a secret key known only to your device. Then it sends an obscured copy of your data to Google. Because the encryption happens before Google’s servers get the information, nobody, including Google, learns your username or password."
https://support.google.com/chrome/answer/10311524?hl=en#zippy=%2Chow-passwor...
If you want the technical details, please take a look at this paper. It goes into detail about the process for Chrome, Firefox, and LastPass.
https://courses.csail.mit.edu/6.857/2020/projects/6-Vadari-Maccow-Lin-Baral....
Scott Helms
On Sat, Jun 12, 2021 at 5:51 PM William Herrin <bill@herrin.us> wrote:
Scott, Google's computer is able to compose an html document which contains my passwords in plain text. Whatever dance they do to either side of that point in their process, at that point they possess my passwords in plain text. Why is this concept a mystery to anyone?
Because it's wrong, they don't have your passwords you do (more accurately your device does). They don't combine the decryption keys with
On Sat, Jun 12, 2021 at 12:10 PM K. Scott Helms <kscott.helms@gmail.com> wrote: the encrypted data, your device does.
Look buddy, I'm not lying. Google's server at passwords.google.com composed an html web page containing my plaintext passwords and sent it to me. Not decrypted by my browser after combining it with a locally stored key. Decrypted on and by Google's server. It's not wrong. It's not false. It happened just like that.
You did authorize, you just didn't read the fine print.
I always read the fine print. I'm that guy. I don't always go searching the menus for bad defaults but I always read everything they bother to tell me I'm agreeing to.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Sat, Jun 12, 2021 at 3:55 PM K. Scott Helms <kscott.helms@gmail.com> wrote:
I don't think you're lying, but you are mistaken.
"I'm not lying. Google's server at passwords.google.com composed an html web page containing my plaintext passwords and sent it to me. Not decrypted by my browser after combining it with a locally stored key. "
So, you're not describing all of the possible ways to decrypt data. What's happening is that the keys to decrypt the passwords are handed to your client (with some checks like a local admin password or pin) when you attempt to decrypt a given password. The passwords _are_ decrypted on your device and you did not get a HTML page with your passwords. Please, go look at the source yourself. What you got was a page that's almost entirely javascript and that includes the functions that handle the decryption.
Don't take my word for it, "When you log in to a website while signed in to Chrome, Chrome encrypts your username and password with a secret key known only to your device. Then it sends an obscured copy of your data to Google. Because the encryption happens before Google’s servers get the information, nobody, including Google, learns your username or password."
There's a problem with your theory. The browser I viewed the passwords from Google in wasn't Chrome. And it didn't have a local copy of any Google passwords or keys. The only place they could have come from was Google's server. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Bill, It's not a theory and it doesn't have to be Chrome to work. Javascript does the work to decrypt the data and it's not browser specific. Read the PDF I supplied that details_excatly_ how the key exchange and encryption works. Scott Helms On Sat, Jun 12, 2021 at 10:35 PM William Herrin <bill@herrin.us> wrote:
On Sat, Jun 12, 2021 at 3:55 PM K. Scott Helms <kscott.helms@gmail.com> wrote:
I don't think you're lying, but you are mistaken.
"I'm not lying. Google's server at passwords.google.com composed an html web page containing my plaintext passwords and sent it to me. Not decrypted by my browser after combining it with a locally stored key. "
So, you're not describing all of the possible ways to decrypt data. What's happening is that the keys to decrypt the passwords are handed to your client (with some checks like a local admin password or pin) when you attempt to decrypt a given password. The passwords _are_ decrypted on your device and you did not get a HTML page with your passwords. Please, go look at the source yourself. What you got was a page that's almost entirely javascript and that includes the functions that handle the decryption.
Don't take my word for it, "When you log in to a website while signed in to Chrome, Chrome encrypts your username and password with a secret key known only to your device. Then it sends an obscured copy of your data to Google. Because the encryption happens before Google’s servers get the information, nobody, including Google, learns your username or password."
There's a problem with your theory. The browser I viewed the passwords from Google in wasn't Chrome. And it didn't have a local copy of any Google passwords or keys. The only place they could have come from was Google's server.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
There's a problem with your theory. The browser I viewed the passwords from Google in wasn't Chrome. And it didn't have a local copy of any Google passwords or keys. The only place they could have come from was Google's server.
Yes. The *encrypted* blob of login/password data was retrieved from Google's servers over a TLS protected session. When you click on any password to view it, the Javascript that it also downloaded presents you with another password challenge, which when successful, the JS will then to decrypt and display the data. - Nothing is ever transmitted in the clear. - The decryption as far I can see is only ever done locally. ( Using the OS hooks if in Chrome, or Javascript via passwords.google.com. ) On Sat, Jun 12, 2021 at 10:36 PM William Herrin <bill@herrin.us> wrote:
On Sat, Jun 12, 2021 at 3:55 PM K. Scott Helms <kscott.helms@gmail.com> wrote:
I don't think you're lying, but you are mistaken.
"I'm not lying. Google's server at passwords.google.com composed an html web page containing my plaintext passwords and sent it to me. Not decrypted by my browser after combining it with a locally stored key. "
So, you're not describing all of the possible ways to decrypt data. What's happening is that the keys to decrypt the passwords are handed to your client (with some checks like a local admin password or pin) when you attempt to decrypt a given password. The passwords _are_ decrypted on your device and you did not get a HTML page with your passwords. Please, go look at the source yourself. What you got was a page that's almost entirely javascript and that includes the functions that handle the decryption.
Don't take my word for it, "When you log in to a website while signed in to Chrome, Chrome encrypts your username and password with a secret key known only to your device. Then it sends an obscured copy of your data to Google. Because the encryption happens before Google’s servers get the information, nobody, including Google, learns your username or password."
There's a problem with your theory. The browser I viewed the passwords from Google in wasn't Chrome. And it didn't have a local copy of any Google passwords or keys. The only place they could have come from was Google's server.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
Has anyone used or looked at Bitwarden. They have a commercial cloud version, but also there is a run it yourself version. There is a RUST port called vaultwarden with docker images. Anyone have any experience with this particular password manager? Geoff On 6/13/21 11:12 AM, Tom Beecher wrote:
There's a problem with your theory. The browser I viewed the passwords from Google in wasn't Chrome. And it didn't have a local copy of any Google passwords or keys. The only place they could have come from was Google's server.
Yes. The *encrypted* blob of login/password data was retrieved from Google's servers over a TLS protected session. When you click on any password to view it, the Javascript that it also downloaded presents you with another password challenge, which when successful, the JS will then to decrypt and display the data.
- Nothing is ever transmitted in the clear. - The decryption as far I can see is only ever done locally. ( Using the OS hooks if in Chrome, or Javascript via passwords.google.com <http://passwords.google.com>. )
On Sat, Jun 12, 2021 at 10:36 PM William Herrin <bill@herrin.us <mailto:bill@herrin.us>> wrote:
On Sat, Jun 12, 2021 at 3:55 PM K. Scott Helms <kscott.helms@gmail.com <mailto:kscott.helms@gmail.com>> wrote: > I don't think you're lying, but you are mistaken. > > "I'm not lying. Google's server at passwords.google.com <http://passwords.google.com> > composed an html web page containing my plaintext passwords and sent > it to me. Not decrypted by my browser after combining it with a > locally stored key. " > > So, you're not describing all of the possible ways to decrypt data. What's happening is that the keys to decrypt the passwords are handed to your client (with some checks like a local admin password or pin) when you attempt to decrypt a given password. The passwords _are_ decrypted on your device and you did not get a HTML page with your passwords. Please, go look at the source yourself. What you got was a page that's almost entirely javascript and that includes the functions that handle the decryption. > > Don't take my word for it, "When you log in to a website while signed in to Chrome, Chrome encrypts your username and password with a secret key known only to your device. Then it sends an obscured copy of your data to Google. Because the encryption happens before Google’s servers get the information, nobody, including Google, learns your username or password."
There's a problem with your theory. The browser I viewed the passwords from Google in wasn't Chrome. And it didn't have a local copy of any Google passwords or keys. The only place they could have come from was Google's server.
Regards, Bill Herrin
-- William Herrin bill@herrin.us <mailto:bill@herrin.us> https://bill.herrin.us/ <https://bill.herrin.us/>
---------- Forwarded message --------- From: William Herrin <bill@herrin.us> Date: Fri, 11 Jun 2021, 17:04 Subject: Google uploading your plain text passwords To: nanog@nanog.org <nanog@nanog.org> Howdy, My gmail account prompted me today to change a compromised password. It wasn't compromised; it was an offline system where I intentionally used a generic password. But in the process... It turns out that every password I allowed Chrome on Android to remember, it uploaded to Google. In plain text!! And it could prove it by displaying the plain text passwords for me on my laptop. And I can't turn the upload off! To the google folks on here: Are you INSANE!? Regards, Bill Herrin -- William Herrin bill@herrin.us All https://bill.herrin.us/to beaa
participants (20)
-
Alain Hebert -
Anoop Ghanwani -
Christopher Morrow -
César de Tassis Filho -
Damian Menscher -
Eric Kuhnke -
Hank Nussbacher -
Jan Schaumann -
Jim -
John Levine -
Josh Luthman -
K. Scott Helms -
Matthew Petach -
Max Harmony -
Michael Thomas -
nanog08＠mulligan.org -
Peter Beckman -
Stephen Bertram -
Tom Beecher -
William Herrin