Exactly. It reminds me of that PostgreSQL CVE issue recently discussed, where the security breach was that someone with admin privileges on a PostgreSQL instance could execute code as the postgres user.
People fail to consider the threat model in some of these cases.
It is sort of an issue. If anyone has an unencrypted disk and gets their computer stolen but not their login password, they would have access to their token when it's stored unencrypted, but if it were stored encrypted, they wouldn't have access to it. Atlassian's response is basically a cop-out. I've barely used Electron but I know about node-keytar.
SSH keys can be encrypted even if the disk isn't encrypted, and the password in /etc/passwd is usually hashed and will take a lot of guesses to crack if they have a good password.
If they steal your unencrypted laptop and you are logged in to your GMail in the browser, they can even access that and reset your password on any account you have.
Rightly, this is not part of the threat model for Trello.
I believe you're mistaken. They would need your password to boot up the computer or unlock your screen. I think the cookies on Chrome are encrypted using the same mechanism as node-keytar. I didn't say anything about stealing a laptop while it's logged in. I just mean physically stealing the laptop.
You could argue that the number of people who protect their computer by password but don't encrypt their disks is too small or isn't worth worrying about. But I know that there is a significant portion of users that has it set up this way.
If your disk is unencrypted, all I need to do is mount your disk on my computer and point my Chrome user disk to /mnt/stolen_drive/home/users/James/chrome_data and I have all your cookies.
I'm not sure about Linux, but on Windows this is trivial. If you are concerned about this attack vector, then encrypt this drive. If you are hit by an RCE, then your Trello keys are the least of your problems.
iOS stores app tokens in plaintext, on an encrypted disk.
If your disk is unencrypted, every session token in your browser can be stolen and used to impersonate you, on services such as GitHub, Google, and others.
There are no excuses for using an unencrypted disk for session token storage, whether in-browser or in-application or other.
The Atlassian response isn't great. But if you want to stay logged in beyond the process lifetime, that means storing the value on disk in a way that the software can read and use.
The only way to protect that sort of token from disk access is to tie it into some secret storage that is protected with a strong credential -- either a TPM tied key store, or full disk encryption. Otherwise, I can encrypt it all day long, but I'll have to store the key somewhere I can read it, which is fairly well useless -- someone reading your disk who can read the encrypted token is going to be able to read the key as well.
On linux, I use ssh-agent. My key at ~/.ssh/id_rsa is encrypted.
When my shell starts, it boots ssh-agent (add "eval `ssh-agent`" to your ~/.bashrc)
Still in the shell boot, it tries to add the ssh key to the keychain (add "ssh-add" to your ~/.bashrc), and it asks for my private key password. Once I enter the password, my key is unlocked for as long at ssh-agent is running (usually until I shut down my computer).
My password is a long, I only need to enter it once a day so it's not really a problem. You can add multiple keys to the ssh-agent (ssh-add mykey.pem). The private key must have these permissions: 0400 (chmod 0400 mykey.pem).
Seeing that electron application code can easily be inspected inside the asar container (I.e. you can't trust the client) :
How would you approach the problem to encrypt secrets locally? The only approach I could come up with involves receiving a symmetric key from a server with certificate pinning, but even that seems quite insecure).
I'm planning an offline-capable PWA, and I've spent a fair bit of time worrying about how to store credentials/tokens for my pouchdb backend. Is there, in fact, an established best practice for this? I looked, but couldn't find anything compelling.
Either your application requires an in-memory-only decryption password at each start, or it requires a plaintext cached-on-disk decryption password for headless startup, or it requires a hardware security module (HSM) through which all encrypted storage requests are routed for decryption.
Encrypted filesystems are necessary for #2 to be safe, but merely move the problem of #1 up one step in the chain to OS boot rather than app boot. #3 isn't necessarily safe as the HSM could be used to decrypt data when an attacker has gained access and is undiscovered, unless you use it to issue a temporary decryption key at OS/app boot, at which point you're effectively back to #1 again.
In practice, if you're a server application author, either use the secure credentials storage service offered by your cloud provider or store your secure tokens encrypted on-disk with the decryption key either stored in a local config file elsewhere or entered at app startup.
I'm the creator / maintainer of a widely used authentication library, and I also don't know the answer to this.
There have been several issues reported around this, but no one seems to have a good proposal for a solution.
I've also discussed this with security auditors from Cobalt (because they flagged it as an issue), but they also did not propose any solutions (other than using httpOnly cookies instead of tokens, which doesn't really address the issue).
This is a surprisingly complicated issue present in a great many applications.
At first, it seems that there is not much to see here. Generally speaking, there is no way that the token could be encrypted that would not still allow decryption for anyone with read access to the disk (that is, the decryption key will itself need to be stored somewhere on disk). This is what Trello support's response is getting at.
However, there are exceptions to this situation, since most operating systems now provide some kind of storage protected by the OS at a higher level (OS X keychain, Windows DPAPI and other similar functionality). In some cases, these facilities are even backed by hardware capabilities (e.g. TPM, secure element) that provide a high level of assurance. They tend to be frustratingly platform-specific and come with a laundry list of limitations though.
So, what about this case? The reporter compares to Chrome, and that's an important comparison. At least on Windows, Chrome does use DPAPI to encrypt user cookies.
But, now there's bad news again. Since operating systems do not generally provide a good way to associate these kinds of secrets exclusively with any given application (once again, there are ways to do this, but they come with even more limitations and are not very common), the exact same situation usually holds! Any application running on the machine at the same privilege level, which tends to be most applications, can probably still get the key needed to decrypt the cookies (e.g. via calling out to DPAPI). OS X is better at locking this down than Windows, but still far from perfect. It's hard to make a blanket statement about Linux because there are many such systems available and none of them are particularly commonly used - on average, I would assert that the situation is worse than on Windows, SELinux notwithstanding for the ten people that use it on their workstation (the same capability is available on Windows but not widely used for the same reasons that SELinux is not widely used).
There is a security advantage to using these types of facilities, as they are generally good at enforcing that anything trying to read a secret is running as the correct user, including things like using the user's account credentials as part of the key material. This provides protections against things like processes running as other users or even on other computers with access to the storage device (say, a stolen hard disk).
But, the bottom line is that you go from "any process with read access to the disk can gain access to the secret" to "any process running as the same user with access to the disk can gain access to the secret." This is better, but not nearly as much better as we'd all hope for... the most common case is still not effectively protected against.
At the end of the day: if it is possible to for any application to read the data from disk without getting additional external key material (e.g. a user entering their password every time), assume that any application with access to the disk can get it. There are ways to make this harder, and in narrow cases even ways to make it exceedingly difficult, but when it comes to bypassing operating system protections, where there's a will there's a way. Measures as unsophisticated as "encrypt the data and then store the key in a file elsewhere in the file system" are remarkably common and so ineffective as to probably be dangerous by giving false confidence.
It's worth noting that this is true of desktop systems and servers.
Mobile operating systems have per-app sandboxing and per-app storage, not just per-user. But in that case, you probably don't need any more storage encryption than the OS already provides by default.
My guess is this will eventually be fixed by running older apps in separate containers (like how Linux runs on Chromebooks and Windows.)
FWIW, SELinux is probably more widespread than you think. Fedora desktop is pretty popular, and has shipped with SELinux enabled by default for a while now. Now whether it has a usefully locked down ruleset for the scenario at hand, I couldn't say.
I'm just going from my personal experience here, but I think on platforms with SELinux enabled (mostly just RHEL derivatives) most people are using unconfined web browsers. SELinux is tricky because you can enable it and still have it do very little or even nothing, and this tends to be the case on desktop distributions. If you install Firefox manually to get a recent version or install Chrome at all, then you most likely don't have policy for them and they're running unconfined, and so are their files (besides the policy that all other applications are likely to share).
This wouldn't be so much of a concern if they offloaded encrypting the cookies to some kind of security service that would be sensitive and so almost certainly have strict SELinux policy around it, but at least Chrome on Linux implements the encryption itself using a flimsy hardcoded key. It's hard to blame them, because there isn't really an option to offload secret-keeping in Linux that is uniformly available and usable.
I suppose the reason this token is not encrypted is because supporting offline data access would mean there's some private key on the computer -- and the same read access that exposed this token would expose that key.
Is the Trello offline data at rest encrypted in any way?
The real question is - how do you handle this in any electron app? Anyone who can access your laptop/computer will be able to retrieve that token because the token needs to be stored somewhere! Has anyone implemented this before and how did you implement it?
"It rather involved being on the other side of this airtight hatchway" ?
https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...