Assurance

[Nick Roy <>]

>> 4. Is "password is never re-used" a requirement?

 

>Not that I’ve seen as a literal practice, though “credential renewal” (4.2.3.4) seems to assume we’re talking about requiring a change. “Never” is a long time, but many implementations of course consider it a best practice to require use of a new password. I don’t think there’s a community consensus on how long passwords should not be reused or how many past values should be restricted.

That can also be extrapolated in the context of your environment, and through discussions with your auditors, in light of the requirements around min-entropy and guessing-entropy.  Typically guessing-entropy is going to be a driver to do things like enforce lockout policies based on failed authentications.  Also, to enforce checking a changed password against (for example) 10 saved password hashes, and minimum password age (so that someone can't just write a script to change their password and cycle back through 10 new passwords back to their original).

Best,

-- 

Nick Roy

Director of Technology and Strategy, InCommon

Internet2, Denver (GMT -6:00)

From: <> on behalf of Eric Goodman
Reply-To: ""
Date: Tuesday, July 7, 2015 at 11:39 AM
To: ""
Cc: Ann West, Chris Dowden, "R. Andrew Johnston", Paul Caskey
Subject: RE: [Assurance] Re: Question for address of record for silver assurance

As Mary said previously, a lot of these are audit questions.

 

I’m providing some answers below based on discussions that have taken place on this list and in other assurance venues in the past. These are not formal “InCommon approved” answers, but represent some of the common thinking among those in the Assurance community looking to implement Silver compliance.

 

--- Eric

 

> 1. What should be minimum chars requirement for silver user password?  Is 12 chars minimum in any way a requirement?

 

The requirement in the spec is “The Authentication Secret shall have at least 10 bits of min-entropy to protect against an untargeted attack.” There is no hard definition. The reference states:

 

A dictionary test is specified here that is intended to ensure at least 10 bits of min-entropy. That test is:

• Upper case letters in passwords are converted to entirely lower case and compared to a dictionary of at least 50,000 commonly selected otherwise legal passwords and rejected if they match any dictionary entry, and

• Passwords that are detectable permutations of the username are not allowed.

This is estimated to ensure at least 10 bits of min-entropy. Other means may be substituted to ensure at least 10 bits of min-entropy. User chosen passwords of at least 15 characters are assumed to have at least 10 bits of min-entropy.

 

In fact, you raise a (probably unintendedly) interesting question, because most of the discussion on this list has been about guessing-entropy, not min-entropy. From the standpoint of meeting min-entropy, arguably there’s not much requirement. However, note that to minimize guessing possibilities, you will in practice need passwords that are of a known, relatively high entropy. 12 characters is not a bad start, but it is not expressly a requirement presuming dictionary tests. (see the quote above).

 

> 2. Are there any crypto requirements we would have to make changes to meet?

 

No one can answer this without knowing your configurations, but again, the requirements are that you use “Approved Algorithms” per the definition. If you use AD for user authentication, take a look at the AD Silver Cookbook (https://spaces.internet2.edu/display/InCAssurance/AD+Silver+Cookbook) for some specific guidance here.

 

> 3. Would we be required to have a method of detecting password guessing?

 

The requirement is that the odds of guessing over the life of the password must be less than 1:2^14. That means that depending on the complexity of the password, the number of failed attempts possible over the lifetime of the password must be limited. The IAP does not provide specific guidance on how this should be done, but it is generally agreed that detecting and counting failed attempts is one valid mechanism (see https://spaces.internet2.edu/display/InCAssurance/Failed+Authentication+Counter+Strawman). Sufficient lockout and password reset requirements are similarly generally agreed to be sufficient (see https://spaces.internet2.edu/display/InCAssurance/Password+Entropy+Calculators).

 

> 4. Is "password is never re-used" a requirement?

 

Not that I’ve seen as a literal practice, though “credential renewal” (4.2.3.4) seems to assume we’re talking about requiring a change. “Never” is a long time, but many implementations of course consider it a best practice to require use of a new password. I don’t think there’s a community consensus on how long passwords should not be reused or how many past values should be restricted.

                                                        

> 5. Is 7.5 years of "Credential Issuance Record Retention" a requirement?

 

Yes, as it states in  4.2.2.3.4.