Assurance

["Jones, Mark B" <>]

I don’t think Eric was suggesting that “a single user record has multiple passwords” but that they are operating two distinct authentication mechanisms.  (Correct me if I am wrong)  So knowing one password would not compromise systems attached to that separate authentication mechanism.

 

The term ‘credential’ seems to have as many definitions as people who use it.  I’m not sure how you are using it.  But I think the point of that section is to be sure the IdPO is protecting  the user’s password everywhere it is used and not just when it is used to authenticate to the IdP.

 

At first I was going to respond that we only use one password, but that may depend on your perspective.  We have been striving for compliance with NIST LoA2 for our ‘we use it for everything’ password.  So, email, ERP, and all the other miscellaneous applications and services we use as students, employees, or faculty.  But we do have systems on campus that use a different password.  A case in point is our employment application site.  There, potential employees establish an LoA 1 identity where they self assert their information and set their own username and password.  This is a completely separate authentication mechanism.  And there are other examples of systems where LoA 1 is sufficient and most convenient for users.  Currently each of these are maintaining their own authentication mechanism in whatever way is most convenient.  But for all of these LoA 1 systems we have “Little or no confidence in the asserted identity’s validity” (OMB M-04-04), which is just fine.

 

From: [mailto:] On Behalf Of Lovaas,Steven
Sent: Monday, August 20, 2012 12:44 PM
To:
Subject: RE: [Assurance] dept's leveraging central authentication systems ....

 

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: [] 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