3

I use Google to store some of my passwords and I noticed a "On-Device encryption" option in Google Chrome settings, that I had disabled. From what I understood, by allowing this, the password would first be encrypted on my devices and only the encrypted string would then be stored on Google servers. So I have turned that on, confirmed it in my mobile phone (Android), set it to use lock screen as a key and everything came through sucessfully - it's (supposedly) now enabled.

But I am not really sure, how and whether does it work. It didn't give me any kind of "master key". When I am using password autofill function of Google Chrome browser on PC or mobile phone, it still does not ask me for anything.

Also, the Google Chrome on PC still warns me about "compromised passwords", so the Google still has to see the raw unencrypted passwords (unless there is some offline DB of compromised passwords in Google Chrome)

According to https://support.google.com/accounts/answer/11350823?visit_id=638154166731283006-3135705296&p=settings_password_ode&rd=1 , there should be some kind of "master key":

Just remember that if you lose the key to your data, you could lose your passwords and passkeys too.

But what key are they referring to? Where can I find the key?

On mobile phone, the key gets probably applied by unlocking the phone with pattern or fingerprint. But what about PC? How does it decrypt the passwords?

schroeder
  • 129,372
  • 55
  • 299
  • 340
user10099
  • 135
  • 1
  • 6
  • I recently read Chromium's code for its cookie jar encryption. There, it used OS-specific APIs such as Window's DPAPI CryptProtectData() for key management. That is, if you can log in to your Windows account, you can perform the decryption. I would expect the password manager to use similar features. But this is just intended to defend against certain attackers, not against Google itself. Google's password manager is not zero-trust. – amon Mar 26 '23 at 10:59
  • That would make sense .. but how would then the synchronization between diferent devices work? For example, if I create new password on Windows using Google Chrome, it would be somehow encrypted by the Windows account credentials and then stored on Google server. How would then Android decrypt it? It has no knowledge of any Windows account. – user10099 Mar 26 '23 at 12:44
  • Or is it actually stored in unencrypted form on Google servers and all this encryption is just about how each of the devices stores these passwords locally for themselves? That way, each of the devices could use their own encryption methods .. – user10099 Mar 26 '23 at 12:50

2 Answers2

0

But what about PC? How does it decrypt the passwords?

It seems that the key that is used to decrypt your passwords on your computer is derived from your Google password.

See the section, 'How It Works', where it reads,

'Once on-device encryption is set up, you can use your Google password or the screen lock for compatible phones or tablets to unlock your password or passkey' (emphasis mine).

Also see further down, under 'How on-device encryption works', where it reads,

'When on-device encryption is set up, your passwords can only be unlocked on your device using your Google password or the screen lock for an eligible device. With on-device encryption, no one besides you will be able to access your passwords'.

I think the key that they are referring to in the section that you referenced in your question is really your Google password.

If that's the case, then it seems that Google is storing your encrypted passwords on their server. The encrypted passwords are downloaded to your device when you login to Google. Then, on your device, a key is derived from your Google password, and this key is used to decrypt your encrypted passwords. This way, Google never sees your plaintext passwords, and Google does not have the key to decrypt your passwords (because presumably they are only storing a salted hash of your Google password, and they are not storing your Google password in plaintext form).

With regard to the question of how the encrypted password file is synced between different devices, where a different password is used on each device: This problem is akin to the problem of broadcasting an encrypted message to multiple recipients. Just think of each device as a recipient. For example, on your Android device, suppose you add a new password to you password store. The encrypted password store is then broadcasted to all of your other devices, so that later, on your computer for example, you have the new password there as well. The problem of broadcasting an encrypted message to multiple recipients, where each recipient has a unique private / public keypair,has a well accepted solution. See Sharing files with others, encrypted on untrustworthy file storage (e.g. the cloud) for more info.

So, on your computer, it is likely that an asymmetric private/public keypair is derived from your Google password; and similarly on your Android device, a unique private/public keypair is derived from your screen unlock code.

schroeder
  • 129,372
  • 55
  • 299
  • 340
