Assurance

[Eric Goodman <>]

> 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