Passwords are a differentkind 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 Ofﬁce loves it, too
Flexibility is critical 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...
...especially the users. Tenured Professor: “You use the same password for my HR beneﬁts that I give my secretary so she can read my email. This is an outrage!” Something’s deﬁnitely 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-modemultifactor is a non-starter Authmech = f(organization) one-size-ﬁts-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 seemsmore 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 hisblog, while we can raise the bar for logins to grant mgt.Another RSA-type hack could force us to changemechanisms......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’sproblem? 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
New IDP external authmech Pluggable interface for custom credential veriﬁers Auth Svc Auth Svc Recognizes different strength values for Plug-In Plug-In Plug-In Rules different credential Plugin API Custom multifactor "external" authmech types IDP Login Page (jsp) Prefs Computes required strength based on claimed identity and SP making request.
New IDP external authmech IDP Login Extensions ajaxy and context Auth Svc Auth Svc sensitive authN options Plug-In Plug-In Plug-In depend on user Rules Plugin API Custom multifactor "external" authmech capabilities and preferences IDP Login Page (jsp) Prefs constrained feedback to defeat incremental attacks
New IDP external authmech Data repositories for rules and preferences Auth Auth Svc Svc IDP stores mech strength rules locally Plug-In Plug-In Plug-In LDAP stores user, Rules Plugin API Custom multifactor "external" authmech SP speciﬁc data IDP Login Page (jsp) Prefs Considering Grouper as replacement for one or both to enhance generality
How’re y’gonna keep ‘emon the farm? Auth Auth SSO becomes an issue Svc Svc across disparate SPs Plug-In Plug-In Plug-In Built-in previous Plugin API Rules session handler Custom multifactor "external" authmech SSO Handler doesn’t understand IDP Login Page (jsp) Prefs strength We disable it and supply SSO in the SP1 SP2 external authmech itself
How’re y’gonna keep ‘emon the farm? Record authN strength Auth Svc Auth Svc factor (sum) in login context (auth method) Plug-In Plug-In Plug-In Rules SSO implements >= Plugin API Custom multifactor "external" authmech semantics -- SSO SSO Handler succeeds iff previous IDP Login Page (jsp) Prefs session method strength >= current requirement SP1 SP2 On SSO failure, require all new creds from user
Novel Use Cases Sometimes a password may not be required (WS)If no one speciﬁes anything, UI can look just like beforeIf an SP explicitly lowers its expectations, new optionsarise Default numeric strength requirement = 1 (equiv to “password only”) Allow OpenID gateway as option for SPs requiring strength < 1