Credential protection in desktop apps, state of the art on each platform, July 2024 edition:<p><i>-- macOS --</i><p>On macOS protecting credentials is easy and effective. You can store secrets in two places:<p>1. In the system keychain. The best place because the keystore database records the code signing identity of each app that creates an entry, and any other app that tries to access those credentials will trigger a permission check by the OS. The permission check window can't be tampered with by other OS processes, nor can your own app be tampered with because the OS will block debugger APIs and also block attempts to overwrite code files on disk. There are APIs for this in whatever framework or language you're using. Browsers protect cookies and local storage for you by using this mechanism (the data is readable on disk but encrypted using a key stored in the keychain).<p>2. If you opted in to the App Sandbox, you can store data in ~/Library/Preferences which is virtualized and redirected to what Apple calls a "container". Apps that try to access files in containers also trigger a permission prompt.<p>As a quick test to prove to yourself this works make sure you're on the latest version of macOS, go into System Settings, Privacy & Security, and ensure that under "full disk access" your terminal app is unchecked. If you toggle it off you'll need to restart the process. Now run e.g. `ls Library/Containers/desktop.WhatsApp/Data` and note you get an permission prompt. This block exists for ALL APPS i.e. every app on macOS is sandboxed even legacy apps and apps that don't opt-in to what Apple confusingly calls the "app sandbox" (they mean something like "stricter app sandbox").<p>Storing credentials is easy on macOS because of the many years of work Apple's security engineers have quietly done, mostly without disruption. Every app on macOS has cryptographically verified identity, which is the hardest part. The rollout of all of this has been so smooth most devs don't even realize how much protection the OS now provides. Let's take a moment to note that this is worthy of serious respect. MacOS is by far the most secure desktop OS out there today, IMHO.<p><i>-- Windows --</i><p>Possible but much harder and mostly undocumented. I haven't yet tried it myself, but it's on the todo list. Firstly, note that protecting credentials from other apps requires the OS to understand app identity i.e. what files belong to an app, who signed them, and then the OS must stop other apps from tampering with those files or the address space of the program that's running. The only supported way to do this on Windows is by packaging and installing your app with MSIX. If you haven't encountered this format before please open my bio, follow the link to my company's product and the user guide will tell you all about it. If you aren't shipping your app with MSIX forget it, there's no way to protect credentials from other apps, only other users using regular file or keychain permissions.<p>If you do use MSIX then it's possible to create directories that only your app can read, but which are still owned by the user i.e. the user can override the protection using Explorer if they want to. The way to do this is far too complicated to explain here unfortunately and involves some serious Windows API voodoo.<p><i>-- Linux --</i><p>As always on Linux, "it depends" but is basically not possible in a widely supported and portable way. Whilst Linux the kernel has all the needed tools, they're not knitted together across the userspace and packaging ecosystem to make it possible. The closest thing to app identity is either SELinux (Red Hat specific more or less) or FlatPaks. Neither is understood by system keychains AFAIK? Debugger APIs aren't really locked down either, and you can't make a directory in $HOME that only a specific FlatPak can read.