Is PasswordVault supported?

[dajbych]

Hi, I'm porting my UWP app to Windows App SDK. I'm unable to read credentials using PasswordVault (Credential Locker API). The source code and package name is unchanged. Is this scenario still supported? (For me, this is a blocking issue.)

[riverar]

And why are you unable? Please be specific.

[andrewleader]

Yeah, @dajbych can you provide more info on what isn't working? I just tested PasswordVault in a packaged WinUI 3 app and it seems to be working for me. Thanks!

[dajbych]

@riverar, @andrewleader I will do my best although I'm not able to see local variables in Visual Studio 2022:
Cannot obtain value of the local variable or argument because it is not available at this instruction pointer, possibly because it has been optimized away. Code optimization is enabled for Release build only, I'm using Debug build.

This is the code I use in both UWP a Windows App SDK apps:

using System;
using System.Linq;
using Windows.Security.Credentials;

const string CREDENTIAL_NAME = "~~~~";
const string USER_NAME = "~~~~";

var vault = new PasswordVault();
vault.RetrieveAll().ToList(); // (1)
vault.Retrieve(CREDENTIAL_NAME, USER_NAME); // (2)

UWP (VS2019, Windows 10 SDK 10.0.19041.0)
(1) Returns a list of all stored PasswordCredential.
(2) Returns a stored PasswordCredential.

Windows App SDK (VS2022, .NET 6, Windows App SDK 1.0.0)
(1) Returns an empty list.
(2) System.Runtime.InteropServices.COMException: 'Element not found. (0x80070490)'

Package.appxmanifest file is identical for both apps (both package name and package family name are identical).

[andrewleader]

Thanks for the additional details @dajbych. We found some differences in the PasswordVault API between full-trust apps (which WinUI 3 apps are full-trust) compared to AppContainer UWP apps that we're investigating with the team and will get back to you.

[andrewleader]

Hi @dajbych, we have confirmed that unfortunately PasswordVault doesn't work as expected for full-trust desktop apps (a.k.a. WinUI 3 apps or WPF apps/etc).

We are investigating ways we can support an updated PasswordVault API in Windows App SDK that will work as expected (as in returning your passwords from your app package identity specific storage, which would allow you to upgrade from UWP without losing data).

Your options today are...

• Wait till we add an updated PasswordVault API to Windows App SDK (we don't have an ETA on that yet).
• Migrate your app and have your users deal with having to re-specify their passwords (start over fresh, basically). Note that passwords stored using PasswordVault will be accessible by all other desktop apps (the API today writes to a shared storage for full-trust apps).
• Temporarily update your UWP app to read and save your passwords in your own app storage, and then a few months later release your rewritten app
• Or build a UWP sidecar that reads from the PasswordVault and is called from your new rewritten WinUI 3 app. This would be a very complicated solution, basically you distribute two apps and you have the WinUI 3 app call into the UWP app to ask for the passwords... I wouldn't recommend this unless you're really desperate to migrate.

[Johno-ACSLive]

If you package the WinUI 3 app as an MSIX then I believe it applies the same level of sandboxing. It might not still work as you need depending on how Windows links the MSIX install and UWP app.

PasswordVault is packaged in the Windows.Security.Credentials namespace which seems to sit in the UWP libraries. I'm actually using PasswordVault in a WinUI 3 app (it's new - not replacing a UWP so didn't need to migrate anything).

[sopelt]

@Johno-ACSLive I am not quite sure what you are saying. PasswordVault seems to behave differently and I have yet to find documentation stating otherwise.
Have you looked into "Credential Manager" in Windows/control panel to see if the credentials from your WinUI app ended up there?

[Johno-ACSLive]

@sopelt yes the credentials do show up in Credential Manager and this is expected because I'm only debugging and running my app via published files. The app will be running in full trust mode even if I have created an MSI and launch the installed executable. In full trust mode PasswordVault will use the user profile store which Credential Manager has access to.

So when you package any application into an MSIX then these applications will run in sandboxed mode - same as a UWP would when it's appx or store delivered package is installed. I've not created an MSIX for my app yet but Credentials in PasswordVault will not be visible in Credential Manager when launching an app installed using an MSIX. Try creating an MSIX with your WinUI 3 app (or a test app) and get it to save/retrieve credentials - they shouldn't appear in Credential Manager. I believe there is a basic MSIX project with Visual Studio but I believe Advanced Installer requires Professional Edition.

That being the case, what I'm unsure of is if you were to install your WinUI 3 app via MSIX - how does Windows treat the package name in relation to the sandboxed app data locations? If it treats the package name the same as a UWP would then in theory you will be able to access the PasswordVault data that your UWP app has access to.

For example, UWP stores app data in C:\Users\user_name\AppData\Local\Packages\app_package_identifier. I've just had a quick read of an Advanced Installer article here which suggests it uses the same redirection (The MSIX redirection is located in the end-users AppData\Local folder, under a subfolder called Packages. Each package installed to the user's device will have a subfolder using the package name.).

Hopefully that makes sense!

EDIT: Just found this here. This describes the trust levels and redirection.

[sopelt]

Thank you @Johno-ACSLive for the detailed response. In the current project there is fortunately no existing UWP-App to consider. Just installing via MSIX will not change the behavior of PasswordVault ... It is really disappointing, that WinUI3 apps first look to have most features one could ever want but the details are more complicated... The location of the app itself, storage for app data/settings/... all seem to work well for packaged/unpackaged but the PasswordVault seems to require actively opting into AppContainer (or at least this is what I believe as of this moment) but it is not easy to estimate which APIs we previously used (FileSystemWatcher ... Process/Windowing/...) will stop working if we would opt in to AppContainer...
It would be nice to have credential isolation without the "full sandbox commitment" ...

Thanks!

[Johno-ACSLive]

@sopelt apologies I was thinking about the original OPs situation.

It seems MSIX was designed with a hybrid approach to virtualisation. Existing files will not redirect therefore this is true of Credentials seen in Credential Manager. It depends on the Windows version as described in the link below "For Windows versions less than or equal to 1809, all writes to the user's AppData folder (including create, delete, and update) are copied on write to a private per-user, per-app location, which is merged at run-time to appear in the real AppData location.
For Windows versions greater than 1809, all newly created files and folders in the user's AppData folder are written to a private per-user, per-app location which is merged at run-time to appear in the real AppData location. Modifications to existing AppData files is done on the unvirtualized files. For reads, the system tries the private location first, then falls back to the unvirtualized AppData.".

However, you can control which paths as described here. Therefore you could ensure that the location of the credential vault is fully virtualised and this should in theory mimick the original isolation behaviour.

Microsoft seems to have tried to stike a balance of hybrid rather than just full trust or full sandbox. This is tied to the packaging technology (MSIX) though.

WinUI 3 is just the new UI framework for .NET apps on Windows. The WindowsAppSDK is meant to unifi API surfaces so presumably Microsoft will want to keep the app model (full trust, hybrid or full sandbox) as part of the packaging/deployment technology.

Alot of the Microsoft examples where file access is required tests access to sandbox storage before falling through to another location.