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.
This story, "Cached Windows passwords sound risky -- but aren't," was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more ofRoger Grimes' Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.