Sunteți pe pagina 1din 52

Multi-Factor Authentication in Higher Education

Todays Speakers
David Walker, Scalable Privacy Project Brendan Bellina, University of Southern California Paul Caskey, University of Texas System Bryan Wooten, University of Utah Bill Thompson, Unicon, Inc.

David Walker, Scalable Privacy Project

What Is Multi-Factor Authentication?

Multiple factors required during authentication

Something you know (e.g., passwords) Something you have (e.g., tokens) Something you are (biometrics)

Each factor mitigates risks of other factors

Tokens mitigate the risk of password phishing Passwords mitigate the risk of token theft

Examples of MFA

Token + PIN Password + cellphone confirmation Single-Factors that may be combined with others to achieve MFA

One-Time Password Biometric Pass phrase

Why Deploy MFA?

Improve on passwords by mitigating the risks of phishing, etc.

Common goal for Google, Facebook, et al Often provided as an option for end-users

Require for specific applications Require as part of an assurance profile

Federal LoA 3 and LoA 4 Potential strategy for InCommon Silver (LoA 2)

The Scalable Privacy Project

2+ year NSTIC grant to Internet2/InCommon Multiple focal points

Promotion of multi-factor authentication (MFA) Citizen-centric attributes and schema Development and deployment of privacy managers Introduction of anonymous credentials

Promotion of MFA

Three pilot deployments

Massachusetts Institute of Technology (MIT) University of Texas System University of Utah

Software infrastructure The MFA Cohortium

Software Infrastructure

Enhancements for Shibboleth and CAS

Coordinate sessions with services requiring differing authentication strengths, including MFA

Partnership with the InCommon Assurance Program for Bronze and Silver


Open source client certificate management system Includes device boarding

The MFA Cohortium

~40 institutions exploring multi-factor authentication

Most wondering what they should do Many starting to deploy A few with mature deployments

Three subgroups

Business Case for MFA Deployment Strategies Technology and Product/Vendor Issues

Can I Use Cohortium in Cohortium: "Group of institutions sharing their Scrabble? explorations, experiences, expertise, artifacts, and
overall journey", in this case of planning for and deploying multi-factor authentication. Cohort: In statistics and demography, a cohort is a group of subjects who have shared a particular event together during a particular time span [cohort (statistics) from Wikipedia]. -tium: added to noun base to create abstract noun, "something connected with the act", could mean "act, condition, office of...".

Cohortium Work Products - 1

The business case for multi-factor authentication

Alignment with institutional mission Mitigation of risk Costs and cost recovery

Deployment strategies

Initial deployment strategies Gaining community acceptance Business continuity when tokens are not available

Cohortium Work Products - 2

Technology issues

Evaluation criteria for MFA solutions Architectural integration patterns Usability Accessibility

Policy issues

How much security is enough? FERPA and other compliance frameworks

More about the Cohortium

The MFA Cohortium Wiki

How to Join

January is Data Privacy Month!

Learn more at

Brendan Bellina, University of Southern California

University of Southern California

Who needs access to our systems? - 40,000 current students (45% undergraduate) - 3,500 active faculty - 12,000 active staff - 6,400 sponsored affiliates (VIPs) - 300 external guests (self-registered) - 2,600+ organization/dept/class accounts - Over 120,000 accounts

Why Considering Multi-Factor?

Even Strong Passwords are insufficient to protect: - access to protected machines - users with elevated privileges - applications that contain sensitive data - application functions that require additional security Due to: - Phishing and poor password handling practices - Weaknesses in account lifecycle management - Shared accounts

General Technical Challenges

- Scalability - Distribution and management of hardware tokens - Affordability - Initial purchase and replacement costs - Supportability - Remote users, staffing requirements - Ease of use - It is very difficult to implement in a way that people will not complain about.

General Policy Challenges

- How to determine what users should be affected? - How to determine what applications should be affected? - How to determine what systems should be affected? - How to manage the above as: - users change roles and positions - applications alter functionality and data - systems alter connectivity, platform, and OS Far, far more to this than just setting up a pilot.

Things to Consider
- Alternative to password should be: - ubiquitous - zero cost - easy to use - Hardware tokens? How scalable? - Smart phone/cell phone? If given the number. - Personal Email? If given the address. - Social Logins (Facebook, Twitter). If registered.

Current Implementation
- Hardware tokens have been used by Information Security, Auxiliary Services, and Hospitality for over a year. - ITS Information Security will be deploying soft tokens (app on smart phone) to hundreds of people for PCI compliance in the next few weeks. - ITS Information Security will be deploying the same soft tokens to system administrators of financial systems, the Student Information System, and core infrastructure in the very near future.

Future Plans
- 2014 Pilot using cell/email/oAuth for Self-Service Password Reset functionality. - CIO is very interested in pursuing multiple levels of security based on risk, with emphasis on value and risk mitigation. - Determination of how applications, users, and systems should be selected and managed will come from Information Technology Services leadership to the USC Information Risk Committee (proposed by the CIO). - Pilot a selected set of applications and users. - Plan further expansion.

