31–40 of 45 posts
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...
People fail to consider the threat model in some of these cases.
Earlier quoted context omitted.
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 ga…
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.
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.
Earlier quoted context omitted.
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.
> 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 mo…
Earlier quoted context omitted.
> 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 mo…
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."
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.
Earlier quoted context omitted.
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."
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.
> 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.
Earlier quoted context omitted.
The private keys in .ssh can be stored encrypted. I do that, and store the decryption key in macOS keychain.
Can you share how to achieve this?
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).
Earlier quoted context omitted.
You almost certain should be storing your keys encrypted with a decent passphrase.
And if you want headless access this passphrase will be stored unencrypted. This is nothing more than security Kabuki theater.
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. Howev…
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.
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.
Earlier quoted context omitted.
And if you want headless access this passphrase will be stored unencrypted. This is nothing more than security Kabuki theater.
Well, yeah, some keys must be unencrypted to be useful. But in a lot of cases you can and should encrypt your keys used to do manual stuff.
(ask for passphrase -> decrypt auth token -> Access API)