

Key for chromium's encrypted cookies store in Linux is “peanuts” - TjWallas
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

======
teraflop
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)

~~~
nly
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
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.

~~~
mhogomchungu
The biggest issue with libsecret and with KWallet is that once a wallet is
opened by one application,every other application can get all the contents of
that opened wallet.

In GNOME,the wallet is opened by the login manager and that means all the
contents of the wallet are available to all processes run from the logged in
user account.

KDE refused to have the above behavior of the login manager opening the wallet
and hence after login,there must be atleast one application that will have to
open the wallet and then the behavior will be the same as libsecret.

Lots of people who use these two storage systems are not aware of the above.

I dont like the above behavior as i want each application to manage its own
private wallet and i created lxqt_wallet[1] to give me the behavior i want.

The project also supports libsecret and KWallet for those who prefer these
backends.

[1]
[https://github.com/mhogomchungu/lxqt_wallet](https://github.com/mhogomchungu/lxqt_wallet)

~~~
zanny
The UX of kwallet is awful, and everyone I put on KDE I always use a blank
wallet password so they are not badgered by "enter password to unlock wallet"
prompts.

Yes, its insecure to have the user session act as an unlock on a cryptographic
store like that. It looks like lxqt_wallet is even worse on that front in
terms of UX - yes, its more secure for every program to have its own secret
stores and require prompts to unlock them, but average desktop users just want
to login and have _that_ unlock their secret stores, pretty much like Gnome
does it.

What you really want is MAC on secrets. Applications that add to the secrets
database get implicit access to those secrets in the future, but first access
should require user permission before an application can start accessing your
credentials for other accounts. You don't really need anyone to reinput a
password, just prompt users "Kfoo wants to access your account
neckbeard@gmail.com, allow?" with allow / deny choices, or make it an option
in the wallet GUI.

You could probably even integrate it into current MAC solutions. Make it a VFS
somewhere in var, and have your distro ship sane defaults like letting the
sanctioned im client (both are based off telepathy nowadays) access the
secrets store on a whitelist of domains, like @gmail, @chat.facebook.com, etc.

~~~
mhogomchungu
> It looks like lxqt_wallet is even worse on that front in terms of UX - yes,
> its more secure for every program to have its own secret stores and require
> prompts to unlock them, but average desktop users just want to login and
> have that unlock their secret stores, pretty much like Gnome does it.

lxqt_wallet supports 3 backends: kwallet,libsecret and internal one that gives
the behavior i explained above.

Each backend has its pro and cons and the project lets the user pick which one
works best for them.

There need to be a general purpose secure storage system that can accommodate
users who wish to not have their secrets that are meant to be used by only one
application be exposed to all other applications.

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

------
TjWallas
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
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
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
Okay, I was wondering if something like that was the case.

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

~~~
justinschuh
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
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.

------
Navarr
"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
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
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.

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

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

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

~~~
icebraining
I'd guess
[https://en.wikipedia.org/wiki/Salt_Peanuts](https://en.wikipedia.org/wiki/Salt_Peanuts)
instead.

------
bhaavan
Well, atleast it goes well with the salt.

------
memborg
mmmmhhhh. Salted peanuts