Paul Caskey, University of Texas System

Driving Factors

Phishing Malware/Keystroke loggers Passwords alone, in any form, have rapidly delining utility for protecting anything from a determined attacker.

Confidential data Scope of access Strengthening of social IDs?

Where Were At Now

NSTIC MFA grant for piloting Duo Security Also piloting Toopher technology (location awareness) A few pilots started across 5 or 6 institutions Some limited production deployments Public computers Remote access No mass deployment yet System-wide policy likely to include some MFA

Impediments to Broad Deployment

User convenience still rules? Non-tech users? Password strength denial Who owns authentication? Proactive vs Reactive? Rapid change of technology Consumerization Increasing sophistication of criminals/malware Cost? Technology deployment challenges No cell phone, lost/forgotten tokens, etc.

Bryan Wooten, University of Utah

University of Utah Current Tech


200+ Applications Internal and Cloud (ie Canvas)

OpenDJ LDAP Shibboleth

External / Cloud Applications Only

Active Directory Grouper (early Alpha)

Current MFA Projects

Cisco Routers / Switches /


EPIC Electronic Medical Records

AIX Backend Servers - DUO

Payment Card Servers (PCI)

Evaluations in progress

NSTIC Challenges
UofU is only CAS pilot CAS Client vs Shibboleth SP Many clients vs. one code base Different feature set

Funding MFA Licenses vs. Development

Add value to broader CAS community Collaboration Unicon, UC Berkeley, UC Riverside, Evergreen College

NSTIC Use Cases / Requirements

Application configured to force all users authenticate with MFA HIPAA, FERPA Individual Users must always authenticate with MFA Users with Elevated Privileges

Application allows either Single Factor or MFA authentication Functionality determined by authentication method

User Opt-in / Opt-out Stretch goal

Token or Mobile MFA Backward compatible

Bill Thompson Unicon, Inc.

Theme: boutique commodity

2fa is currently boutique and custom rather than commodity and ubiquitous.

moving from custom to commodity experimentation and innovation supports and complements commoditization

(without interesting experiments, how do you know what is worth commoditizing?)

Licensing costs?
From the abstract:

More competitive licensing options for MFA, as well as expanding MFA technologies (e.g. mobile/app/phonebased solutions), are helping to address a significant factor -- cost -- for deploying and supporting MFA.

No. Complexity cost.

Licensing cost (or other costs of 2fa tokens) is a problem, but its not the problem.

The problem is what would you do with 2fa if you had it?

Who uses what to access what, how? And how is this experience usable enough that this actually works?

What problem are we solving here?

Example 1: Ryerson 2fa

Boutique and awesome. Crafted with love. Ryerson-specific smartphone app based on open source Google Authenticator.

Web-based second password solution for folks bereft of smart phones.

Zero licensing costs to anyone (that was never the problem)

Backed by Ryersons custom SIS services.


What we have here is a lovingly crafted solution that works for Ryerson.

And some (open source!) starting points for your 2fa implementation.

But not commoditization

To replicate: Just add love, sweat, thought, care, craft, institutional policy, user education, support, and processes. No biggie!

Who, what, what, how?

Who should be prompted when accessing what?

Dunno. Ask the (custom) SIS!

Whats the additional authentication factor?

OATH TOTP as implemented by Ryerson-custom smartphone app. Fallback on second static password for the smartphone have-nots.

How is the authentication factor experienced?

Customizations to CAS single sign-on login.

Example 2: Evergreen: Multi-factor authentication add-on for CAS 3.5 commodity?

Free and open source software

Factors are sub-flows

Spring Web Flow sub-flows Combine:

UI Logic Backing Java

Plugged into the regular CAS login flow Modularity. Pluggability. Commoditization.

Who authenticates how to what?

Specified just-in-time via a request parameter, set by the relying party

Very CAS-like. Lightweight. Adhoc.

Whats the authentication factor?

It happens to be one-time passwords generated by proprietary tokens and validated via RADIUS against a proprietary token management server

But its just a CAS AuthenticationHandler. Could have been another AuthenticationHandler. Like, say, the developed-for-Ryerson OATH TOPT AuthenticationHandler.


How is it experienced?

CAS sub-flow. So, as part of single sign-on CAS remembers fulfilled authentication methods within the single sign-on session. Requires any given method at most once.

Thats an experience decision. Think about it. Boutique.

Moving towards commoditization

You can do a lot with JIT decision-making by the relying party about authentication method

But thats not the same thing as LOA And more generally you may want to centralize configuration. Service registry?

Methods are just AuthenticationHandlers With experiences via Spring Web Flow sub-flows Commoditization.

Open Two Factor Free and open source software Self-service user binding to OATH tokens


More and better open source starting points Next versions of CAS and of Shibboleth IdP modeling more complexity and nuance in the core product

Local implementation becomes more feasible