Re: Google uploading your plain text passwords

[Jim <mysidia () gmail com>]

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