1

According to Arun on StackOverflow “Starting Chrome 80 version, cookies are encrypted using the AES256-GCM algorithm, and the AES encryption key is encrypted with the DPAPI encryption system, and the encrypted key is stored inside the ‘Local State’ file.”. (https://stackoverflow.com/questions/60230456/dpapi-fails-with-cryptographicexception-when-trying-to-decrypt-chrome-cookies/60611673#60611673).

Now at first glance this looks like an improvement rather than passing cookies to Windows Data Protection API (DPAPI) directly they’re encrypted with a better algorithm and only the key is protected through the API. Stronger encryption is used and Windows Data Protection API encrypts the key. Unfortunately the protection scope is changed from LocalUser to LocalMachine.

It appears that this means if a user were to copy the hard drive by plugging it into another computer they would no longer need your Windows account password to decrypt this key in the local state file with the Windows Data Protection API. In theory this would allow another user on the system to steal passwords and cookies weakening security protections that existed further.

I put together a code demo with Brave Browser demonstrating this risk (see: https://github.com/irlcatgirl/BraveCookieReaderDemo). It’s easy enough to swap paths of SQLite and Local State files for Chrome.

According to https://docs.microsoft.com/en-us/windows/win32/api/dpapi/nf-dpapi-cryptprotectdata#parameters

Typically, only a user with logon credentials that match those of the user who encrypted the data can decrypt the data. In addition, decryption usually can only be done on the computer where the data was encrypted. However, a user with a roaming profile can decrypt the data from another computer on the network. If the CRYPTPROTECT_LOCAL_MACHINE flag is set when the data is encrypted, any user on the computer where the encryption was done can decrypt the data. The function creates a session key to perform the encryption. The session key is derived again when the data is to be decrypted.

Due to a change in scope in Windows DPAPI did this change harm Chrome’s security or am I misinterpreting my findings?

  • 1
    Might be a vulnerability, but once an attacker has access to your local machine and you did not use any FDE, then all bets are off anyways. – MechMK1 Apr 20 at 8:06
  • @MechMK1 Not really? I mean, Windows password hashing is disgustingly bad, but a password-encrypted file - which is what any data encrypted with current-user DPAPI boils down to - is still going to be unreadable to the attacker until they crack that password. Getting physical access to a non-FDE machine means you can read and write any data you want, but if the data you want - such as the necessary stored passwords and/or cookies to hijack your accounts - are encrypted and the keys (or the key to unwrap the keys) aren't stored on the disk, the attacker is SOL. – CBHacking Apr 22 at 5:23
2

Just going off what you describe: I can see no legitimate reason whatsoever for Chrome to use the Local Machine scope, and I would call that a security vulnerability.

I'm not sure how secure the local machine key is, but at minimum it can be decrypted by any user with authenticated (login) access to the machine. It might be possible even without any log in access if the key is stored in a retrievable way (to an attacker with unrestricted read access but no passwords, such as somebody who stole a hard drive that wasn't using full-volume encryption). By contrast, the user DPAPI master key is wrapped using a key derived from the user's password and through a fairly expensive key derivation function.

I'm also just not really sure why to make this change in general. Yes, AES256-GCM might be a bit more secure than DPAPI's default (AES128-CBC + HMAC-SHA2-512, I think) but for practical purposes adding more crypto implementations isn't a good idea; the security is only as good as the weakest link. DPAPI is slow to initialize due to the expensive key derivation algorithm, but once it's initialized the key gets stored in non-paged memory inside the protected Windows security subsystem; using the key is then fast (it requires a same-machine remote procedure call, and inter-process communication always has some perf cost, but the lrpc system on Windows is highly optimized and the data being passed is small). Additionally, the protections on the key are probably much better than Chrome will put on its "master" key.

I'm sure Google had their reasons, and they might even be good ones for at least part of their audience (maybe they had a problem with the way current-user keys work on domain-joined machines? maybe some people use different Windows accounts but share a Chrome profile somehow, and it needed the encrypted data to be shareable across the accounts for a setup like that?), but for the typical user this looks like a major step backwards for very little gain.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.