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