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

41–50 of 59 posts

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

#41

Post by mschuster91 »

justinschuh wrote: post #36
mschuster91 wrote: post #5

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

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: lib…

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.

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

#42

Post by 001spartan »

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?

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.

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

#43

Post by asuffield »

kuschku wrote: post #40
carussell wrote: post #39

Earlier quoted context omitted.

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

About the first thing: he means that Google stores them in a way so that they can access the data – instead of doing end to end crypto with a password derived key.

It's only true because he's stuck the words "by default" in there. The button to set a password-based key is in the menu and then it does end-to-end crypto.

If you don't give it a key, it does the best it can with an impossible problem.

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

#45

Post by mhogomchungu »

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.

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

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

#46

Post by zanny »

mhogomchungu wrote: post #45
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.

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

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

#47

Post by kuschku »

asuffield wrote: post #43
kuschku wrote: post #40

Earlier quoted context omitted.

About the first thing: he means that Google stores them in a way so that they can access the data – instead of doing end to end crypto with a password derived key.

It's only true because he's stuck the words "by default" in there. The button to set a password-based key is in the menu and then it does end-to-end crypto. If you don't give it a key, it does the best it can with an impossible problem.

Technically, due to having a Google Account, there would be a way for that.

And if you set a master password for Chrome mobile, you can still access everything without this password on desktop chrome, and in reverse.

As you are logged into your Google account anyway, though, they should just use your account identifier as seed for the key if no other option is available.

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

#48

Post by rmrfrmrf »

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.

Mmk.

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

#49

Post by wtbob »

carussell wrote: post #39
wtbob wrote: post #32

Earlier quoted context omitted.

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

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

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

They store that information such that they can read it. Yes, it may actually be encrypted with a key they have access to, but it's effectively plaintext because they can read it.

> > Mozilla utterly destroyed the security of their sync system

> You're going to need to qualify that statement.

https://blog.mozilla.org/services/2014/04/30/firefox-syncs-n...

Your master key is stored on their servers, encrypted with a key derived from your password. That's pretty bad already, since user-memorable passwords are highly susceptible to guessing. It gets worse though, since they use Mozilla-served JavaScript to log you into your Firefox account—which means Mozilla could choose to serve someone different JavaScript and steal his password.

All it would take is a court order, and they could be forced to do it.

Post reply on HN