18

If I can change my password with cmd net user example * without needing to confirm my old password, why, when I change my password in the usual way (via settings or control panel), do I need to confirm my old password? If the point of confirming a password is to prevent somebody who finds the PC open from signing in, this circumvents it!

Stalemate
  • 183
  • 1
  • 6
  • 5
    Linux does the same. if I run `passwd` as normal user, I have to provide my password. But as root, it does not ask me for the password. If I already have admin rights, asking for the password again does nothing to really protect the system. – ThoriumBR Jul 15 '20 at 19:10
  • Isn't half the point there that "cmd net user example *" sits well below Windows? – Robbie Goodwin Jul 16 '20 at 20:22
  • 1
    Are you asking about confirming the old password (to know if the original user is making the change) or confirming the new password (by entering it twice)? – Razvan Socol Jul 17 '20 at 04:58

1 Answers1

34

In addition to what nobody said there's a more practical, but mostly internal, requirement here. Changing a local password in Windows without knowing the original password is called a reset. Resets cause DPAPI keys to be invalidated (because they're protected by a primary secret based on the user password). Once the reset happens those original keys are dead and cannot be decrypted because the new password doesn't match the old password.

Changing a user password requires knowledge of the original password so those DPAPI keys can be rotated safely.

Resets are, from an administrative point of view, a worst case solution for this reason. This is actually why you get the "irreversible loss" warning from lusrmgr.msc, and to do so requires local admin privileges.

irreversible loss warning from Windows

yoozer8
  • 810
  • 2
  • 7
  • 17
Steve
  • 15,155
  • 3
  • 37
  • 66
  • When a user is logged in, doesn't the OS already have access to the DPAPI keys? Why would it need the password again for changing the key? – nobody Jul 16 '20 at 10:54
  • 2
    @nobody If the OS is handling things properly and in a secure manner, it should not have access to those keys unless they're actually being used. Keys should not be readable in memory unless they're in use, period. This is not always the case on Windows (I'm pretty sure you can have it cache the keys on login so it doesn't prompt for passwords on first usage), but on a properly secured system it should be. – Austin Hemmelgarn Jul 16 '20 at 15:04
  • To be more precise: there's just no guarantee the password is known at that exact moment. Maybe it is, maybe it isn't. Change could theoretically happen outside the users logged on session, though rare. – Steve Jul 16 '20 at 15:10
  • @AustinHemmelgarn IIRC In Windows, any program running under any user account can ask DPAPI to encrypt/decrypt data when that user is logged on. The user is not prompted for the password again (you can try it yourself). This means the API can access the keys and so it should be able to change them without asking for the password again. – nobody Jul 16 '20 at 15:24
  • 4
    DPAPI is a lot more complicated than that. There are generations of keys. Just because the current set is decrypted and available in memory doesn't mean the rest are. You need to guarantee all keys can be decrypted, which requires the current password. – Steve Jul 16 '20 at 16:14