5 ms·

Key for chromium's encrypted cookies store in Linux is “peanuts”

111 points by TjWallas 11y ago

mschuster91 11y ago
Well without having a user-specified master password like firefox has, you're bound to use some "pseudosecret" keys.
- vbezhenar 11y ago
  You can use unique password stored in the protected system storage (like OS X Keychain) so at least user is protected from non-root users.
  - RubyPinch 11y ago
    shouldn't that protection already exist just in the file permissions of the cookie storage? this doesn't really protect much from other users since other users don't have access to the file in the first place, and doesn't protect from the user that owns the browser process. which is probably why the bug still exists, adding a randomly generated key only adds another easily passable obstacle
    - nly 11y ago
      File permissions can be bypassed by anyone who gets physical access once, encryption can't.
    - vbezhenar 11y ago
      I have user vbezhenar. I run browser under that user. I have system storage for sensitive data. Its data available only via API which checks permissions. E.g. only Chrome can access its data. Chrome must be able to read its cookies, so cookies file must be readable/writeable for user vbezhenar. And there are high chances that I'll run malware program under this user vbezhenar too, so it can read cookies file, but it won't be able to access encryption password.
- justinschuh 11y ago
  System credential managers are the established way to do this properly. They are user configurable, generally maintain credentials in a separate security context, derive a strong key from the user logon credential, can more easily support hardware security mechanisms, and introduce minimum user friction by default. That's why Chrome and most browsers prefer the system credential managers when available (on Linux: libsecret, Gnome Keyring, or KWallet). The application specific "master password" is more of an anti-pattern for effective credential storage. The most glaring issue is that user friction is so high that it's rarely ever enabled, because it's just too inconvenient and confusing for most people. But beyond that it has the weaknesses typical to any credential manager not deeply integrated into the OS (e.g. credential management is handled entirely in the user's context, management is inconsistent between applications, etc.).
  - mschuster91 11y ago
    I don't get the advantage of system credential managers - at least as long as the user is logged on, I can always hook myself into a browser process and retrieve the passwords. The only advantage system-level password storage has is when the attacker e.g. wants to get the passwords from a forensic image or such.
userbinator 11y ago
I guess a lot of others are also wondering, "What's the point?" If an attacker can read the file the cookies are stored in, you have already lost. It even mentions "obfuscation" - which might be a slight obstacle if this was closed-source - but Chromium is open-source.
- bbrazil 11y ago
  Obfuscation is still useful. For example if a sysadmin is investigating a problem they're less likely to accidentally see a user's data in human-readable form, it also provides a level of defence against unsophisticated attackers.
  - deleted 11y ago
    [deleted]
    - detaro 11y ago
      They are talking about obfuscating the stored data, not the code.
- justinschuh 11y ago
  The obfuscation isn't really intentional IIRC. It's an artifact of the assumption that a proper base credential will be available from either libsecret, Gnome Keyring, or KDE Wallet. The fixed key is just a placeholder that gets used when none of those secure mechanisms is installed on the system. Although, that file has a number of outdated comments, which add to the confusion.
TjWallas 11y ago
Some more details from the source: Password is: "peanuts" Salt is: "saltysalt" Algorithm used: AES-128-CBC The number of KDF iterations is: 1 Edit: Indicate that no. of iterations is for the Key Derivation Function
- tgb 11y ago
  I don't know too much about this so I'm a bit confused. What does a salt do if it's the same for everything?
  - tinco 11y ago
    Nothing, it's just that the field is required for the function that's being used for the obfuscation. There's a lot of confused people in this thread. There are no mistakes made in the code, people are simply surprised that there's a mode in which Chromium that only obfuscates the keystore. Adding to the confusion is the fact that they're using an encryption library to do the obfuscation, so people see it and expect there to be real encryption going on and then see the dummy values in the important fields.
    - tgb 11y ago
      Okay, I was wondering if something like that was the case.
  - 001spartan 11y ago
    Using a salt ensures that an attacker cannot use pre-generated rainbow tables to crack something. If there is no salt, it is very fast to use rainbow table lookups for cracking. The salt doesn't really need to be secret, as it is only there to make an attacker work harder. However, the existence of a known, hardcoded salt means that an attacker can generate rainbow tables specifically for cracking these cookies, so the salt isn't really useful here.
    - cwyers 11y ago
      Salts are almost never secret, in fact; typically the salt is stored in plaintext alongside the hashed password. As you note, that's because the salt is supposed to defeat pre-computed rainbow tables, not be a shared secret.
