Mailing List Archive

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/

On Fri, Jun 11, 2021 at 9:16 AM Matthias Merkel
<matthias.merkel@staclar.com> wrote:
> On mobile: Chrome Settings -> Sync -> Uncheck Sync All -> Uncheck Passwords

This works. Thank you.

Still, on by default? How many billions of passwords does google now
have stored with reversible encryption?

Regards,
Bill Herrin



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

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

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

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

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

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

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

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 12:01 PM William Herrin <bill@herrin.us> wrote:

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

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, 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 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-chrome-passwords/

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:

> 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: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/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 <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 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?

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

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:

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

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

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/

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 <bill@herrin.us> wrote:

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

>
> 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-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 <bill@herrin.us> wrote:
>
>> 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/
>>
>

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

I am not the brightest bulb in the house, but when I try to go to
passwords.google.com, I get the following response:

Google can't check your passwords for security issues because you set up a
> passphrase to encrypt your passwords in your Google Account. This keeps the
> data private to you. Learn more.
> <https://support.google.com/chrome/bin/answer/165139?hl=en>


This occurs on my Google Chrome browser, which does sync my passwords
between devices because I have the browser signed into my personal account,
and my Brave browser, which is never signed in with any Google accounts.

I don't remember setting a passphrase, but apparently I did. I can't
remember if I did that because I did see a behaviour, such as showing me
all my passwords with little to no effort, or it was offered as a security
feature and I said, "Yes, please."

Jason K Pope
214.566.8527
boards188@gmail.com
Greater love has no one than this, that one lay down his life for his
friends.
John 15:13