5

In Linux, there's a KDE Wallet (and GNOME Wallet) application, that stores passwords and other sensitive data. These wallets by default prevent accidental data access of application other than the one that stored the data.

E.g. if the piece of data was stored by the /bin/app1, then /bin/app2 won't have full access to that data, and the wallet will first ask the user if they really want to allow /bin/app2 to access the data stored by /bin/app1.

I find this feature important for some aspects of local data security for an application I participate in.

On Windows, a somewhat analogous UX is provided by wincred.h, but, as I currently understand, there's no any kind of per-application restrictions in it. It will provide the data access to any application started by the current user, and thus provide less security that the application-scoped defaults of Linux wallets.

Is there any way to achieve a similar application- (or vendor-) scoped security in Windows using only standard APIs?

ForNeVeR
  • 6,726
  • 5
  • 24
  • 43
  • 1
    It depends on the version(s) of Windows you are targeting. In the old days you used DPAPI and prompted the user for optional entropy. The optional entropy could be an app-specific password or PIN. Windows 8 and above has Password Vault. And Windows 10 has Credential Manager. See, for example, [Windows equivalent of OS X Keychain?](https://stackoverflow.com/q/442923/608639) – jww Jun 09 '19 at 18:15
  • One thing to watch out for is, what happens to the wallet or keychain data. OS X 10.10 and above ship it to Apple, so your secrets leave your security boundary. It does not inspire a lot of confidence when Apple, Apple employees, law enforcement and other miscreants have access to your keychain. There's nothing special about Apple. Google and Android does it too. I expect Microsoft also does it. – jww Jun 09 '19 at 18:18
  • @jww I would accept an answer that targets any one of them. Windows 10+ is okay. Regarding the "app-specific password or PIN": in case of Linux wallet apps, the application path itself is such a password, and the wallet infrastructure will make sure the path is right. I'm looking for a similar mechanism that ensures that the app from the outside path (or e.g. from an external vendor) won't be able to access the protected data. I _think_ that would require a third-party (e.g. OS) to verify the path and/or vendor. – ForNeVeR Jun 10 '19 at 03:25
  • OK, so where you are going with this effectively ends at, each app needs to be a security principal, just like a user is a security principal. As far as I know (which may be wrong nowadays), iOS and Android solved it because apps are signed and the public key uniquely identifies the app. So it is closely related to code signing due to some emergent properties. OS X is close because of the sandbox service, but it is opt-in. Linux sounds close in a different way, but it lacks code signing. I have no idea the state of Windows. Someone familiar with the security architecture needs to answer. – jww Jun 10 '19 at 06:13
  • 1
    If you have some time, take a look at Peter Gutmann's *[Engineering Security](http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf)* book. One chapter performs a case study of Apple's keychain, and details the threats and security controls used to contain the threats. Apple does a nice job with their keychain (but they f**k'd up when they started moving it to their iCloud). The evaluation can be your yard stick to measure other solutions and different platforms. – jww Jun 10 '19 at 06:19
  • 2
    Windows security is bound to user accounts. To get per-application security, you'll need to run those applications under separate user accounts. That's what UWP does. – IInspectable Jun 10 '19 at 12:49
  • @IInspectable if I write an UWP application, will its data be accessible from the outside? I understand that other UWP applications won't likely have the access, but will the non-privileged local user have the access to my UWP application data? – ForNeVeR Jun 10 '19 at 14:45
  • 1
    I believe the Credential Manager controlled data is inaccessible to a regular logged on user account, although it does roam across devices. There are other ways to encrypt data, though. What are you ultimately trying to accomplish? – IInspectable Jun 10 '19 at 16:40
  • There's an open-source IM type application. It stores its data on disk. And there're many cases when the user accounts gets stolen from this application (mostly from Windows machines), because malware programs can read the data. We're planning to add the data encryption, but if we store any keys alongside the application, the same malware programs will easily read that and still stole the data. So, we're thinking about using some additional security level. Forcing the users to reenter the password at each start is huge no-no. – ForNeVeR Jun 11 '19 at 04:50
  • I'm afraid, that's not something *you* can prevent. Malware generally guides users through installation, making sure to have the user give it the required privileges. And once you're running code under the local system administrator account, it's no longer your machine. This is something that needs to be addressed at the system level (e.g. by running Windows 10 in S mode). – IInspectable Jun 11 '19 at 07:10
  • While your points are true, there was also a point of implementing this functionality in Linux wallet applications, it was implemented to prevent (or make more narrow) some vectors of attack. So, while I generally agree that this security concern shouldn't be a business of a local application, I can also see how it could improve the security (as a percent of accounts stolen) in the real-world scenarios. – ForNeVeR Jun 11 '19 at 11:05

0 Answers0