Navarr 11y ago
"ksalt - at least salt is a variable, surely it at least is randomly generated, right?" > // Salt for Symmetric key derivation. > const char kSalt[] = "saltysalt";
- verandaguy 11y ago
  Reading this was like seeing a ray of hope being shot down by a minigun. In seriousness, what gives!? Why are these so simple? Surely a development base as large as Chromium's could pick up on something like this.
  - sirclueless 11y ago
    It's a good software development principle. Make things that are secure look secure. Make things that are insecure look insecure. This is going to be insecure no matter what precautions are taken, because the source is open and the key is part of the binary, so it should look exactly as insecure as it is so no one assumes anything untrue about this code.
- dchest 11y ago
  Obviously, there is no point in using a random salt when your key is public. There will be no point in using salt when they generate a random secure key ("We need to improve this password situation by moving a secure password into a system-level key store.") To be fair, there's no point in key derivation at all if the goal is to have a fixed or randomly generated key, so I don't know what they were thinking. Unless this password is provided by user.
teraflop 11y ago
This is misleading. If you follow the links to the Chromium bug tracker, you'll note that Chrome integrates with the GNOME and KDE encrypted password managers when they're available. If they're not, it falls back to storing passwords itself with obfuscation, which is the best it can do. (On Windows and OS X, it uses CryptProtectData and the Keychain API, respectively.) https://code.google.com/p/chromium/wiki/LinuxPasswordStorage https://code.google.com/p/chromium/wiki/LinuxPasswordStorage
- __mp 11y ago
  I wonder how many people are using KDE or Gnome these days. I'm pretty sure I'm using something other than KDE and Gnome on my Linux installs.
  - keithpeter 11y ago
    Debian Popularity Contest can tell you a few things... Just over half of those participating have installed Gnome/KDE/Cinnamon https://qa.debian.org/popcon-graph.php?packages=gnome-shell%2C+gnome-panel%2C+cinnamon%2C+xfce4-panel%2C+kde-workspace-bin&show_installed=on&want_percent=on&want_legend=on&want_ticks=on&from_date=2015-01-01&to_date=2015-06-14&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 https://qa.debian.org/popcon-graph.php?packages=gnome-shell%... And it looks as if about a quarter totally are using Gnome/KDE/Cinnamon regularity (rest could be switched off of course!) https://qa.debian.org/popcon-graph.php?packages=gnome-shell%2C+gnome-panel%2C+cinnamon%2C+xfce4-panel%2C+kde-workspace-bin&show_vote=on&want_percent=on&want_legend=on&want_ticks=on&from_date=2015-01-01&to_date=2015-06-14&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 https://qa.debian.org/popcon-graph.php?packages=gnome-shell%... Popcon statistics are notoriously hard to interpret though so a large pinch of salt needed. https://joeyh.name/blog/entry/the_popcon_problem/ https://joeyh.name/blog/entry/the_popcon_problem/
- nly 11y ago
  Here's a question: why isn't there a de facto desktop independent password/key/secret manager for Linux? The Linux kernel has userland crypto apis built-in, why aren't we using them? At most, only the manager/permissions UI should be desktop dependent.
__mp 11y ago
I haven't looked at the caller code but are you sure that only the cookie code is using this function? The function looks pretty generic and it might be used somewhere else as well...
xiaq 11y ago
In related news, if you don't have a key and a lock, you cannot really lock a door.
memborg 11y ago
mmmmhhhh. Salted peanuts
bhaavan 11y ago
Well, atleast it goes well with the salt.
elchief 11y ago
Linux -> Linus -> (Charles Schultz) Peanuts-> peanut?
- icebraining 11y ago
  I'd guess https://en.wikipedia.org/wiki/Salt_Peanuts https://en.wikipedia.org/wiki/Salt_Peanuts instead.
Donaldino 11y ago
Best way to use unlock wifi password software on your device : http://www.unlockphonetool.com/unlock-wifi-password-software-free-download/ http://www.unlockphonetool.com/unlock-wifi-password-software...

