You seem to be curious specifically about the key used to encrypt the passwords in Chrome.

The answer is:

Every password is encrypted with a different random key.

And then the encrypted password is stored in the SQLite database file:

%LocalAppData%\Google\Chrome\User Data\Default\Login Data

You can use something like SQLite Database Browser or SQLite Maestro to view it. Here's a snippet from my Login Data file:

origin_url                                username_value               password_value
========================================  ==============               ========================
http://thepiratebay.org/register          [email protected]  01000000D08C9DDF0115D1118C7A00C04FC297EB01000000BB0E1F4548ADC84A82EC0873552BCB460000000002000000000003660000C0000000100000006811169334524F33D880DE0C842B9BBB0000000004800000A00000001000000043C8E23979F5CC5499D73610B969A92A08000000EE07953DEC9F7CA01400000098B5F0F01E35B0DC6BBAFC53A9B1254AC999F4FA

You'll notice the password is an encrypted blob of data. The approximate algorithm to encrypt a new password is:

  • generate a new random session key
  • encrypt the password with the session key
  • encrypt the session key with the user's RSA public key
  • generate a Message Authentication Code (HMAC) for the encrypted data
  • concatenate the encrypted session key, the encrypted password, and the MAC

And Chrome saves that blob to its SQLite database.

But to answer your question: Where does the encryption key come from?

Each password is encrypted with a different randomly generated key

The Technical Details

Of course i left out the technical details. Chrome does not encrypt your passwords itself. Chrome does not have a master key used to encrypt anything. Chrome does not do the encryption. Windows does.

There is a Windows function, CryptProtectData, which is used to encrypt any arbitrary data you like. The details of calling it is less important. But if i invent a pseudo-language that somewhat can be decipherable as any programming languge, Chrome calls:

CryptProtectData(
      { cbData: 28, pbData: "correct battery horse staple" },
      "The password for superuser.com and all the glee therein",
      null, //optional entropy
      null, //reserved
      null, //prompt options
      0, //flags
      { cbData:   pbData:  }); //where the encrypted data will go

So the password:

  • Plaintext: correct battery horse staple
  • Encrypted: 01000000D08C9DDF0115D1118C7A00C04FC297EB01000000BB0E1F4548ADC84A82EC0873552BCB460000000002000000000003660000C0000000100000006811169334524F33D880DE0C842B9BBB0000000004800000A00000001000000043C8E23979F5CC5499D73610B969A92A08000000EE07953DEC9F7CA01400000098B5F0F01E35B0DC6BBAFC53A9B1254AC999F4FA

You'll notice that i never needed to supply a password. That is because Windows takes care of all of that. In the end:

  • a random password is generated to encrypt the password
  • that password is encrypted with a random password
  • that password is encrypted with your Windows password

So the only way for someone to know your password is if they know your password.


The passwords are encrypted and stored in a SQLite database:

The important piece here is CryptProtectData, which is a Windows API function for encrypting data. Data encrypted with this function is pretty solid. It can only be decrypted on the same machine and by the same user that encrypted it in the first place.