Assurance

["Lovaas,Steven" <>]

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