[Feature Request]: Reset cookie encryption key

[kris7t]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description

The cookie encryption feature added in #27524 and the related electron.safeStorage API #30020 allows storing secrets encrypted by a per-application key under MacOS and certain Linux systems. However, Chromium's encryption approach is somewhat vulnerable to replay attacks: since a fixed encryption key is used, Chromium will decrypt any secret, including secrets previously captured and then restored.

For a simple example, consider an application with a password lock with the password lock settings and the hash of the password saved in a config file as a secret encrypted with electron.safeStorage to prevent tampering. This is vulnerable to a replay attack:

1. An attacker can capture an encrypted configuration with a disabled lock (e.g., written to the disk by the application before the user has set up the password lock).
2. Even after the user has set up the password lock, the attacker can just replace the config file with the captured one (i.e., replay it) to completely disable the lock.

This could be made much more secure if the application could wipe the encryption key when the password is changed or an invalid (encrypted) configuration file is detected. This would wipe any sensitive information (cookies) stored by the application, and make previously captured encrypted data useless (as long as the system keychain remains secure).

Proposed Solution

There should be a way to reset the cookie encryption key, making any previously saved encrypted data unrecoverable.

After a new key should be generated and saved in the system keychain, there should be a way for the application to use the new key for encrypting data before it restarts. This would make it possible to automatically reset the key when tampering with the encrypted data is detected (so that a new, valid encrypted configuration can be saved and we don't get into an infinite loop due to interpeting the missing/garbled encrypted configuration as a tamper on the next restart).

Alternatives Considered

One possible solution is to wipe any saved cookies (instead of the encryption key) when tampering is detected. This may deter less prepared attackers, but, as long as any previously data can still be encrypted with the current key, the attacker can just replay a backup of the encrypted cookie database, too.

If the operating system (MacOS) or the keychain application (Linux) supports it, the user could directly set the cookie encryption key to require a password before it is released to Electron. This has several downsides:

• It requires special support from the host system.
• It requires manual intervention from the user and cannot be set up from an Electron application.
• It requires the user to quit the Electron application to make it locked (i.e., make local, but non-administrator attackers unable to access encrypted data).

Additional Information

This issue came up when trying to brainstorm a master password lock feature for a(n upcoming) messaging application: https://gitlab.com/say-hi-to-sophie/sophie/-/issues/15

The key management problem also exists in other applications, such as https://github.com/ramboxapp/community-edition/issues/2048

[nornagon]

I'm not sure I fully understand your use case, but if you have a "password lock" feature, then the password should be part of the encryption key when you store your data. You could, for instance, encrypt the data prior to passing it to safeStorage, using the password as the key.

I'm closing this because as described, I don't think there is any action for us to take. I'm happy to continue discussion here though and we can reopen if needed.

[kris7t]

The problem is that the data we're trying to protect is the cookies within the (persistent) chromium partitions set by third-party sites. These are not under our control, so we can't change them to use a user-provided secret instead).

Normally, cookies are encrypted with the chromium cookie encryption key (when electron is fused for it), which -- as far as I known -- can't be changed or reset from within an electron app. The only possible way I can see is to instruct the user to manually go to the system keychain app and delete the cookie encryption key from there.

If the encryption key could be derived from a user-entered password, there could be an effective password lock (i.e., the cookies would be protected by the derived key). But this also seems impossible (even if the chromium cookie encryption key could be configured), since we would need to display browser window to prompt the user for the password, and (I presume) creating a browser window would already require a cookie encryption key to be present.

So the next best thing is to have the cookie encryption key randomly generated and stored in the keychain (i.e., normal electron/chromium cookie encryption), which lets us display the password prompt, and then decide whether to load the third-party sites (that use the cookies that are stored in an encrypted by chromium) based on the password provided by the user.

But in this scenario, the user's password hash is vulnerable to replay attacks, even if it is stored in an encrypted form. This is due to the (obvious) weakness that the cookie encryption key is not actually derived from the password, so the cookies are not bound to the password in any way. This could be patched up by resetting the chromium cookie encryption key (thereby clearing/garbling and cookies stored in persistent partitions) on every password change.

---

Indeed, there might be some A/B problem in here. 🙂 A much better way would be to be able to provide a custom cookie encryption key for the third-party cookies per session (or partition), so keys actually derived by the user password could be used for third-party sites. But I'm not sure whether chromium's architecture would allow this at all, while being able to just reset the key stored in the OS keychains seems much easier. Hence this feature request.