Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

code.google.com

Post reply on HN
Print view View original

11–20 of 59 posts

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

#11

Post by dchest »

Navarr wrote: post #3

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

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.

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

#12

Post by RubyPinch »

vbezhenar wrote: post #9
mschuster91 wrote: post #5

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

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.

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

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

#13

Post by 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

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

#14

Post by dchest »

TjWallas wrote: post #2

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

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

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

#16

Post by __mp »

teraflop wrote: post #13

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/LinuxPas…

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.

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

#17

Post by nly »

teraflop wrote: post #13

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/LinuxPas…

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.

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

#18

Post by tinco »

tgb wrote: post #10
TjWallas wrote: post #2

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

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?

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.

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

#19

Post by detaro »

[deleted] wrote: post #8
bbrazil wrote: post #7

Earlier quoted context omitted.

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]

They are talking about obfuscating the stored data, not the code.

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

#20

Post by samch »

TjWallas wrote: post #2

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

I don't care what anybody says. I still like salted peanuts.
Post reply on HN