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.
[ Brace yourself for IT's 9 biggest security threats. | Find out how to block the viruses, worms, and other malware that threaten your business. | Learn how to protect your systems with InfoWorld's Security Central newsletter. ]
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.