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

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

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

[skybrian]

It looks like Trello supports Yubikeys? What's the threat model there?

[dullgiulio]

Support != require

[floatingatoll]

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.

[benatkin]

The key part is on an encrypted disk. That makes a big difference.

node-keytar has support for encryption on an unencrypted disk. Lose the password and you're locked out.

[toast0]

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.