Key for chromium's encrypted cookies store in Linux is “peanuts”(code.google.com)
code.google.com
Key for chromium's encrypted cookies store in Linux is “peanuts”
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
58 comments
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.
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.
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
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
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 [email protected], 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.
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 [email protected], 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.
> 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.
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.
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).
And it still uses libsecret under the hood.
I use pass and pass-dmenu since I don't use a DE. http://www.passwordstore.org/
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).
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).
> 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 password should live outside of a computer under the user's physical control. Thus, passwords (and other private data) on remote systems should always be encrypted with secure keys, themselves generated on the user's device and encrypted on his device with his memorable password.
The facts that by default Google will store your website and WiFi passwords (along with your emails and pictures) in plaintext on their servers, and that Mozilla utterly destroyed the security of their sync system, are utterly sickening.
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 password should live outside of a computer under the user's physical control. Thus, passwords (and other private data) on remote systems should always be encrypted with secure keys, themselves generated on the user's device and encrypted on his device with his memorable password.
The facts that by default Google will store your website and WiFi passwords (along with your emails and pictures) in plaintext on their servers, and that Mozilla utterly destroyed the security of their sync system, are utterly sickening.
> 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.
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.
> 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.
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.
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.
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.
Expecting privacy (or privacy-preserving security) from Google products has always been folly.
Mozilla used to be different. However, when Brendan was purged, first doubts may have arisen. Now that we also see cyber-bully Klabnik on their payroll, the probability has risen sharply that Mozilla has been successfully subverted into a political pressure group.
Since Mozilla now is enrolled in support of the dominant ideology, it has no incentive for supporting privacy anymore, either: The dominant ideology wants minority opinion holders to be outed and ostracised.
Mozilla used to be different. However, when Brendan was purged, first doubts may have arisen. Now that we also see cyber-bully Klabnik on their payroll, the probability has risen sharply that Mozilla has been successfully subverted into a political pressure group.
Since Mozilla now is enrolled in support of the dominant ideology, it has no incentive for supporting privacy anymore, either: The dominant ideology wants minority opinion holders to be outed and ostracised.
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.
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.
Mmk.
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).
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/
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/
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.
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.
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.
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](1)
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.
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
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.
There's no such thing as AES-CBC iterations, it's the number of iterations for PBKDF2-HMAC-SHA1.
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.
Okay, I was wondering if something like that was the case.
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.
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.
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.
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: 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.).
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.).
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.
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.
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
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.
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.
File permissions can be bypassed by anyone who gets physical access once, encryption can't.
"ksalt - at least salt is a variable, surely it at least is randomly generated, right?"
> // Salt for Symmetric key derivation.
> const char kSalt[] = "saltysalt";
> // 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.
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.
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.
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.
In related news, if you don't have a key and a lock, you cannot really lock a door.
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...
Linux -> Linus -> (Charles Schultz) Peanuts-> peanut?
I'd guess https://en.wikipedia.org/wiki/Salt_Peanuts instead.
Well, atleast it goes well with the salt.
mmmmhhhh. Salted peanuts
https://code.google.com/p/chromium/wiki/LinuxPasswordStorage