111 points by TjWallas 11y ago

mschuster91 11y ago

Well without having a user-specified master password like firefox has, you're bound to use some "pseudosecret" keys.

vbezhenar 11y ago
You can use unique password stored in the protected system storage (like OS X Keychain) so at least user is protected from non-root users.
- RubyPinch 11y ago
  shouldn't that protection already exist just in the file permissions of the cookie storage? this doesn't really protect much from other users since other users don't have access to the file in the first place, and doesn't protect from the user that owns the browser process. which is probably why the bug still exists, adding a randomly generated key only adds another easily passable obstacle
  - nly 11y ago
    File permissions can be bypassed by anyone who gets physical access once, encryption can't.
  - vbezhenar 11y ago
    I have user vbezhenar. I run browser under that user. I have system storage for sensitive data. Its data available only via API which checks permissions. E.g. only Chrome can access its data. Chrome must be able to read its cookies, so cookies file must be readable/writeable for user vbezhenar. And there are high chances that I'll run malware program under this user vbezhenar too, so it can read cookies file, but it won't be able to access encryption password.
justinschuh 11y ago
System credential managers are the established way to do this properly. They are user configurable, generally maintain credentials in a separate security context, derive a strong key from the user logon credential, can more easily support hardware security mechanisms, and introduce minimum user friction by default. That's why Chrome and most browsers prefer the system credential managers when available (on Linux: libsecret, Gnome Keyring, or KWallet). The application specific "master password" is more of an anti-pattern for effective credential storage. The most glaring issue is that user friction is so high that it's rarely ever enabled, because it's just too inconvenient and confusing for most people. But beyond that it has the weaknesses typical to any credential manager not deeply integrated into the OS (e.g. credential management is handled entirely in the user's context, management is inconsistent between applications, etc.).
- mschuster91 11y ago
  I don't get the advantage of system credential managers - at least as long as the user is logged on, I can always hook myself into a browser process and retrieve the passwords. The only advantage system-level password storage has is when the attacker e.g. wants to get the passwords from a forensic image or such.

userbinator 11y ago

I guess a lot of others are also wondering, "What's the point?" If an attacker can read the file the cookies are stored in, you have already lost. It even mentions "obfuscation" - which might be a slight obstacle if this was closed-source - but Chromium is open-source.

bbrazil 11y ago
Obfuscation is still useful. For example if a sysadmin is investigating a problem they're less likely to accidentally see a user's data in human-readable form, it also provides a level of defence against unsophisticated attackers.
- deleted 11y ago
  [deleted]
  - detaro 11y ago
    They are talking about obfuscating the stored data, not the code.
justinschuh 11y ago
The obfuscation isn't really intentional IIRC. It's an artifact of the assumption that a proper base credential will be available from either libsecret, Gnome Keyring, or KDE Wallet. The fixed key is just a placeholder that gets used when none of those secure mechanisms is installed on the system. Although, that file has a number of outdated comments, which add to the confusion.

TjWallas 11y ago

Some more details from the source: Password is: "peanuts" Salt is: "saltysalt" Algorithm used: AES-128-CBC The number of KDF iterations is: 1 Edit: Indicate that no. of iterations is for the Key Derivation Function

tgb 11y ago
I don't know too much about this so I'm a bit confused. What does a salt do if it's the same for everything?
- tinco 11y ago
  Nothing, it's just that the field is required for the function that's being used for the obfuscation. There's a lot of confused people in this thread. There are no mistakes made in the code, people are simply surprised that there's a mode in which Chromium that only obfuscates the keystore. Adding to the confusion is the fact that they're using an encryption library to do the obfuscation, so people see it and expect there to be real encryption going on and then see the dummy values in the important fields.
  - tgb 11y ago
    Okay, I was wondering if something like that was the case.
- 001spartan 11y ago
  Using a salt ensures that an attacker cannot use pre-generated rainbow tables to crack something. If there is no salt, it is very fast to use rainbow table lookups for cracking. The salt doesn't really need to be secret, as it is only there to make an attacker work harder. However, the existence of a known, hardcoded salt means that an attacker can generate rainbow tables specifically for cracking these cookies, so the salt isn't really useful here.
  - cwyers 11y ago
    Salts are almost never secret, in fact; typically the salt is stored in plaintext alongside the hashed password. As you note, that's because the salt is supposed to defeat pre-computed rainbow tables, not be a shared secret.

