3

I have been experimenting with Windows.Security.Credentials.PasswordVault as a way of storing my applications' passwords.

Reading the class documentation and the UWP documentation, I assumed the vault has some method of identifying applications, so that a particular app may only retrieve credentials it has saved in the vault itself:

Apps and services don't have access to credentials associated with other apps or services.

I was unable to confirm that this works, since an app I wrote was actually able to access the credentials another app of mine had saved in the vault, including the passwords. Since the mechanism doesn't require any certificates or app IDs, I was curious about how it even could ensure the above property.

Looking at SO I found this very similar, as yet unanswered question. It confuses me further, because its asker says:

It appears that even though the second application is using the same key as the first app used in saving the data; the second app cannot retrieve that data. This is good.

In my case, the second application can read the vault credentials saved by the first with no problem, password and all. Not only that, I can also read all passwords stored by the Internet Explorer for the websites I have password auto fill information saved. The comments on this question confirm that there is no mechanism to prevent one app from accessing another's stored credentials if both are executed by the same user, which is in direct contraditiction to my understanding of the API documentation.

I must be misunderstanding how the security aspect of PasswordVault works. How can it be used to secure credentials so that they can be used only by the app that created them?

Information about my environment:

  • Apps run on Windows 10
  • API platform 10.0 (also tested with 8.0)
  • Apps are executed with no elevated rights
waldrumpus
  • 2,540
  • 18
  • 44
  • Is your app a classic desktop app or a modern app? All modern apps have an app-id. – Anders May 29 '18 at 13:03
  • @Anders I'm not sure what exactly you mean by "classic" and "modern". I wrote and compiled the apps myself using Microsoft Visual Studio; they are not being published in the Microsoft Store, if that's what you mean. – waldrumpus May 29 '18 at 13:16
  • @Anders Please see my edit regarding the app being able to read Internet Explorer passwords; even if my app is "classic" or otherwise outdated, it should still be impossible for it to read passwords saved by IE, right? – waldrumpus May 29 '18 at 13:17
  • No, classic desktop apps probably use the user token (HKCU) and is shared by all apps running as that user. Modern/WinRT/Store apps don't have to be published in the store but they will always have some sort of ID AFAIK. – Anders May 29 '18 at 13:25
  • @Anders Do you happen to have any more information about what constitutes a modern app? – waldrumpus May 29 '18 at 13:37
  • A security system that only works for store apps is the very definition of security by obscurity :) – Jonathan Potter May 29 '18 at 15:05
  • 1
    @waldrumpus You generally know if you are writing a UWP/Modern app or not. If you are using Visual Studio you probably picked some kind of project template when you started. A classic/desktop app written in C/C++ starts in main() or WinMain() and calls Win32 and/or C API functions while UWP apps use the UWP (WinRT) API. – Anders May 29 '18 at 15:10
  • 1
    The main difference between a Windows Store app and a classic Desktop app is *"App Identity"*, usually controlled through the *Package.appxmanifest* file. Each Windows Store app is installed and run under a unique user account, assigned when you register your app. Passwords in the PasswordVault aren't shared with apps running under a different user account. Since the PasswordVault API has the `DualApiPartitionAttribute`, it is available to Windows Store and Desktop apps. You are probably calling it from a Desktop app. @Anders: A UWP app written in C++ also starts in `WinMain`. – IInspectable May 29 '18 at 20:36
  • @JonathanPotter: A security system that works by controlling access to resources based on SID's is hardly obscure. We've been using that literally for decades. – IInspectable May 29 '18 at 21:05
  • @IInspectable That is correct, I'm calling it from a desktop app, no manifest present. If I understand you correctly, the vault will prevent cross-app credential access if one or both of the apps are installed via the store, because they're essentially run under distinct users? If that's correct, I'd consider that a valid answer to my question. – waldrumpus May 30 '18 at 07:15
  • @IInspectable Would the same also go for apps installed with ClickOnce? – waldrumpus May 30 '18 at 07:15
  • 1
    I don't have enough detail about the implementation available to submit an authoritative answer. I also don't know ClickOnce enough to comment on that. It is true, though, that a Universal Windows Platform application is secured by running it under a unique user account. It doesn't matter, how that app is installed either (through the Store, by side-loading it, invoking an MSIX installer, or even when running it from a package layout under a debugger). The SID is fixed, allowing PasswordVault entries to be accessed from any device using the same app. – IInspectable May 30 '18 at 09:19

0 Answers0