Post

And so we had an explosion of security stuff. It wasn't good, but it was transformational. And that security stuff meant logging in to...stuff. Passwords. Now in Windows world we had NT and soon Active Directory. A central place to orchestrate access to...stuff. One password to rule the world.

Except not everything was Windows (how dare) and not everything was ruled by Active Directory (sacrilege), or maybe you had two Active Directory's (acceptable). When you connected to that thing you couldn't automatically auth to it so it prompted Ye Olde Cred Prompt and away you go.

That's fine, once, I guess, but what if you access this thing five times a day every day? It gets tedious. What if we put in a magical "Remember My Password" checkbox? Now you can connect those 25 times a week and never get prompted again. Obviously brillant!

And thus is born the Credential Manager. Now, if you've ever considered building a password manager, first, my condolences for the braincells you lost, and second, it starts destroying your soul once you get into the weeds. It's just CRUD over a database, right? How hard can it be?

Lets just rip the bandaid off: how the hell do you protect the long term storage of those passwords such that they're accessible when you need them and cannot be stolen? The answer to this question is the first step to destroying your soul: it depends; define 'stolen'.

In the 90s and 2000s our general philosophy was, in a muchly distilled way, that the user is the security boundary and other users cannot steal your passwords. We still live by that rule, but more on that in a minute. Goal: We protect passwords such that other users on the machine can't steal them.

In Windows we have isolation promises. Kernel mode from user mode, user A from user B, etc. Therefore it's pretty straightforward that user B shouldn't be able to grab user A's passwords off the disk. We can do that through ACLs. But what if I'm an admin or I walk off with the hard drive?

Okay, not great. We need to protect the credentials such that only the user can touch them even if an attacker has the raw bytes. Oh, hello cryptography. We encrypt the passwords! To what? Which key? How do you protect /that/ key? Dammit.

WELL what if we just prompt for a password to unprotect your passwords every time you need to use your passwords? You want to prompt for a ...password... to unlock your database of ...passwords... in lieu of a ...prompt... from a resource asking for said... password? Which, uh, password?

That's actually the lesser of two evil user experiences. What happens when you want to SAVE a password before the database is open? Prompt > Save > Prompt > what, I just entered my password?? > WRONG PASSWORD TRY AGAIN, IDIOT.

And so we must make sure the database is accessible on first use and also protected from attackers walking off with hard drives, so what do? Aha! What if we use the users password they logged into the computer with?! Congratulations you've invented DPAPI: Data Protection API.

Your password is used as a key to unlock a wrapping key, which wraps more keys, which rotate every few months, and those keys are used to protect whatever arbitrary thing you want to protect. Good in theory. I will save it for another story, but DPAPI is nevertheless a cursed technology.

So anyway, we now have a way to protect your passwords by using your logon credential. When you log on you unlock the database and when the machine is off the key isn't on disk so grabbing the hard drive yields nothing. Actually that's not bad for the turn of the millenium.

Over the years a bunch of functionality was added to DPAPI and Credman for reliability and roaming. The interesting side effect of having a key derived from your password is as long as you know your password you can derive that key wherever you want, so credential roaming just works.

I think it was in the Win 10 era where we provided an ability to sync your credman database across machines. Incidentally, once upon a time, that used OneDrive to do the heavy lifting.

Credential Guard also has protections for Credential Manager too. We do our darndest to prevent the release of those secrets by letting Cred Guard do the authy bits instead of normal world.

DPAPI has some key escrow behaviors against AD that let you recover corrupted intermediate keys so you can always get your data. This necessarily requires AD (or Entra too these days) because there's no other escrow entity you trust. This is why local users prompt this horrid warning.

If you have a local user and you SET the password there is no mechanism to decrypt the DPAPI keys because the old password is, presumably, long gone. CHANGE is fine since it requires you enter the existing password, so it can ratchet the keys. But we're off on a tangent. Back to Credman.

You might have noticed an hour ago when this thread started that there are two tabs on the control panel: Web Credentials / Windows Credentials. I've just described Windows credentials. Web credentials are, shockingly, used for websites by a browser, Internet Explorer and Edge (pre-chromium).

Now we get to the modern-ish world and we think about how attacks are very different. It's one thing for malware to steal a password to a file share on a corporate network you must physically be in a building to access. It's wholly different if its a cred to a website accessible globally.

Oh, and remind me of the time a team I was on used cryptprotectdata to encrypt a secret on a vm managed by vmss. Once a month (reliably), the service failed because the key was corrupted. It took us WEEKS to figure it out.

CURSED. DPAPI is CURSED in many failure modes.

This one was VMSS and how it handled os updates, not specifically DPAPI (except for DPAPI using a machine specific key). Oh, and we learned that fun times happen when techs in the data center swap the TPM on the host.