Navarr 11y ago

"ksalt - at least salt is a variable, surely it at least is randomly generated, right?" > // Salt for Symmetric key derivation. > const char kSalt[] = "saltysalt";

verandaguy 11y ago
Reading this was like seeing a ray of hope being shot down by a minigun. In seriousness, what gives!? Why are these so simple? Surely a development base as large as Chromium's could pick up on something like this.
- sirclueless 11y ago
  It's a good software development principle. Make things that are secure look secure. Make things that are insecure look insecure. This is going to be insecure no matter what precautions are taken, because the source is open and the key is part of the binary, so it should look exactly as insecure as it is so no one assumes anything untrue about this code.
dchest 11y ago
Obviously, there is no point in using a random salt when your key is public. There will be no point in using salt when they generate a random secure key ("We need to improve this password situation by moving a secure password into a system-level key store.") To be fair, there's no point in key derivation at all if the goal is to have a fixed or randomly generated key, so I don't know what they were thinking. Unless this password is provided by user.

teraflop 11y ago

This is misleading. If you follow the links to the Chromium bug tracker, you'll note that Chrome integrates with the GNOME and KDE encrypted password managers when they're available. If they're not, it falls back to storing passwords itself with obfuscation, which is the best it can do. (On Windows and OS X, it uses CryptProtectData and the Keychain API, respectively.) https://code.google.com/p/chromium/wiki/LinuxPasswordStorage https://code.google.com/p/chromium/wiki/LinuxPasswordStorage

__mp 11y ago
I wonder how many people are using KDE or Gnome these days. I'm pretty sure I'm using something other than KDE and Gnome on my Linux installs.
- keithpeter 11y ago
  Debian Popularity Contest can tell you a few things... Just over half of those participating have installed Gnome/KDE/Cinnamon https://qa.debian.org/popcon-graph.php?packages=gnome-shell%2C+gnome-panel%2C+cinnamon%2C+xfce4-panel%2C+kde-workspace-bin&show_installed=on&want_percent=on&want_legend=on&want_ticks=on&from_date=2015-01-01&to_date=2015-06-14&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 https://qa.debian.org/popcon-graph.php?packages=gnome-shell%... And it looks as if about a quarter totally are using Gnome/KDE/Cinnamon regularity (rest could be switched off of course!) https://qa.debian.org/popcon-graph.php?packages=gnome-shell%2C+gnome-panel%2C+cinnamon%2C+xfce4-panel%2C+kde-workspace-bin&show_vote=on&want_percent=on&want_legend=on&want_ticks=on&from_date=2015-01-01&to_date=2015-06-14&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 https://qa.debian.org/popcon-graph.php?packages=gnome-shell%... Popcon statistics are notoriously hard to interpret though so a large pinch of salt needed. https://joeyh.name/blog/entry/the_popcon_problem/ https://joeyh.name/blog/entry/the_popcon_problem/
nly 11y ago
Here's a question: why isn't there a de facto desktop independent password/key/secret manager for Linux? The Linux kernel has userland crypto apis built-in, why aren't we using them? At most, only the manager/permissions UI should be desktop dependent.

__mp 11y ago

I haven't looked at the caller code but are you sure that only the cookie code is using this function? The function looks pretty generic and it might be used somewhere else as well...

xiaq 11y ago

In related news, if you don't have a key and a lock, you cannot really lock a door.

memborg 11y ago

mmmmhhhh. Salted peanuts

bhaavan 11y ago

Well, atleast it goes well with the salt.

elchief 11y ago

Linux -> Linus -> (Charles Schultz) Peanuts-> peanut?

icebraining 11y ago
I'd guess https://en.wikipedia.org/wiki/Salt_Peanuts https://en.wikipedia.org/wiki/Salt_Peanuts instead.

Donaldino 11y ago

Best way to use unlock wifi password software on your device : http://www.unlockphonetool.com/unlock-wifi-password-software-free-download/ http://www.unlockphonetool.com/unlock-wifi-password-software...