Re: cached login credentials

Oops! Right, I missed that bit.

In answer to your original question, it depends on which kind of logon you use. Anything that does an interactive logon will store cached credentials, so yes, the GUI RunAs will do this. The command-line RunAs will also, unless you include the /netonly switch.

Sure, rainbow tables are growing in popularity. They're effective in pass-the-hash attacks, and this is why I've become an ardent fan of long simple passphrases rather than short complex passwords. Pass phrases are easier to remember, you can type them quicker, and they thwart rainbow tables. Consider a simple 20-character passphrase: you're looking at many tens, maybe low hundreds, of years to generate. And I can't find a handy formula now, but I suspect that finding sufficient hard drive space to store the output will be a bit problematic. For the same reasons, rainbow tables become ineffective against password verifiers: remember these are salted with user IDs, which require significantly larger tables--again, there's the time and space issues to contend with.

Interesting corollary you've thought of, and I'm sure there's a lot of smart discussion that could take place around it. I would consider it this way: the only true defense we have against physical access is time. If we can implement measures that seriously increase the time it would take to launch an attack, then the stolen asset becomes less interesting (and indeed probably encourages the attacker to move on to someone not as smart as you). I like to think of encryption as the thing that buys us time. If the available measures increase the time cushion to millions of years, then I'm cool with that--to me, it's good enough. Long simple passphrases and BitLocker (with TPM and PIN, please) are satisfactory mitigations to Immutable Law #3.

Steve Riley

"msb-2007@xxxxxxxxxxxxx" <msb2007nospamnospam@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:9D3A212E-4702-417D-AFC5-8C397B0D6DC2@xxxxxxxxxxxxxxxx
Thanks for the quick response. And while I agree with each of your points (I
was attempting to acknowledge that in my original post), you didn't actually
answer my question...

If a user logs into a domain machine using "normal" domain user access
credentials, and uses runas to do priviledged operations (assume they use
domain admin account credentials), is a credential cached anywhere for the
domain admin account?

As to your point, rainbow tables are starting to become available to more
"ordinary" users, and so the "theoretical" is becoming more and more
"practical" every day. Underground, distributed, collaborative rainbow table
cracking networks do exist...

My concern is that I'm trying to determine if Corallary 1 to Immutable Law
#3 is true or not... -- "If a bad guy has unrestricted physical access to any
computer in your network, even if its disconnected from your network, it's
not your network anymore" That would be bad....



"Steve Riley [MSFT]" wrote:

As Jesper and I describe in our book
(, cached credentials:

* Are stored not in LSA but in the security hive, a better place for storing
* Are _not_ your ID/password or the hash of your password, but instead a
hash of the hash, salted with your user name (in practicality, this makes
them nearly impervious to ordinary password cracking tools)
* Require running attack tools in SYSTEM context: meaning the bad guy
already has complete control of your computer anyway, so who cares?

There's way too much fretting and worrying over this. Without cached
credentials, laptop computers become completely useless when not connected
to the domain--and this, then, destroys the very reason that laptops exist.

If you're really worried about cracking passwords, then set password
policies that require certain complexity or--better--a minimum length of at
least 15 characters (then you can ignore complexity). Now you can eliminate
password cracking attacks from your list of worries, because the time
required to crack them stretches into the hundreds of millions of years.

(Actually, password cracking attacks really aren't even that interesting.
"Pass-the-hash" attacks, where the bad guy already has hashes of passwords,
_are_ interesting: see the "Should I be concerned about password cracking?"
section in Jesper's article at

In your note, you quote Immutable Law #3
Not to sound flippant, but the best way to thwart this attack is to make
sure you don't get your laptop stolen. There is, of course, a mitigation for
this, too: BitLocker Drive Encryption in Windows Vista Business (if you have
Software Assurance), Enterprise, and Ultimate editions.

One other point that might matter: here at Microsoft, we don't disable or
tweak the settings. We leave the number of cached credentials set to the
default (10), and we require strong passwords. Soon we'll be moving to
corp-wide smartcard logon and finally getting rid of passwords.

Steve Riley

"msb-2007@xxxxxxxxxxxxx" <msb2007nospamnospam@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote in message news:7E81A5D6-B936-4A55-BEA4-FFC85650B6D4@xxxxxxxxxxxxxxxx
>I know this is a topic that has been argued about in security circles >for
> some time...
> However, I haven't been able to find an answer to this particular
> question:
> If a user logs into a domain machine using "normal" domain user access
> credentials, and uses runas to do priviledged operations (assume they > use
> domain admin account credentials), is a credential cached anywhere for > the
> domain admin account?
> Background: if I login to a machine directly with a domain admin > account,
> the domain admin credentials will be cached locally. While these
> credentials
> are somewhat protected through Microsoft's approach with encrypted
> "verifiers", they are not completely secure from a determined attacker.
> Lots
> of argument about how difficult it would be, but I'm confident there is > an
> attack vector there. The old adage "if I have physical access to your
> machine, there is no telling what I can do" applies.
> I understand that there is a registry key (CachedLogonsCount=0) that > can
> be
> set to disallow the caching of credentials, but that doesn't really > work
> well
> when the computer is a laptop that needs to be useable when > disconnected
> from
> the domain. My ultimate goal is to ensure that our security practices > for
> domain adminstrators don't expose the corporate network to additional > risk
> when a laptop is stolen.
> Regards!
> -Matt