Multifactor AuthN:It Isn’t Just for Auditors Anymore

Rob Carter & Shilen Patel, Duke University

Fall, 2011 Internet2 Member Meeting

But first, a few words from our security office...

Passwords are the problem

Password phishing

5% success rate spearphishing

Some users have had local passwords speared repeatedly

Passwords are the problemHash crackers & GPUs

SO demo: random pw’s on a single std. video card

5-char: 4 min, 8-char: 45 days

Linear decomp, scaling

$25k ==> 8-char ~ 8 hrs

Password reuse + one weak external system...

...and a word from our auditors...

You’ve Got Policy Problems

Institutional expiration, complexity policies considered too weak

Crack efficiency rises faster than password policies harden

maybe always will...

kpmg(sis,erp) ~= FAIL

...and a few from our users...

Passwords are a different kind of problem...

You already make my password impossibly hard

If I have to change it frequently, I’ll have to write it down

If I have to pick one suddenly, it’ll be weak

Isn’t the system already secure?

Guess where that leaves us?

Auditors say we need to do something

Security says we need to do it quickly

Users won’t accept strict password policies

We’ve no way out but up...

Multifactor AuthN seems the answer

Physical factors aren’t phishable

Auditors love N-factor AuthN

Security Office loves it, too

Not all application contexts have the same requirements or capabilities

Institutional security goals often run counter to applications’ ease-of-use goals

Everybody needs a little give and take...

Flexibility is critical

...especially the users.

Tenured Professor: “You use the same password for my HR benefits that I give my secretary so she can read my email. This is an outrage!”

Something’s definitely an outrage, here, but...

...maybe we can use this as a carrot to the auditors’ stick...

...but it’ll require more than the traditional approach to multifactor authentication...

Traditional single-mode multifactor is a non-starter

Authmech = f(organization)

one-size-fits-all -- that always works

University users aren’t exactly a captive audience

Second factors are always attractive targets (viz RSA) -- want to avoid lock-in

Multimode solution seems more attractive...

Authmech = f(app,user) (or even f(app,user,location))

f() = Max(user(app),app(user),institution(app,user))

Prof W. can self-select a higher bar for his logins to his blog, while we can raise the bar for logins to grant mgt.

Another RSA-type hack could force us to change mechanisms...

...and besides... it’s good enough for Google Accounts

Low-hanging fruit strategy

Start with the IDP

700+ on-campus SPs and growing already

If we’re careful, most SPs won’t need to do anything and their users won’t notice anything

Infrastructure behind the IDP can be reused

New apps are largely web-based; older apps continue to grow better web interfaces

But shouldn’t it be the SP’s problem?

Perhaps, but...

...SP<->IDP conversation lacks full negotiation, so...

...negotiation would require multiple SP round-trips,...

...and would likely require app awareness,...

...but application authors aren’t usually that savvy

Guess where we are again?

IDP Login Page (jsp)

Custom multifactor "external" authmech

Plug-In Plug-In Plug-In

Plugin API

AuthSvc

AuthSvc

Rules

Prefs

New IDP external authmechPluggable interface for custom credential verifiers

Recognizes different strength values for different credential types

Computes required strength based on claimed identity and SP making request.

IDP Login Page (jsp)

Custom multifactor "external" authmech

Plug-In Plug-In Plug-In

Plugin API

AuthSvc

AuthSvc

Rules

Prefs

New IDP external authmechIDP Login Extensions

ajaxy and context sensitive

authN options depend on user capabilities and preferences

constrained feedback to defeat incremental attacks

IDP Login Page (jsp)

Custom multifactor "external" authmech

Plug-In Plug-In Plug-In

Plugin API

AuthSvc

AuthSvc

Rules

Prefs

New IDP external authmechData repositories for rules and preferences

IDP stores mech strength rules locally

LDAP stores user, SP specific data

Considering Grouper as replacement for one or both to enhance generality

IDP Login Page (jsp)

Custom multifactor "external" authmech

Plug-In Plug-In Plug-In

Plugin API

AuthSvc

AuthSvc

Rules

Prefs

SP1 SP2

SSO Handler

How’re y’gonna keep ‘em on the farm?

SSO becomes an issue across disparate SPs

Built-in previous session handler doesn’t understand strength

We disable it and supply SSO in the external authmech itself

IDP Login Page (jsp)

Custom multifactor "external" authmech

Plug-In Plug-In Plug-In

Plugin API

AuthSvc

AuthSvc

Rules

Prefs

SP1 SP2

SSO Handler

How’re y’gonna keep ‘em on the farm?

Record authN strength factor (sum) in login context (auth method)

SSO implements >= semantics -- SSO succeeds iff previous session method strength >= current requirement

On SSO failure, require all new creds from user

Novel Use Cases

Sometimes a password may not be required (WS)

If no one specifies anything, UI can look just like before

If an SP explicitly lowers its expectations, new options arise

Default numeric strength requirement = 1 (equiv to “password only”)

Allow OpenID gateway as option for SPs requiring strength < 1

Demos, Demos, Demos