Your SlideShare is downloading. ×
2012-03 MultiFactor Not Just For Auditors
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

2012-03 MultiFactor Not Just For Auditors

105
views

Published on

2012-03 MultiFactor Not Just For Auditors by Rob Carter, …

2012-03 MultiFactor Not Just For Auditors by Rob Carter,
Consultant at Duke Univeristy

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
105
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Multifactor AuthN:It Isn’t Just for AuditorsAnymoreRob Carter & Shilen Patel, Duke UniversityFall, 2011 Internet2 Member Meeting
  • 2. But first, a few words fromour security office...
  • 3. Passwords are the problemPassword phishing 5% success rate spearphishingSome users have hadlocal passwordsspeared repeatedly
  • 4. Passwords are the problemHash crackers & GPUsSO demo: random pw’s ona single std. video card 5-char: 4 min, 8-char: 45 daysLinear decomp, scaling $25k ==> 8-char ~ 8 hrsPassword reuse + oneweak external system...
  • 5. ...and a word from ourauditors...
  • 6. You’ve Got Policy ProblemsInstitutional expiration,complexity policiesconsidered too weakCrack efficiency risesfaster than passwordpolicies harden maybe always will...kpmg(sis,erp) ~= FAIL
  • 7. ...and a few from ourusers...
  • 8. 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?
  • 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
  • 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
  • 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...
  • 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 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...
  • 13. Traditional single-modemultifactor 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
  • 14. 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
  • 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
  • 16. 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
  • 17. Guess where we are again?
  • 18. New IDP external authmech Pluggable interface for custom credential verifiers 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.
  • 19. 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
  • 20. 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 specific data IDP Login Page (jsp) Prefs Considering Grouper as replacement for one or both to enhance generality
  • 21. 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
  • 22. 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
  • 23. Novel Use Cases Sometimes a password may not be required (WS)If no one specifies 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
  • 24. Demos, Demos, Demos