Multifactor AuthN: It Isn t Just for Auditors Anymore. Rob Carter & Shilen Patel, Duke University Fall, 2011 Internet2 Member Meeting

Transcription

1 Multifactor AuthN: It Isn t Just for Auditors Anymore Rob Carter & Shilen Patel, Duke University Fall, 2011 Internet2 Member Meeting 1

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

3 Passwords are the problem Password phishing 5% success rate spearphishing Some users have had local passwords speared repeatedly 3

4 Passwords are the problem Hash 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... 4

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

6 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 6

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

8 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? 8

9 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 9

10 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 10

11 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... 11

12 ...especially the users. Tenured Professor: You use the same password for my HR benefits that I give my secretary so she can read my . 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... 12

13 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 13

14 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 14

15 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 15

16 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 16

17 Guess where we are again? 17

18 New IDP external authmech Pluggable interface for custom credential verifiers Auth Svc Auth Svc Recognizes different strength values for different credential types Computes required strength based on claimed identity and SP making request. Plug-In Plug-In Plug-In Plugin API Custom multifactor "external" authmech IDP Login Page (jsp) Rules Prefs 18

19 New IDP external authmech IDP Login Extensions ajaxy and context sensitive Auth Svc Auth Svc authn options depend on user capabilities and preferences Plug-In Plug-In Plug-In Plugin API Custom multifactor "external" authmech IDP Login Page (jsp) Rules Prefs constrained feedback to defeat incremental attacks 19

20 New IDP external authmech Data repositories for rules and preferences IDP stores mech strength rules locally LDAP stores user, SP specific data Auth Svc Auth Svc Plug-In Plug-In Plug-In Plugin API Custom multifactor "external" authmech Rules Considering Grouper as replacement for one or both to enhance generality IDP Login Page (jsp) Prefs 20

21 How re y gonna keep em on the farm? SSO becomes an issue across disparate SPs Auth Svc Auth Svc Built-in previous session handler doesn t understand strength Plug-In Plug-In Plug-In Plugin API Custom multifactor "external" authmech SSO Handler IDP Login Page (jsp) Rules Prefs We disable it and supply SSO in the external authmech itself SP1 SP2 21

22 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 Auth Svc Auth Svc Plug-In Plug-In Plug-In Plugin API Custom multifactor "external" authmech SP1 SSO Handler IDP Login Page (jsp) SP2 Rules Prefs 22

23 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 23

24 Demos, Demos, Demos 24