Assurance

[David Langenberg <>]

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