Google uploading your plain text passwords

Sun Jun 13 01:19:25 UTC 2021

>
> 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 at 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 at herrin.us> wrote:
>
>> On Sat, Jun 12, 2021 at 12:10 PM K. Scott Helms <kscott.helms at 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 at herrin.us
>> https://bill.herrin.us/
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210612/2aaaca4e/attachment.html>