mti2935
  • 23,468
  • 2
  • 53
  • 73
  • If the Google account password is actually the master symmetric key used to encrypt all stored passwords, what would happen, if I would change this password?

    I have actually tried this - I have put all my devices offline, logged in to Google account using Firefox on Windows PC (that does not know about my Google stored passwords) and changed the Google account password. Then, using new Firefox incognito instance, I logged in with the new password and I was still able to view the raw passwords (https://myaccount.google.com/security) - it only asked me for an Android lock screen pattern.

     – user10099 Mar 26 '23 at 14:39
  • Which proves, that Google account password is not needed to decrypt the passwords. Does that mean, that in my case, the master symmetric key is the Android lock screen pattern? If that is so, how can Chrome work with the passwords, when it does not know this pattern? (after I have updated the password in Chrome, it could access the passwords straight away. it didn't ask for the Lock screen pattern) – user10099 Mar 26 '23 at 14:39
  • I have done a next experiment - I have deleted my profile from Chrome completely, then changed the password through Firefox. After that, I have synced with my profile back and only then it asked me for my lock screen pattern on Chrome. So my master key is probably really that Android lock screen pattern and it was initially automatically stored in Chrome when I was enbling this "on-device encryption" feature. – user10099 Mar 26 '23 at 14:59
  • The master symmetric key (MSK) used to encrypt all your passwords is then encrypted with each device's public key; whereby each device's public/private keypair are derived from either your Google password or the device's lock code. Then, this entire bundle (including all of the encrypted passwords, and the MSK encrypted with each device's public key) is synced to all devices. This is how the new FF incognito instance was able to view your raw passwords, using your android lock code. When you change passwords, the MSK is simply decrypted using the old password, and re-encrypted using the new. – mti2935 Mar 26 '23 at 15:02
  • So the reason why I was able to access the passwords by Android screen code from FF was, that because of the previous password change, the private key derived from actual password couldn't be used to decrypt the MSK, because the MSK encrypted by FF's new public key did not exist yet in this bundle (= the device was uknown). So the new device (FF) used other device's (Android) mechanism (lock screen) to derive its private key, used that private key to decrypt MSK (enc by Android pub key) and then added MSK encrypted by its own public key to this bundle as the new device. Does that seem right? – user10099 Mar 26 '23 at 17:04
  • Yes, that seems right. – mti2935 Mar 26 '23 at 17:08
  • Ok, perfect. So if I understand it correctly, the MSK is not a Google account password. It can actually be anything. It just needs to be generated locally (probably by the first device?) and then passed within this bundle, encrypted for each device separately. – user10099 Mar 26 '23 at 17:22
  • 1
    Yes, that's correct. The MSK is most likely generated by a CSPRNG, and all of the devices operate the same way. Each time a change is made to the underlying password file, the device on which the change was made simply creates a new randomly generated MSK, encrypts the plaintext password file with this MSK, then encrypts the MSK using each of the other device's public keys, then uploads the entire bundle to Google's server, which then distributes this bundle to all of the other devices. – mti2935 Mar 26 '23 at 17:34
  • Thanks for explanation :) Once you mentioned the "bundle", it all started to make sense. – user10099 Mar 26 '23 at 18:00
  • 1
    Glad it makes sense. BTW, it should be noted that this is not a zero-trust system. When you login to a Google service using your Google password, Google sees your Google password in plaintext (after it is sent through the TLS tunnel). If Google (or an employee at Google) were to 'go rogue', they could then use your Google password to decrypt your other passwords. – mti2935 Mar 27 '23 at 07:25
-1

I think the accepted answer is actually wrong. Let's check the fact in the google's own document:

First it said very clear it is a single unique key that is used to encrypt your data.

Encryption is just a way of making the info you save to Google more secure. Using a unique key, your info is made impossible to read by anyone else. Then, the only way to read the information is by unlocking it with the same unique key.

This unique key is stored on Google's server and google can use it to decrypt your data without your consent.

The encryption key, used to access your passwords, is safely stored in your Google Account. Google then uses this key to access (decrypt) your passwords

The following recovery option further verified my observation because if the google do not own your key in clear text, then it cannot recovery your encrypted data.

If you lose your Google password, you risk loss of access to your saved passwords. Keeping your account recovery phone number and email up-to-date can help regain access to your account if you lose your password.

But google do provide an option to let you control your own encryption key which in theory google won't record it. This is the hidden option sync passphrase.

The difference between on-device encryption & sync passphrase With sync passphrase, you choose a phrase to lock and unlock your data. You will lose access to your data if you forget your sync passphrase With a passphrase, you can use Google's cloud to store and sync your Chrome data without letting Google read it.

But I really have some doubt here because they did not disclose their actual algorithm and also no one can audit their code. They can simply just record your passphrase but still telling you they do not have it in your face.

So I think why risk to lock yourself out? just use the on device encryption and only store unimportant credential in there. For privacy you should use some dedicated password manager like bitwarden. For critical credentials you should never store it in any cloud, remember them, or less securely put them on a paper and hide it. Change your password more often.

Wang
  • 128
  • 5