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

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

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

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

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

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

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

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

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?

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

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

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

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 ‘em
on 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 ‘em
on 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 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

24. Demos, Demos, Demos