Trello Desktop Application Stores Authentication Token in Plain Text

Trello Desktop Application Stores Authentication Token in Plain Text
medium.com

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.