11–20 of 45 posts
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…
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.)
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.
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).
"It rather involved being on the other side of this airtight hatchway" ?
https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
I don't think this is an issue. As rightfully responded by Atlassian.
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 th…
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.
Earlier quoted context omitted.
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 th…
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.
I don't think this is an issue. As rightfully responded by Atlassian.
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 th…
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.
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.