Re: CryptProtectData across reboot on XP
From: Amit Rahul [MS] (arahul_at_online.microsoft.com)
Date: 03/17/04
- Next message: nick: "use of WlxGetOption() with WLX_OPTION_SMART_CARD_INFO"
- Previous message: Mike Collins: "GinaStub, userinit.exe and Exception (0xc0000142)"
- In reply to: Erik Tkal: "Re: CryptProtectData across reboot on XP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 16 Mar 2004 20:08:20 -0800
Are you using a NT4 domain (I mean a domain with NT4 DC's in it) with XP
clients? Since DPAPI backup/recovery support doesn't exist on NT4 we have
provided a workaround to avoid loosing DPAPI data. As John explained you can
force the XP machine to use W2K style master key backup/recovery. For that
you would need to set a registry key before you create the master key. This
registry key "MasterKeyLegacyNt4Domain"enforces a legacy mode
backup/recovery on Xp systems. Please refer to John's mail on KB for how to
use this.
-- Thanks, Amit Rahul [MS] This posting is provided "AS IS" with no warranties, and confers no rights. "Erik Tkal" <anonymous@discussions.microsoft.com> wrote in message news:0E7C3E17-84F7-4865-B6A3-917DC6753B04@microsoft.com... > I can understand the backup information not being available with no DC available, but that should be a failure scenario - the primary decryption with the user's password should produce the master key. > > Referring to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/windataprotection-dpapi.asp > > 1) >>> > DPAPI initially generates a strong key called a MasterKey, which is protected by the user's password. DPAPI uses a standard cryptographic process called Password-Based Key Derivation, described in PKCS #5, to generate a key from the password. This password-derived key is then used with Triple-DES to encrypt the MasterKey, which is finally stored in the user's profile directory. > <<< > > 2) >>> > The other question you might have is how does DPAPI access MasterKeys after a user changes his or her password? The answer is again a two-step process. First, DPAPI hooks into the password-changing module and when a user's password is changed, all MasterKeys are re-encrypted under the new password. Second, the system keeps a "Credential History" file in the user's profile directory. When a user changes his or her password, the old password is added to the top of this file and then the file is encrypted by the new password. If necessary, DPAPI will use the current password to decrypt the "Credential History" file and try the old password to decrypt the MasterKey. If this fails, the old password is used to again decrypt the "Credential History" file and the next previous password is then tried. This continues until the MasterKey is successfully decrypted. > <<< > > 3) >>> > While unprotecting data, if DPAPI cannot use the MasterKey protected by the user's password, it sends the backup MasterKey to a Domain Controller via a mutually authenticated and privacy protected RPC call. The Domain Controller then decrypts the MasterKey with its private key and sends it back to the client via the same protected RPC call. This protected RPC call is used to ensure that no one listening on the network can get the MasterKey. > <<< > > So when the user changes his password, the system must be connected to the network, which we have observed. After the user changes his password, he can still decrypt data, even when disconnected from the network, so the credentials must be cached. Per (2) above, the Master Key should have been reencrypted with the user's new password and stored locally, and there should be a credential history file stored locally, also encrypted with the new password. > > So now I reboot the system and am disconnected from the network. I can log on fine using my cached credentials, but decryption of data protected by the previous password is inaccessible. So what happened to the credential history file stored locally? Is that what you are referring to when you indicate "backup"? > > This is critical, because in our situation, the data we are decrypting is used to establish the network connection. Our customers are seeing this issue with XP clients connected to an AD domain, and I am trying to reproduce that exactly here right now. Our domain here is NT4, so I am able to reproduce the problem regardless of whether I am connected to the network or not. > > Also, you state that the workaround causes "WinXP to behave like Win2K when an NT4 DC is detected." Will this workaround *not* cause that behaviour in an AD domain? If so then CryptProtectData would be useless to us. > > Thanks for your help, > Erik > > > ----- John Banes [MS] wrote: ----- > > With domain user accounts on WinXP, DPAPI is dependent on having a user > domain controller (DC) available. This domain controller must be running > Win2K or later. If this DC is not available, then DPAPI won't be able to > backup its master keys, so that when the user's password is changed then > DPAPI won't be able to decrypt stuff properly. This affects both password > changes and password resets. > > Win2K didn't have this problem, because if a Win2K DC wasn't available then > it would back up the master keys using a machine local secret. This wasn't > all that secure, but it wasn't so reliant on having a DC available either. > On WinXP we improved the default security, and introduced a hard dependency > on a Win2K DC. This was a difficult decision, but in the end we decided that > security was most important. > > The registry key mentioned in KB 331333 merely tells WinXP to behave like > Win2K when an NT4 DC is detected. > > Is your user domain still running with NT4 domain controllers, by any > chance? > > Regards, > John Banes > [Microsoft Security Developer] > > This posting is provided "AS IS" with no warranties, and confers no rights. > Please do not send email directly to this alias. This alias is for newsgroup > purposes only. > > "Erik Tkal" <etkal@funk.com> wrote in message > news:2A4F668F-01B7-4758-BE89-C9FCB199E8A4@microsoft.com... > > Can you answer this please? I think there is a bug on XP where when you > > change your password that the write of the new credential info does not > > persist. From the DPAPI docs: > >> "First, DPAPI hooks into the password-changing module and when a user's > > password is changed, all MasterKeys are re-encrypted under the new > > password. Second, the system keeps a "Credential History" file in the > > user's profile directory. When a user changes his or her password, the old > > password is added to the top of this file and then the file is encrypted > > by the new password. If necessary, DPAPI will use the current password to > > decrypt the "Credential History" file and try the old password to decrypt > > the MasterKey. If this fails, the old password is used to again decrypt > > the "Credential History" file and the next previous password is then > > tried. This continues until the MasterKey is successfully decrypted." > >> The previous KB article I referred to (331333) mentions a workaround > > having to do with password recovery, but not a simple password change, > > even though it does seem to work around the immediate issue. Can someone > > explain to my why without this registry change I cannot decrypt data after > > a password change and a reboot. > >
- Next message: nick: "use of WlxGetOption() with WLX_OPTION_SMART_CARD_INFO"
- Previous message: Mike Collins: "GinaStub, userinit.exe and Exception (0xc0000142)"
- In reply to: Erik Tkal: "Re: CryptProtectData across reboot on XP"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
