Re: Google uploading your plain text passwords

[William Herrin]

On Sat, Jun 12, 2021 at 3:55 PM K. Scott Helms  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
b...@herrin.us
https://bill.herrin.us/

Re: Google uploading your plain text passwords

[Tom Beecher]

>
> 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 
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-password-protection-works%2Chow-we-protect-your-data
>
> 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.pdf
>
> Scott Helms
>
>
>
> On Sat, Jun 12, 2021 at 5:51 PM William Herrin  wrote:
>
>> On Sat, Jun 12, 2021 at 12:10 PM K. Scott Helms 
>> 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
>> b...@herrin.us
>> https://bill.herrin.us/
>>
>

Re: Google uploading your plain text passwords

[K. Scott Helms]

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-password-protection-works%2Chow-we-protect-your-data

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.pdf

Scott Helms



On Sat, Jun 12, 2021 at 5:51 PM William Herrin  wrote:

> On Sat, Jun 12, 2021 at 12:10 PM K. Scott Helms 
> 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
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Google uploading your plain text passwords

[William Herrin]

On Sat, Jun 12, 2021 at 10:36 AM Max Harmony via NANOG  wrote:
> On 12 Jun 2021, at 10.29, William Herrin  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
b...@herrin.us
https://bill.herrin.us/

Re: Google uploading your plain text passwords

[William Herrin]

On Sat, Jun 12, 2021 at 12:10 PM K. Scott Helms  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
b...@herrin.us
https://bill.herrin.us/

Re: Google uploading your plain text passwords

[Christopher Morrow]

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  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

Re: Google uploading your plain text passwords

[K. Scott Helms]

  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=1

Scott Helms



On Sat, Jun 12, 2021 at 10:29 AM William Herrin  wrote:

> On Sat, Jun 12, 2021 at 5:11 AM K. Scott Helms 
> 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
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Google uploading your plain text passwords

[Jim]

On Sat, Jun 12, 2021 at 12:33 PM Christopher Morrow
 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

Re: Google uploading your plain text passwords

[Hank Nussbacher]

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

Re: Google uploading your plain text passwords

[Christopher Morrow]

On Sat, Jun 12, 2021 at 1:31 PM Christopher Morrow 
wrote:

>
>
> On Sat, Jun 12, 2021 at 1:21 PM Tom Beecher  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/password_manager/
>
>
> 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==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  wrote:
>>
>>> On Sat, Jun 12, 2021 at 5:11 AM K. Scott Helms 
>>> 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
>>> b...@herrin.us
>>> https://bill.herrin.us/
>>>
>>

Re: Google uploading your plain text passwords

[Max Harmony via NANOG]

On 12 Jun 2021, at 10.29, William Herrin  wrote:
> 
> They
> snuck it on me.

By hiding it right on the "browser features" page?


signature.asc
Description: Message signed with OpenPGP

Re: Google uploading your plain text passwords

[Christopher Morrow]

On Sat, Jun 12, 2021 at 1:21 PM Tom Beecher  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/password_manager/


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  wrote:
>
>> On Sat, Jun 12, 2021 at 5:11 AM K. Scott Helms 
>> 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
>> b...@herrin.us
>> https://bill.herrin.us/
>>
>

Re: Google uploading your plain text passwords

[Tom Beecher]

>
> 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  wrote:

> On Sat, Jun 12, 2021 at 5:11 AM K. Scott Helms 
> 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
> b...@herrin.us
> https://bill.herrin.us/
>

Re: [nanog] Famous operational issues

[Patrick Schultz]

opening the link currently gives me a HTTP 500 error, very fitting :)

Am 12.06.2021 um 04:42 schrieb Dan Mahoney:
> I only just now found this thread, so I'm sorry I'm late to the party, but 
> here, I put it on Medium.
>
> https://gushi.medium.com/the-worst-day-ever-at-my-day-job-beff7f4170aa
>
>> On Mar 12, 2021, at 10:07 PM, Mark Tinka  wrote:
>>
>> Hardly famous and not service-affecting in the end, but figured I'd share an 
>> incident from our side that occurred back in 2018.
>>
>> While commissioning a new node in our Metro-E network, an IPv6 
>> point-to-point address was mis-typed. Instead of ending in /126, it ended in 
>> /12. This happened in Johannesburg.
>>
>> We actually came across this by chance while examining the IGP table of 
>> another router located in Slough, and found an entry for 2c00::/12 floating 
>> around. That definitely looked out of place, as we never carry parent blocks 
>> in our IGP.
>>
>> Running the trace from Slough led us back to this one Metro-E device in 
>> Jo'burg.
>>
>> It took everyone nearly an hour to figure out the typo, because for all the 
>> laser focus we had on the supposed link of the supposed box that was 
>> creating this problem, we all overlooked the fact that the /12 configured on 
>> the point-to-point link was
>> actually supposed to have been a /126.
>>
>> The reason this never caused a service problem was because we do not 
>> redistribute our IGP into BGP (not that anyone should). And even if we did, 
>> there are a ton of filters and BGP communities on all devices to ensure a 
>> route such as that would have
>> never made it out of our AS.
>>
>> Also, the IGP contains the most specific paths to every node in our network, 
>> so the presence of the 2c00::/12 was mostly cosmetic. It would have never 
>> been used for routing decisions.
>>
>> Mark.
>

Re: [nanog] Famous operational issues

[Giuseppe De Luca]

What a day.. hope you are better now :)


On 6/12/2021 2:42 AM, Dan Mahoney wrote:

I only just now found this thread, so I'm sorry I'm late to the party,
but here, I put it on Medium.

https://gushi.medium.com/the-worst-day-ever-at-my-day-job-beff7f4170aa



On Mar 12, 2021, at 10:07 PM, Mark Tinka  wrote:

Hardly famous and not service-affecting in the end, but figured I'd
share an incident from our side that occurred back in 2018.

While commissioning a new node in our Metro-E network, an IPv6
point-to-point address was mis-typed. Instead of ending in /126, it
ended in /12. This happened in Johannesburg.

We actually came across this by chance while examining the IGP table
of another router located in Slough, and found an entry for 2c00::/12
floating around. That definitely looked out of place, as we never
carry parent blocks in our IGP.

Running the trace from Slough led us back to this one Metro-E device
in Jo'burg.

It took everyone nearly an hour to figure out the typo, because for
all the laser focus we had on the supposed link of the supposed box
that was creating this problem, we all overlooked the fact that the
/12 configured on the point-to-point link was actually supposed to
have been a /126.

The reason this never caused a service problem was because we do not
redistribute our IGP into BGP (not that anyone should). And even if
we did, there are a ton of filters and BGP communities on all devices
to ensure a route such as that would have never made it out of our AS.

Also, the IGP contains the most specific paths to every node in our
network, so the presence of the 2c00::/12 was mostly cosmetic. It
would have never been used for routing decisions.

Mark.

Re: Google uploading your plain text passwords

[William Herrin]

On Sat, Jun 12, 2021 at 5:11 AM K. Scott Helms  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
b...@herrin.us
https://bill.herrin.us/

Re: Google uploading your plain text passwords

[K. Scott Helms]

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  wrote:

> On Fri, Jun 11, 2021 at 9:42 AM César de Tassis Filho
>  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
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Google uploading your plain text passwords

[Anoop Ghanwani]

On Fri, Jun 11, 2021 at 12:51 PM Matthew Petach 
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-chrome-passwords/