Assurance

[Eric Goodman <>]

Thanks, Jeff,

 

That’s a great article. FWIW, it was the LSASS (LM or) NT password hashes that I was thinking of in my original post.

 

--- Eric

 

From: [mailto:] On Behalf Of Capehart,Jeffrey D
Sent: Wednesday, April 29, 2015 7:57 AM
To:
Subject: RE: [Assurance] IAP Question on Stored AUthentication Secrets

 

Microsoft has a TechNet article on Cached and Stored Credentials Technical Overview.

https://technet.microsoft.com/en-us/library/hh994565.aspx

 

The AD Cookbook guidance is to turn off LM hash.

 

There is a Credential Manager store in windows, that is optional.  I think this is much better than the old .pwl files, but still subject to memory scraping or off-line attacks if the machine is compromised, which is a known risk managed through standard procedures per the profiles.

 

If you want to see your credentials managed (cached) in Windows, then go to Control Panel.  Open “Credential Manager”.  You should see your Windows Credentials listed, including your logon ID.

 

For domain logons, there is a “password verifier” stored in the registry, for when the domain is not available.

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.

http://support.microsoft.com/kb/913485

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.

http://www.infoworld.com/article/2616322/security/cached-windows-passwords-sound-risky----but-aren-t.html?page=2

Jeff

 

From: [] On Behalf Of David Langenberg
Sent: Tuesday, April 28, 2015 6:06 PM
To:
Subject: Re: [Assurance] IAP Question on Stored AUthentication Secrets

 

In our implementation, we read 4.2.3 as applying to how the institution stores the Authentication Secrets at rest.  The requirement does not address how a user stores them nor any transient storage used in the process of validating/processing them.  It would be impractical and prohibitively costly to audit every single machine/device/workspace a user could work from for compliance otherwise.

 

Dave

 

On Tue, Apr 28, 2015 at 3:57 PM, Eric Goodman <> wrote:

Greetings all,

 

I’m sure you’re all excited to have me posting more IAP questions!

 

Background:

 

Section 4.2.3.4 (S) Stored Authentication Secrets describes protection mechanisms for “Authentication Secrets”. This section invokes language about approved algorithms, etc.

 

Section 4.2.3.6 (S) Strong Protection of Authentication Secrets talks about protection of “Credential Stores”. This section then references 4.2.3.4 to talk about constraints.

 

By the definitions in the IAAF, any given user’s password is an “Authentication Secret”, whereas a “Credential Store” is a collection of “Authentication Secrets”. Read that way, if a user stores their password locally in a file or script on their machine, in memory, or insufficiently salted, etc., that user is in violation of Silver, whereas the user would NOT be in violation of 4.2.3.6 (there’s only one Authentication Secret, not a collection of them, on the user’s local machine).

 

 

The question: Do people interpreting the IAP generally presume that 4.2.3.4 really refers to “Authentication Secrets that are in Credential Stores” or as “Authentication Secrets” writ large? If the latter, does this raise additional issues with meeting Silver? E.g., the way the user’s password hash is cached in AD after login is, I believe, in violation of 4.2.3.4, just like the AD DS Credential Store would be. (This AD local “password hash cache” is the specific use case that raised this question.)

 

 

FWIW, 4.2.3.5 (B) Basic Protection of Authentication Secrets also talks about Authentication Secrets and not Credential Stores.

 

--- Eric

 

 

--

David Langenberg

Identity & Access Management Architect

The University of Chicago