Cached Windows passwords sound risky — but aren’t

I deal with a lot of customers who area worried about Windows password attacks. These days, the biggest fear is of pass-the-hash attacks, a topic I’ve written about many times in the past couple of years.

Often, when customers voice concern about pass-the-hash attacks, they ask me about cached log-ons in Windows. They’ve heard about the vulnerability and have read one or more whitepapers about it. Even Microsoft recommends disabling cached log-ons.

In fact, cached Windows log-ons aren’t a big risk at all. I’ll tell you why in a minute, but first, let’s review the basics.

How cached passwords work

When a user successfully logs on to a Windows computer for the first time, Windows creates a local user profile folder to store desktop and other user-related settings. For domain users, Windows will store a cached log-on as well. With future log-ons, if the domain user attempts to log on to the same domain but the Windows user cannot successfully contact a domain controller, Windows will log on the user locally if the user submits the same password (or other authentication credentials) entered in the last successful domain log-on.

A common use for cached log-ons is to serve traveling laptop users. When the laptop user is connected to the home domain network, log-ons are verified by the domain controller. But when the laptop is away from its home domain, the user can still log on and use Windows because of the cached information. The password (or authentication credential) used during travel must be identical to the one previously cached while on the home network. When away, the submitted password is verified against something called the cached log-on password verifier, which is a one-way function of the user’s previously submitted password.

A case of mistaken identity

In thinking about cached log-on verifiers, users often make the error of equating them to normal password hashes (such as LANManager or NT hashes) that computer hackers are always stealing, replaying, and cracking. Fortunately, they aren’t the same. The mistaken assumption is reinforced by Microsoft’s recommendation, as documented in the Microsoft Security Compliance Manager tool, that cached log-ons be disabled.

The default cached log-on setting (located in group policy objects at Computer Configuration/Windows Settings/Security Settings/Local Policies/Security Options/Interactive Logon: Number of Previous Logons to Cache) is usually around 10 cached log-ons. This default setting goes back to Windows NT 4.0, if not longer. Now, Microsoft recommends that cached log-ons be set to 0, which disables it.

The bad thing about disabling cached log-ons is that many computers could be difficult to log on to, or even to troubleshoot or repair, if the computer cannot reach a domain controller. Many computers, even ones that never leave the home network, suffer quick, transient network problems, which cached log-ons help overcome.

The confusion over the security risk of the cached log-on seems to ensnare lots of Windows security experts. I’ve read more than a few security papers that have characterized removing cached log-ons as a highly critical recommendation. I have seen respected computer security firms find cached log-on verifiers on their customer’s networks and point them out as hacking vectors that need to be addressed immediately.

Nothing could be further from the truth. I often respond by telling the customer to ask their security vendor to show them a successful attack using cached log-on verifiers. It’s one thing to find a cached log-on verifier (they are stored and readily retrievable using the right tools in the registry under HKLM/Security) and another for them to be usable to an attacker.

Verifiers vs. authenticators Cached log-on verifiers aren’t good hacking candidates for several reasons. First, verifiers aren’t hashes or authenticators — they’re verifiers, as the name suggests. Password hashes are authenticators; when stolen, they can be used to initiate new authenticated sessions. If you steal my password hash, in the Windows computer world, you are me. But if you get my verifier, you cannot do much with it. It isn’t an authenticator and can’t be used for authentication.

A verifier could possibly be used to crack a password, but even that would prove difficult. A Windows password verifier is tens of thousands of times — if not orders of magnitude — harder to crack than a normal Windows password hash. To begin with, password verifiers are salted with the user’s name. Salting doesn’t add tremendous complexity to cracking of the verifier, but it isn’t done with the other password hashes, and it complicates brute forcing, rainbow table creation, and use. It also prevents easy comparison searches for reused passwords.

The real value in protecting the verifier is its inherent computational generation effort. In early versions of Windows, the log-on cache verifier was many times more difficult to crack than a normal password hash. In Windows Vista/Windows Server 2008 (and later), the log-on cache verifier is protected using PBKDF2, which is considered cryptographically very secure and is significantly more resistant to brute-force attacks than earlier protection mechanisms. It essentially takes the password, the salt, and a pseudo-random function, then mathematically computes them over thousands of rounds of identical computations.

For practical purposes, as long as your password is of decent strength (at least eight characters), cracking a Windows password hash verifier is nontrivial. That’s crypto-babble for “ain’t gonna be done by most people using today’s available hardware.”

In order for an attacker to get to a password verifier, he or she must be a local administrator, which gets the attacker to Local System to retrieve the verifiers. With that level of access, an attacker is far better off stealing the regular password hashes or password sniffing. Why try to get to something that’s hard to crack when you can, with the same effort, get something that works every time without additional hacking?

It can’t hurt to limit the number of cached log-on profiles, as Microsoft recommends, but there isn’t much value to doing so. Cached log-ons can’t be used in pass-the-hash attacks, can’t be used as authenticators, and certainly aren’t high risk in most environments. Hopefully, anyone who’s written differently will correct their documentation and update their customers. We have more important things to worry about.