
Trello Desktop Application Stores Authentication Token in Plain Text - murugaviki
https://medium.com/@vigneshgovindhan/trello-desktop-application-stores-authentication-token-in-plain-text-14cb7ab2998f
======
outworlder
Isn't this a case of

"It rather involved being on the other side of this airtight hatchway" ?

[https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...](https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31283)

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

[https://news.ycombinator.com/item?id=19659684](https://news.ycombinator.com/item?id=19659684)

------
asadlionpk
I don't think this is an issue. As rightfully responded by Atlassian.

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

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

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

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

Physical access is game over.

~~~
benatkin
You have the encrypted cookies. You can't use the encrypted cookie to login
with gmail.

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...](https://stackoverflow.com/questions/22532870/encrypted-cookies-in-
chrome)

Otherwise there would be no point in such projects as node-keytar.

~~~
nemothekid
> _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](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.

~~~
benatkin
From that page: "If the DPAPI data was encrypted with the logon password, you
have to enter this password in the 'Windows Login Password' field."

~~~
nemothekid
And how many people do you know enter their logon password every time they
start Chrome?

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.

~~~
benatkin
I already went over this. Quoting myself:

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

------
baronswindle
I might be an idiot to ask this, but how is this different from the AWS CLI
storing IAM keys in ~/.aws/credentials ?

~~~
jbverschoor
Or the private keys in ~/.ssh?

~~~
javagram
The private keys in .ssh can be stored encrypted. I do that, and store the
decryption key in macOS keychain.

~~~
poyu
Can you share how to achieve this?

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

~~~
imtringued
I can already see the headline "ssh-agent desktop application stores private
keys in plain text".

There is no solution to the problem of the author beyond demanding a password
on every single interaction.

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

~~~
slantyyz
For some use cases, you can use Keytar ([https://github.com/atom/node-
keytar](https://github.com/atom/node-keytar)) which uses the credential
system/keychain on the OS.

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

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

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

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

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

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

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

------
carlhjerpe
Is there any other solution than allowing users to set a "local masterpass"? I
mean even lastpass is vulnerable to this while unlocked right?

