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

21–30 of 59 posts

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

#21

Post by nly »

RubyPinch wrote: post #12
vbezhenar wrote: post #9

Earlier quoted context omitted.

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

File permissions can be bypassed by anyone who gets physical access once, encryption can't.

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

#22

Post by krakensden »

nly wrote: post #17
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.

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.

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

#23

Post by nly »

krakensden wrote: post #22
nly wrote: post #17

Earlier quoted context omitted.

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.

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.

KWallet in KDE4 doesn't seem to be using libsecret. Is this a KDE 5.x thing?

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

#24

Post by tinco »

nly wrote: post #17
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.

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

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

#25

Post by justinschuh »

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…

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.

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

#26

Post by dd9990 »

nly wrote: post #23
krakensden wrote: post #22

Earlier quoted context omitted.

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.

KWallet in KDE4 doesn't seem to be using libsecret. Is this a KDE 5.x thing?

It's being called KSecret Service afaik (https://barlog.rusu.info/valentin/blog/?p=411).

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

#28

Post by justinschuh »

userbinator wrote: post #6

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.

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.

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

#29

Post by jryan49 »

nly wrote: post #17
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.

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

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

#30

Post by keithpeter »

__mp wrote: post #16
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.

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/

Post reply on HN