Security analysts have found a severe security vulnerability in the desktop app for Microsoft Teams that gives threat actors access to authentication tokens and accounts with multi-factor authentication (MFA) turned on.
Disk encryption covers the “dude swiped my laptop” attack vector but not the malicious npm package (or whatever) attack vector.
There isn’t a perfect security in the face of arbitrary malware, but we have OS key stores for good reason. For example, macOS keychain is encrypted by the SEP, and access to the data requires user authentication on a case by case basis when set correctly. It is not possible for any software at any privilege level to bypass it.
But the malicious npm package can just read whatever key the app reads then decrypt the values. They are running with the same permission.
The only thing that really improves this is per-app sandboxing but if you are sandboxing the app then it shouldn’t be able to read any arbitrary files out of your home directly anyways.
Keychains are an improvement but not much. 99% of users will just unlock the keychain upon login so it doesn’t really provide much benefit. Unsandboxed apps are indistinguishable to the keyring daemon so they can just request one anothers’ keys. (Maybe windows or mac has some codesigning magic so that the keyring daemon knows the identity of the app at a finer grain than the user level? but at this point we are really just back to sandboxed apps).
Basically there is nearly no point to most apps to doing anything special to store sensitive files. If your app is secure enough that the user will be happy to unlock the keychain on every app launch sure. But that is a nearly non-existent use case. In general the OS should just provide secure storage as the default. For sandboxed apps they won’t have access to each others storage unless explicitly granted, for non-sandboxed apps there isn’t much you can do besides obscurity.
Do you have links to “set up properly”. The problem is that for most systems other than maybe some of the “app store” type setups the OS has not concept of “application”. The credentials are just the user and that is the same for all unsandboxed apps.
Here’s an example of controlling access on per application basis with macOS keychain. The basic concept here is that the OS controls access to sensitive data, and applications can have individual stores associated with them. This allows control over what application can access a particular piece of data in the store.
That just seems to be about granting an app access to all keys, which is not quite the same as per-app keys.
I know that macOS has this for sandboxed apps from the app store, maybe they have it for “sideloaded” apps as well but at least most OSes don’t have that. At least for Windows and Linux there isn’t a good way to identify an “app” to separate it from any other. My macOS knowledge is rusty but IIRC you install apps in a system-owned directory and apps only have permission to update themselves so maybe you could use the application path as a key, but the other listed affected OSes don’t have that.
Disk encryption covers the “dude swiped my laptop” attack vector but not the malicious npm package (or whatever) attack vector.
There isn’t a perfect security in the face of arbitrary malware, but we have OS key stores for good reason. For example, macOS keychain is encrypted by the SEP, and access to the data requires user authentication on a case by case basis when set correctly. It is not possible for any software at any privilege level to bypass it.
But the malicious npm package can just read whatever key the app reads then decrypt the values. They are running with the same permission.
The only thing that really improves this is per-app sandboxing but if you are sandboxing the app then it shouldn’t be able to read any arbitrary files out of your home directly anyways.
Keychains are an improvement but not much. 99% of users will just unlock the keychain upon login so it doesn’t really provide much benefit. Unsandboxed apps are indistinguishable to the keyring daemon so they can just request one anothers’ keys. (Maybe windows or mac has some codesigning magic so that the keyring daemon knows the identity of the app at a finer grain than the user level? but at this point we are really just back to sandboxed apps).
Basically there is nearly no point to most apps to doing anything special to store sensitive files. If your app is secure enough that the user will be happy to unlock the keychain on every app launch sure. But that is a nearly non-existent use case. In general the OS should just provide secure storage as the default. For sandboxed apps they won’t have access to each others storage unless explicitly granted, for non-sandboxed apps there isn’t much you can do besides obscurity.
No, it cannot because apps cannot just reach into memory of other apps and keychain access has permissions per application.
How does the keychain know what “application” is calling it?
If set up properly then each application has its own private store that it registers with the keychain. This isn’t exactly rocket science.
Do you have links to “set up properly”. The problem is that for most systems other than maybe some of the “app store” type setups the OS has not concept of “application”. The credentials are just the user and that is the same for all unsandboxed apps.
Here’s an example of controlling access on per application basis with macOS keychain. The basic concept here is that the OS controls access to sensitive data, and applications can have individual stores associated with them. This allows control over what application can access a particular piece of data in the store.
That just seems to be about granting an app access to all keys, which is not quite the same as per-app keys.
I know that macOS has this for sandboxed apps from the app store, maybe they have it for “sideloaded” apps as well but at least most OSes don’t have that. At least for Windows and Linux there isn’t a good way to identify an “app” to separate it from any other. My macOS knowledge is rusty but IIRC you install apps in a system-owned directory and apps only have permission to update themselves so maybe you could use the application path as a key, but the other listed affected OSes don’t have that.
I’m not familiar with windows, but here’s an example of how secrets management works on Linux.