This is hilarious and exactly what I would expect from Microsoft.
And that a few days after the load of GIFShell vulnerabilities. But nah, no need to patch anything.
Really odd that it doesn’t use the recommended credential storage APIs on Windows at least
I’m so glad I’m not forced to use this garbage. Microsoft can’t do anything right.
What a great time to use BSD!
From the same people who made it trivial to crack their system passwords in the early 2000’s
I don’t get it. Of course the app stores these in cleartext, the app needs to access them to login. Sure it could encrypt it but that is just obscurity, the key would have to be stored to somewhere the app has access to for it to use the tokens.
The article doesn’t seem to say that these were world-readable or otherwise visible to other users. So this seems like mostly a non-story. Use full disk encryption and you’ll be fine.
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.
But the malicious npm package can just read whatever key the app reads then decrypt the values. They are running with the same permission.
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.
