September 24th, 2024

The UserConsentVerifier confirms that the user is there, but it doesn’t protect any data

Raymond Chen
Raymond Chen

The User­Consent­Verifier Windows Runtime class lets you display one of those authentication prompts to confirm the identity of the user. Programs like Web browsers often use this before doing things like revealing cached passwords.

The User­Consent­Verifier does not actually protect any data. Its purpose is confirm that the correct user is still there, and that it’s not just somebody who randomly walked up to an unlocked computer.

You see, the Web browser already has your password. When you go to a Web page, the Web browser already autofilled your password without asking you to go through the User­Consent­Verifier. Clearly it knows your password already because it filled it in!

The purpose of the User­Consent­Verifier prompt is not to grant the program permission to access the password. It already knows how to do that. The purpose of the prompt is to grant the program permission to reveal the password.

The decision to protect the reveal with a User­Consent­Verifier is that of the program’s developer. In an alternate universe, the program’s developer might have decided, “You know what? I’ll reveal your password to anybody.” But in this universe, the program’s developer said, “You know what? Users might get creeped out if I just reveal their password at the drop of a hat. Let me show a good faith effort to protect it.”

If you assume that the Web browser itself may have been compromised, then this prompt protects nothing, because the code that compromised the Web browser can just extract the password from the Web browser directly. Or it can patch the program so it just skips the call to the User­Consent­Verifier entirely.

Note that the class name is the “user consent verifier”: Its job is to confirm that the user gave consent for an action. It doesn’t actually protect the action.

Bonus chatter: Note that the user consent verifier uses the same interface as Windows Hello, but Windows Hello actually does something! It grants access to keys stored in the TPM.

Category
Old New Thing
Topics
Other

Author

Raymond Chen

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.

3 comments

Discussion is closed. Login to edit/delete existing comments.

Newest
Newest Popular Oldest
  • Christopher Lee

    I’m surprised that this UserConsentVerifier class didn’t get multi-user API overloads, as Surface Hub and Xbox consoles are the key scenarios where you have multiple users signed in and collaborating (possibly with shared input devices), so you’d want to confirm that an individual user actually intended to do something risky.

  • Dan Bugglin

    I really hated when Chrome added a prompt like this for revealing saved passwords for the reasons you mention in this post... it's very easy for users to assume their passwords are protected behind this prompt. But, you can go to the website in question, and let the password autofill, and use the browser dev tools to reveal it easily.

    Honestly I have to say having this password prompt to reveal saved passwords feels like a...

    Read more
    • LB

      I would have expected autofilled password fields to be poisoned until consent is given, so that devtools can’t just bypass that. Sounds like a bug in Chrome.

Read next