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

51–59 of 59 posts

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

#51

Post by erikb »

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'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?

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

#52

Post by mhogomchungu »

zanny wrote: post #46
mhogomchungu wrote: post #45

Earlier quoted context omitted.

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…

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…

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

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

#53

Post by sorbits »

erikb wrote: post #51
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'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?

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

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

#54

Post by icebraining »

newuser88273 wrote: post #38
lolpep8 wrote: post #37

Earlier quoted context omitted.

How could I not think of that! Hiring a kind of SJW-ey guy to write Rust docs is just a small step in the direction of clear-text passwords and the removal of HTTPS from Firefox. Better switch to Gnome Web, then.

If Mozilla was a-political, Klabnik couldn't work there if Brendan couldn't. He can, and Mozilla isn't. Actually, the politicalization of Mozilla means that everything technical will lose priority over time.

There's no such thing as an apolitical organization; their very structure is based on underlying political beliefs.

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

#56

Post by cwyers »

001spartan wrote: post #42
tgb wrote: post #10

Earlier quoted context omitted.

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?

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 t…

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.

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

#58

Post by tgb »

tinco wrote: post #18
tgb wrote: post #10

Earlier quoted context omitted.

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…

Okay, I was wondering if something like that was the case.

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

#59

Post by vbezhenar »

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

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.

Post reply on HN