47 ms·

Trello Desktop Application Stores Authentication Token in Plain Text

37 points by murugaviki 7y ago

jcrawfordor 7y ago
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 7y ago
  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 7y ago
    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.
- skybrian 7y ago
  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.)
NewsAware 7y ago
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 7y ago
  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.
asadlionpk 7y ago
I don't think this is an issue. As rightfully responded by Atlassian.
- benatkin 7y ago
  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 7y ago
    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.
    - skybrian 7y ago
      It looks like Trello supports Yubikeys? What's the threat model there?
      - dullgiulio 7y ago
        Support != require
    - benatkin 7y ago
      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.
baronswindle 7y ago
I might be an idiot to ask this, but how is this different from the AWS CLI storing IAM keys in ~/.aws/credentials ?
- jbverschoor 7y ago
  Or the private keys in ~/.ssh?
  - javagram 7y ago
    The private keys in .ssh can be stored encrypted. I do that, and store the decryption key in macOS keychain.
    - poyu 7y ago
      Can you share how to achieve this?
      - simlevesque 7y ago
        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 7y ago
        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.
      - 7y ago
andrewflnr 7y ago
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.
- lynndylanhurley 7y ago
  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).
- progval 7y ago
  https://news.ycombinator.com/item?id=20347205 https://news.ycombinator.com/item?id=20347205
- floatingatoll 7y ago
  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.
outworlder 7y ago
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=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
- stingraycharles 7y ago
  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
carlhjerpe 7y ago
Is there any other solution than allowing users to set a "local masterpass"? I mean even lastpass is vulnerable to this while unlocked right?
orliesaurus 7y ago
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?
greenpizza13 7y ago
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?

37 points by murugaviki 7y ago

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 7y ago
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 7y ago
  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.
skybrian 7y ago
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.)

NewsAware 7y ago

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

asadlionpk 7y ago

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

benatkin 7y ago
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 7y ago
  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.
  - skybrian 7y ago
    It looks like Trello supports Yubikeys? What's the threat model there?
    - dullgiulio 7y ago
      Support != require
  - benatkin 7y ago
    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.

baronswindle 7y ago

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

jbverschoor 7y ago
Or the private keys in ~/.ssh?
- javagram 7y ago
  The private keys in .ssh can be stored encrypted. I do that, and store the decryption key in macOS keychain.
  - poyu 7y ago
    Can you share how to achieve this?
    - simlevesque 7y ago
      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 7y ago
        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.
    - 7y ago

andrewflnr 7y ago

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.

lynndylanhurley 7y ago
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).
progval 7y ago
https://news.ycombinator.com/item?id=20347205 https://news.ycombinator.com/item?id=20347205
floatingatoll 7y ago
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.

outworlder 7y ago

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=31283 https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...

stingraycharles 7y ago
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

carlhjerpe 7y ago

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

orliesaurus 7y ago

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?

greenpizza13 7y ago

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?