Assurance

[Eric Goodman <>]

No, not both, the "Silver" password is intended for "LoA2". The other is intended for "no LoA assertion made".

A lot of it clearly comes down to the interpretation of the requirement. Back when we made the decision, we knew of a multitude of centrally-managed systems that had not switched to requiring secure protocols (and in some cases didn't support an of them), so we didn't see it as something we could assert given our own division was breaking the desired policy.

But from a conceptual standpoint, standing up any of Kerberos, LDAP or AD in a standard "open-access" configuration implies that you are allowing access. Assuming a policy of "don't use this without securely handling the passwords", how much control/monitoring of that use is considered good enough to meet the requirements of LoA 2? 

--- Eric

On Mon, Aug 20, 2012 at 4:38 PM, Jones, Mark B <> wrote:

I don’t read this section as making it required that inappropriate use of passwords be absolutely controllable, only that there must be policy/procedure in place that addresses the issue.  After all, this is only LoA 2.

 

When you talk about a “two-password” solution vs. a “multifactor” solution, are you considering both solutions Silver (LoA 2)?  I think the question should be which LoA is required?  If LoA 2 is sufficient why bother with multifactor?  If LoA 3 is required then we should be going through the effort to implement multifactor even if that is not convenient.

 

As far as deciding which LoA is needed, does the “2.2. Risks, Potential Impacts, and Assurance Levels” section of OMB M-04-04 apply to our community?

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Monday, August 20, 2012 1:32 PM

To:
Subject: Re: [Assurance] dept's leveraging central authentication systems ....

 

Perhaps I’m missing a link in the logic chain, though. Eric, how did you deal with this question?

 

We designed our services so that by itself the non-Silver password does not allow any method to gain access to the Silver password. Assuming we did that correctly we don't think there's an extra issue there. There's no additional strength between the Silver and non-Silver passwords, same composition requirements, dictionary and composition checks, etc. The only real difference is how carefully we monitor the access to and usage of the Silver vs. non-Silver credential by applications.

 

Since we support AD, unix shell, email and other services that rely on "unrestricted" -- in the context that you can't control what applications can use it -- authentication mechanisms, that may allow clients to cache passwords locally in potentially insecure formats, or that may not use SSL on the "front end" (from client to proxy) we didn't see any other option to ensure we meet Silver than to require a Silver-specific password. 

 

We make a distinction between the passwords for internal campus purposes as well. So as a hypothetical, if a system was brought up containing HIPAA classified data, we would likely require that system to use our Silver-specific password, or to implement some additional security to mitigate use of the non-Silver password if they needed it for some technical reason.

 

We understand that the two-password solution is less desirable than multifactor -- in fact the same document that states the restrictions around the Silver password also refers to multifactor -- but since we didn't (and don't) have ubiquitous multifactor supported via the central authentication services, this was our next best solution.

 

--- Eric 

 

 

 

On Mon, Aug 20, 2012 at 10:43 AM, Lovaas,Steven <> wrote:

Hello to the list!

 

I haven’t been able to join in the conference calls yet (planning on the next one), but I’ve been following the various conversations as we prepare our own Silver project.

 

This particular thread caught my interest, because it’s a topic we touched on (multiple passwords).

 

Isn’t this a weakest-link problem? What we’re trying to assert is that the credential is being used by the appropriate person, so the real object of assertion is the credential itself, not just the authentication secret. Making the password (strongly) resistant to guessing is a tool, but not the ultimate goal. If a single user record has multiple passwords, one of which is Silver-strong and one of which is not, then cracking the weak password would give an attacker access to the credential and (possibly) to the methods to change the Silver-strong password… or might at least give authenticated access to systems that allow the installation of password-acquisition tools. I think that’s the motivation behind section 4.3.6 #3, and why we’re attempting to use this as an opportunity to strengthen ALL password interfaces throughout our organization.

 

Perhaps I’m missing a link in the logic chain, though. Eric, how did you deal with this question?

 

Are others using a separate credential altogether, or a second password on the main campus credential?

 

Looking forward to the next call…

 

Thanks,

Steve Lovaas

Colorado State University

 

 

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Monday, August 20, 2012 10:38 AM

To:
Subject: Re: [Assurance] dept's leveraging central authentication systems ....

 

This is one of the reasons we went to two different passwords (one intended to be Silver compliant, one not). We don't have any non-web, publicly facing authentication protocols available for our proto-Silver password (i.e., firewalls restrict all those interfaces). And our policies state that use of the proto-Silver password requires approval -- with Shibboleth preferred, and proxy authentication requiring additional approvals.

 

That said, I've already seen cases where application developers have created apps that prompt users for passwords and then screen scrape logins against web applications that do have access, checking for "successful/unsuccessful login" messages on the authorized app. To me that's clearly inappropriate besides being our policies, but not all developers look at things the same way I do, and there's no good way to stop it technically if you don't know that it's happening.

 

--- Eric

On Mon, Aug 20, 2012 at 8:35 AM, Cantor, Scott <> wrote:

On 8/20/12 11:25 AM, "Ann West" <> wrote:
>
>Can you explain what "a policy against such apps" means? Do you mean "a
>policy against non-silver-compliant apps using silver credentials"?

Yes. Telling depts they can't just stand up password harvesting
front-ends. At most sites, that's unenforceable because if nothing else
you have email openly available as a password checker (though that's
changing somewhat with all the outsourcing of email I guess).

I'm very skeptical of such "don't ask, don't tell" approaches to all this,
and yes, that's one of my arguments here for two-factor as you said.

-- Scott