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

https://code.google.com/p/chromium/codesearch#chromium/src/components/os_crypt/os_crypt_posix.cc&q=peanuts&sq=package:chromium&type=cs&l=40

by TjWallas • 11 years ago

111 55 11 years ago

code.google.com

TjWallas• 11 years 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

tgb2• 11 years 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?

tinco2• 11 years 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.

001spartan• 11 years 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.

dchest2• 11 years ago

There's no such thing as AES-CBC iterations, it's the number of iterations for PBKDF2-HMAC-SHA1.

samch• 11 years ago

I don't care what anybody says. I still like salted peanuts.

Navarr• 11 years 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• 11 years 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• 11 years 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.

dchest2• 11 years 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.

mschuster912• 11 years ago

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

vbezhenar2• 11 years 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• 11 years 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

justinschuh3• 11 years 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.).

mschuster912• 11 years 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• 11 years 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• 11 years 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.

justinschuh3• 11 years 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.

teraflop• 11 years 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

__mp2• 11 years 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• 11 years 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%...

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%...

Popcon statistics are notoriously hard to interpret though so a large pinch of salt needed.

https://joeyh.name/blog/entry/the_popcon_problem/

nly3• 11 years 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.

krakensden• 11 years ago

There is- it's called libsecret, and it's used as a cross-platform backend for both the Gnome & KDE secret managers, which are 'just' guis for it. I don't actually know if it uses the Linux kernel's apis, but it's supposed to do a pretty good job.

tinco2• 11 years ago

I wonder if there's a definitive list somewhere of what features operating systems should have in order to be proper for running a generic server or desktop.

There's so many blurry lines there. I agree that a secret store is best done as a system level service, but it's so hard to standardize on one api, and yet so easy for a shitty one to become de facto (I.e. X.org).

jryan49• 11 years ago

I use pass and pass-dmenu since I don't use a DE. http://www.passwordstore.org/

justinschuh3• 11 years ago

That's a bit out of date, because libsecret is supported as well: https://code.google.com/p/chromium/codesearch#chromium/src/c...

But yeah, it pretty much looks for any sort of secure credential manager and falls back to the fixed key only when nothing is available.

wtbob2• 11 years ago

If they're not, it falls back to storing passwords itself with obfuscation, which is the best it can do.

No, the best it could do is to have a master password, provided at launch.

I'm really concerned about the extent to which neither Google nor Mozilla actually cares about user security. No plaintext password should ever live somewhere outside of the user's head; no password encrypted with a user-memorable password should live outside of a computer under the user's physical control. Thus, passwords (and other private data) on remote systems should always be encrypted with secure keys, themselves generated on the user's device and encrypted on his device with his memorable password.

The facts that by default Google will store your website and WiFi passwords (along with your emails and pictures) in plaintext on their servers, and that Mozilla utterly destroyed the security of their sync system, are utterly sickening.

newuser882732• 11 years ago

Expecting privacy (or privacy-preserving security) from Google products has always been folly.

Mozilla used to be different. However, when Brendan was purged, first doubts may have arisen. Now that we also see cyber-bully Klabnik on their payroll, the probability has risen sharply that Mozilla has been successfully subverted into a political pressure group.

Since Mozilla now is enrolled in support of the dominant ideology, it has no incentive for supporting privacy anymore, either: The dominant ideology wants minority opinion holders to be outed and ostracised.

carussell• 11 years ago

Google will store your website and WiFi passwords (along with your emails and pictures) in plaintext on their servers

You're going to need to qualify that statement.

Mozilla utterly destroyed the security of their sync system

You're going to need to qualify that statement.

erikb• 11 years ago

I'm not good at security stuff, but is a hardcoded password not much worse than any string written to some kind of config database but that is different for every program installation or system user?

sorbits• 11 years ago

It’s about the same, as anyone would be able to read the generated password from the config database (since where to store it would still be hardcoded in the binary).

__mp2• 11 years 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• 11 years ago

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

memborg• 11 years ago

mmmmhhhh. Salted peanuts

bhaavan• 11 years ago

Well, atleast it goes well with the salt.

elchief• 11 years ago

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

icebraining2• 11 years ago

I'd guess https://en.wikipedia.org/wiki/Salt_Peanuts instead.

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

Related Stories