Trello Desktop Application Stores Authentication Token in Plain Text
medium.com
medium.com
"It rather involved being on the other side of this airtight hatchway" ?
https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
People fail to consider the threat model in some of these cases.
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.
Rightly, this is not part of the threat model for Trello.
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.
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.
Physical access is game over.
It might only encrypt some of the cookies, but encrypting cookies in such a way that you need to be able to log in or unlock the screen with your password is a thing. https://stackoverflow.com/questions/22532870/encrypted-cooki...
Otherwise there would be no point in such projects as node-keytar.
On Windows, the DPAPI (which node-keytar uses) does not protect against physical access. Here's a nifty GUI tool that is easily found with Google: https://www.nirsoft.net/utils/dpapi_data_decryptor.html
On Windows, DPAPI may protect you against unprivileged code execution, but it will not protect you against a privileged RCE or someone physically mounting your unencrypted hard drive.
I'm not sure what the state of the art in Linux or OS X's keychain is, but I wouldn't be surprised if they don't try to protect against that threat vector as well.
EDIT: I looked into it a bit more, and the particular workaround I was thinking of may have been patched sometime between Windows 8 and Windows 10.
> 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.
It isn't before starting Chrome. It's when unlocking their screen or when starting up their computer.
A typical scenario for having your laptop stolen is being robbed while carrying your laptop in a backpack. If the lid is closed, the screen should be locked, if good password settings were chosen. Better to have the whole disk encrypted, but NSAPI provides some security for those who only have passwords set.
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.
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.
node-keytar has support for encryption on an unencrypted disk. Lose the password and you're locked out.
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).
There is no solution to the problem of the author beyond demanding a password on every single interaction.
(ask for passphrase -> decrypt auth token -> Access API)
The point is, you haven't actually solved the problem. It's not magic. In a 2-system authentication scheme, where headless access is necessary, a key needs to be somewhere in plaintext accessible to the process. You can obfuscate this, or add OS controls, or hardware chips, or ssh-agent, or keystores, or web-services for keys, but it doesn't change this reality.
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).
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).
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.
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.
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.
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.)
Is the Trello offline data at rest encrypted in any way?