This article discusses cached credentials security in Microsoft Windows Server 2003, in Microsoft Windows XP, and in Microsoft Windows 2000. This article mostly discusses domain credentials. However, this article also discusses generic credentials for clarification.
Understanding password caching
Windows-based computers use two forms of password caching: domain credentials and generic credentials.
Domain credentials are used by operating system components and are authenticated by the Local Security Authority (LSA). Typically, domain credentials are established for a user when a registered security package authenticates the user's logon data. This registered security package may be the Kerberos protocol or NTLM.
Generic credentials are defined and authenticated by programs that manage authorization and security directly instead of delegating these tasks to the operating system. For example, a program might require that a user enter a user name and a password that the program provides. Or, a program might require that a user produce a certificate to access a Web site.
Programs use credentials management functions to prompt users for credentials that are defined by the program. These credentials may take the form of a user name, a password, a certificate, or a smart card. The credentials that the user enters are returned to the program for authentication.
Credentials management lets you customize cache management. Credentials management also provides long-term storage for generic credentials. Generic credentials can be read and written by user processes.
Windows XP Professional and Windows Server 2003 include a Stored User Names and Passwords feature that also provides credential management functionality. Depending on the type of authentication, this feature can save user credentials so they can be reused later.
Credential Manager stores user credentials securely. These credentials include passwords and X.509 certificates. Credential Manager lets both roaming and nonroaming users provide credentials only one time. For example, the first time that a user runs a program on a company's network, authentication is required. Therefore, the user is prompted to supply credentials. After the user provides these credentials, they continue to be associated with the program.
Functionality that cached domain credentials provide
Cached domain credentials provide the following functionality:
- Single Sign-On
Single Sign-On (SSO) uses the credentials that are collected during an interactive domain logon to let the user authenticate to a network one time. Thereafter, the user has access to all the authorized network resources without providing credentials again. These network resources may range from hardware devices to programs, files, and other types of data. All these resources may be spread throughout an enterprise on servers of various types. The resources may be in different domains or may be on different operating systems.
- Access to machine resources when a domain controller is unavailable
After a successful domain logon, a form of the logon information is cached. Later, a user can log on to the computer by using the domain account, even if the domain controller that authenticated the user is unavailable. Because the user has already been authenticated, Windows uses the cached credentials to log the user on locally. For example, suppose a mobile user uses a domain account to log on to a laptop that is joined to a domain. Then, the user takes the laptop to a location where the domain is unavailable. In this scenario, Windows uses the cached credentials from the last logon to log the user on locally and to allocate access to local computer resources.
Security of cached domain credentials
The term cached credentials does not accurately describe how Windows caches logon information for domain logons. In Windows 2000 and in later versions of Windows, the username and password are not cached. Instead, the system stores an encrypted verifier of the password. This verifier is a salted MD4 hash that is computed two times. The double computation effectively makes the verifier a hash of the hash of the user password. This behavior is unlike the behavior of Microsoft Windows NT 4.0 and earlier versions of Windows NT.
If an attacker tries to conduct a cryptanalytic attack on the verifier, this encryption has two consequences:
- A precompiled table must be created for each salt.
- The verifier cannot be used to log on anywhere else.
Configuration options for cached domain credentials
- Number of cached domain credentials stored on the client
By default, the operating system caches the verifier for each unique user's ten most recent valid logons. This value can be set to any value between 0 and 50. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
Cached domain logon information
- Notification of logon using cached domain credentials
When you try to log on to a domain from a Windows-based client computer, and a domain controller is unavailable, you do not receive an error message. Therefore, you may not notice that you logged in with cached domain credentials. For more information about how to display a message when you use cached credentials to log on, click the following article number to view the article in the Microsoft Knowledge Base:
User is not alerted when logging on with domain cached credentials
Security considerations for cached domain credentials
Deleting the credential cache
Regardless of what encryption algorithm is used to encrypt the password verifier, a password verifier can be overwritten so that an attacker can authenticate as the user to whom the verifier belongs. Therefore, the administrator's password may be overwritten. This procedure requires physical access to the computer. Utilities exist that can help overwrite the cached verifier. By using one of these utilities, an attacker can authenticate by using the overwritten value.
Overwriting the administrator's password does not help the attacker access data that is encrypted by using that password. Also, overwriting the password does not help the attacker access any Encrypting File System (EFS) data that belongs to other users on that computer. Overwriting the password does not help an attacker replace the verifier, because the base keying material is incorrect. Therefore, data that is encrypted by using Encrypting File System or by using the Data Protection API (DPAPI) will not decrypt. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
An attacker with physical access to your computer may be able to access your files and other data