Secrets stored in Password Vault / Credential Locker are encrypted using the Windows Data Protection API (DPAPI, see also MSDN) and stored in the user's profile directory (to see where, run vaultcmd.exe /list
). On Win10, DPAPI uses AES256, and the password is hashed using PBKDF2 with 8000 iterations (or possibly more on recent updates). See this answer for more about that.
DPAPI "master" keys are static for a user but are protected using a password-derived key. This protected master key (stored in the user's profile directory) is unrecoverable if a user's password is forcibly reset (by an administrator or by directly editing the SAM registry hive). Thus, Credential Vault-stored secrets (and everything else protected by DPAPI keys, including Encrypting File System keys) are in effect protected by the quality of your password.
Note that Windows password hashes are terrible (there's some obfuscatory nonsense on top, but at the end of the day the passwords are stored as single-round unsalted MD4 hash digests). This means, if an attacker has administrative access to your machine or physical access to the hard disk (or a backup image thereof), they can attempt to brute-force your Windows password at an astonishing rate (tens of billions of candidates per second, using commodity hardware). An attacker can also simply try to look up your password in a "rainbow table" of pre-computed hashes. A sufficiently good - mostly meaning long - password is still secure, though.
For "Windows Store" sandboxed apps, an additional layer of separation applies. When a particular app uses PasswordVault, it can only see or store credentials for itself. However, I wouldn't count on this as a security benefit; I don't believe it's enforced by any actual security boundaries (e.g. ACLs on the data) and expect an app could just get around this by calling the native APIs directly.