Strong Authentication Project Update for NPTF 4/21/2008

Strong Authentication

Project Update for NPTF4/21/2008

Agenda

• Review Project– Background and Goals

– Methodology

• Implementation Requirements

• Review the Options

• Recommendations

• Challenges and Risks

• Resources and Schedule for Development


Background

Key Concerns with Authentication• Increase in password theft

• Increased likelihood of password cracking

• Mobile computing

• Increased demand for credentials

• Levels of assurance

• Positioning Penn for the future


Project Goal

Publish a specific set of recommendations for improvements to PennKey and for strengthening Penn web authentication to protect University assets and individuals’ private data.


Methodology

• Divide Into Five Related Sub Projects:– Establish Central Authentication Log

– Strengthen PennKey Passwords

– Update Web Authentication Infrastructure

– Supplement Re-usable Passwords

– Enable Multiple Levels of Assurance


RequirementsEstablish Central Authentication Log

• Centrally collect information about login attempts– Service Name

– Access Time

– Originating IP Address

– Success or Failure

• Phase 1 – Identify participants and collect the data

• Phase 2 – Create and deploy tools to query the data

• Phase 3 – Integrate fraud monitoring software


RequirementsStrengthen PennKey Passwords

• Increase the minimum complexity required for Penn Key passwords

• Establish communications plan to inform:– End users

– Application owners

– Local support providers

– System administrators


RequirementsUpdate Web Authentication Infrastructure

• Provide a replacement for websec that:– Addresses current security vulnerabilities– Supports web-based Kerberos authentication– Supports multiple authentication factors– Supports Kerberized single sign-on– Supports integration with Shibboleth


RequirementsSupplement Re-usable Passwords

• Develop a process that:– Identifies which applications must require a second

authentication factor

– Defines the procedures an application which provides sensitive data must follow

• Recommend a two-factor solution that:– Integrates with the websec replacement

– Can be deployed on a per application basis

– Can be replaced without recreating accounts


RequirementsEnable Multiple Levels of Assurance

• Position the University to support multiple levels of assurance for both authentication and I.D. proofing

• Outline a policy that application developers can use to identify the level of assurance required for that application

• Specify the technical security requirements for each level of assurance


• Options:– Real time data upload

– Periodic batch upload

• Recommendation:– Support both real time and periodic uploads of log data

– Real time will be preferred but not required

• Option:– Require all Level of Assurance 3 applications to contribute to the logs, regardless of

their participation in central authentication?

• Recommendation:– Systems using common user identifiers such as Penn ID or Penn Name should be

enabled but not required to contribute


Options and RecommendationsEstablish Central Authentication Logging

• Option:– In addition to authentication data, should application usage data (i.e. SSN access)

be logged in this repository as well?

• Recommendation:– This possibility should be enabled but not required. Application participation

should be based on a project by project cost-benefit analysis.


Options and RecommendationsEstablish Central Authentication Logging

• Options:– Increase the complexity of passwords, but allow them to remain shorter.

– Transition from a password model to a passphrase model.

• Considerations– Passwords do not expire or lock, so they must be able to withstand a long period of

brute force guessing

– Password complexity increases exponentially with length, but only cubically with alphabet

• A 15 character password with only lowercase letters will take 23 years to break

• A 10 character password with 1 upper, 1 number, and 1 special character will take only 81 days to break.

– Difficult to remember passwords will be written down (and stolen) or forgotten• jnrUf5@&pM versus theredandtheblue


Options and Recommendations Strengthen PennKey Passwords

• Recommendation:– Promote a minimum password length of 15 characters, with pass phrases

encouraged• The phrase may contain dictionary words, but not ascending/repeating sequences (i.e.

‘aaa’ or ‘123’)

• No other onerous complexity restrictions on phrases of this length, so they are easy to remember without being written down

– Users desiring a shorter 10 character password can add numbers, upper case letters, and special characters to achieve a higher complexity.

• Challenges / Risks– Communication and coordination with support providers will be essential

– It is burdensome to ask users to learn new password rules and change their passwords, so it cannot be done frequently

– Some automated systems, such as those creating Guest PennKeys will have to be modified to generate legal passwords



• Options:– Expire existing PennKey passwords when the complexity rules change

– Grandfather all existing PennKey passwords until the user chooses to change them

– Have a phased rollout period to encourage the community to change passwords over time



• Recommendation:– Have a phased rollout period to encourage the community to change passwords

over time as part of the Cosign authentication process• For users who have not changed their password the success screen should contain links to either update

their password or continue to their destination.

• After 4 months, the success screen would be replaced with the password change screen for these users. A link would be provided to skip this step and continue to their destination.

• After an additional 4 months, the link to skip the password change step would be removed.

– Users changing their password should get real time validation of their choice (i.e. Microsoft Live, Google)

– Passwords that aren’t changed should not expire automatically at any point

• Challenges / Risks– Users who do not use web applications would not be prompted to change their

passwords

– All PennKey holders would have to make this change, including alumni



• Options:– Stanford WebAuth

• Self Service Provisioning

• Logout via timeout only

• Shibboleth Interoperability as an Identity Provider

• Only supports Apache, no IIS support

• No native support for multiple factors

• Single Sign On with Shared Secret

– Cosign (University of Michigan)• Provisioning by ISC

• Global logout supported

• Shibboleth Interoperability must be developed

• Supports IIS and Apache

• Native Multifactor Support

• Single Sign On with Shared Secret


Options and Recommendations Update Web Authentication Infrastructure

• Recommendation:– Replace Websec with Cosign

• Provides very modular multi-factor support

• Supports both IIS and Apache web servers

• Supports a global logout

• Has an integration library for java web applications

– Integrate Cosign with Shibboleth

• Migration costs– Service certificates require a self-provisioning interface

– Depending on the technology, 1-3 hours migration time per application

– Custom login pages no longer supported

– SSL Costs for web servers not currently supporting SSL traffic


Options and Recommendations Update Web Authentication Infrastructure

• Options:– Hardware tokens

– Software tokens

– Virtual two factor

– Biometrics

• Recommendation:– Use Hardware tokens as Penn’s second authentication factor

• Software tokens can be compromised if the desktop/device they are running on are compromised

• Virtual two factor does not protect against replay attacks and commonly involve secrets easily stolen

• Biometric solutions are very expensive to deploy, and cannot easily be replaced if compromised

– Tokens should be easy to use and carry with no input required from users

– Vendor solutions should integrate with Active Directory


Options and Recommendations Supplement Re-usable Passwords

Integrate with Kerberos, always use both factors

• Pros:– Strengthen PennKey

– No user confusion

• Cons:– Onerous usability demands for users

– All applications behave at the same level of assurance, regardless of sensitivity

• Notes:– May also work with Active Directory where PennKey is used

– Moderate cost to roll out and maintain, but lower cost for modifying existing infrastructure


Options and Recommendations Supplement Re-usable Passwords: Two Factor Architecture Options

Integrate with Kerberos, users are given two credentials (one with and one without 2-factor enabled)

• Pros:– Strengthen PennKey

– Variable levels of assurance based on data sensitivity

• Cons:– User confusion on when to use which credential

– Significant technical issues for authorization and single sign-on

• Notes:– Does not work with Active Directory

– May require additional KDCs



Decouple from Kerberos, enable on a per-application basis

• Pros:– Variable levels of assurance based on data sensitivity

– Works directly with Cosign

• Cons:– Doesn’t strengthen PennKey

– Requires additional infrastructure to be bought

– Less secure, since credentials can be attacked separately

• Notes:– Works with Active Directory

– Applications not using Cosign or not supported natively by the vendor would require rework to use

– Could be used with systems not using PennKey



• Recommendations:– Deploy a decoupled solution today

• Easiest for end-users to adopt

• Easiest to pilot by application without impact on other applications

• Makes Penn a more a hardened, unattractive target

– Re-evaluate with an eye towards an integrated solution in 4-5 years.• MIT Kerberos may evolve to make LOA-based two-factor possible

• Users may be better positioned to accept two-factor for everyday use

• It may be necessary as phishing and password cracking becomes more sophisticated



• Options:– Employ a 3 level of assurance hierarchy

– Employ a 4 level of assurance hierarchy

• Recommendation:– Employ a 3 level of assurance hierarchy:

• Level 1 - Little or no confidence in the asserted identity's validity

• Level 2 - Some confidence in the asserted identity’s validity

• Level 3 - Highest confidence in the asserted identity’s validity

– Required level will be based on risk assessment matrix of the likelihood and possible extent of harm to:

• University reputation

• University financial loss or liability

• University’s academic, research, or administrative functions

• Individual user

• Personal safety


Options and Recommendations Enable Multiple Levels of Assurance

• Options:– Contract to a 3rd party to perform remote ID proofing using credit report data

– Identify a secret known only by both Penn and PennKey holders to use for remote ID proofing

– Continue to use the slow U.S. Mail system employed today

• Recommendation:– 3rd party remote ID proofing services should not be employed

• Sensitivity of the data considered is unacceptable to the desired audience

– The scope of this issue seems to fall under the purview of Bill Branan’s Streamlining PennKey initiative


Options and Recommendations Enable Multiple Levels of Assurance

• Strong Authentication Really Five Projects– Establish Central Authentication Log

• ISC Networking and Telecommunications

– Strengthen PennKey Passwords• ISC Administrative Information Technologies & Communications

– Update Web Authentication Infrastructure• ISC Networking and Telecommunications

– Implement Two Factor• ISC Networking and Telecommunications

– PennKey Authentication Policies• ISC Administrative Information Technologies & Communications


Design and Development

ISC Information Security

Robin Beck, ISC

Executive Sponsor/Owner

Dan Alig, Wharton Mark Aseltine, ISC TSS Chris Bradie, Business Services Jim Choate, ISC ASTT Jeanne Curtis, ISC AIT Deke Kassabian, ISC Networking & Telecom Doug Brunk, School of Medicine Dave Millar, ISC Information Security Bill Ramirez, ISC SEO Lauren Steinfeld, OACP Steve Stines, OACP Gary Truhlar, Human Resources Mike Winkler, Library Ira Winston, SAS, SEAS, Design

Advisory Group

Jim Choate, ISC

Program Manager

Central Authentication Log ISC N&T

Project Coordination Team Strengthen PennKey Passwords

ISC AIT & Communications

Implement Cosign ISC N&T

Implement Two-Factor ISC N&T

PennKey Authentication Policy ISC AIT & Data Administration

Bryan Hopkins, ISC ASTT Dave Millar, ISC Information Security Project Leader, ISC N&T Strengthen PennKey Project Leader, ISC Bill Branan, ISC AIT

Organization

• Establish Central Authentication Log– ISC Networking and Telecommunications

– Begin Phase 1 in June 2008

– Estimated Completion Dates• Phase 1 – February 2009

• Phase 2 – June 2009

• Phase 3 – October 2009

• Receive log information from all non-Cosign applications by February 2010– RADIUS Clients– Jabber– Kite– Library Web Proxy


Design and DevelopmentEstablish Central Authentication Log

• Strengthen PennKey Passwords– ISC Administrative Information Technology & Communications

– Begin September 2008

– Dependencies:• Cosign conversion

• Develop transition and password change web application

– Estimated Timeframe and Completion Date• Begin the password transition period January 2009

• Password change no longer optional by September 2009


Design and DevelopmentStrengthen PennKey Passwords

• Implement Cosign– ISC Networking and Telecommunications

– Begin May 2008

– Dependencies• Penn Name to Penn Id conversion service (Central Authorization project)

– Estimated Timeframe and Completion Date• ISC Pilot by August 2008

• Rollout and transition existing Websec applications to Cosign by September 2009

• Password change tool to be available by January 2009


Design and DevelopmentUpdate Web Authentication Infrastructure

• Implement Two Factor– ISC Networking and Telecommunications

– Begin July 2008

– Estimated Timeframe and Completion Date• Identify Two Factor Token Vendor by May 2009

• Launch a small scale pilot by August 2009

• Broader pilot and ongoing rollouts to Level of Assurance 3 applications ongoing


Design and DevelopmentSupplement Reusable Passwords

• PennKey Authentication Policies– ISC Administrative Information Technology & Data Administration

– Begin May 2008

– Part of the Streamlining PennKey Initiative

– Estimated Timeframe and Completion Date• Have policies available for public comment period by August 2008


Design and DevelopmentEnable Multiple Levels of Assurance


Design and DevelopmentPreliminary High Level Timeline

Identify Vendor / Trial Testing Contract Integration ISC Pilot Broader PilotSupport Ongoing Rollouts …

Development ISC Pilot Rollout and Transition for all websec applications

Develop Infrastructure Get Data / Develop Query Tool Fraud Detection

Development User Password Change Grace Period

First Draft of Policies Public Comment and Review

06/08 07/08 08/08 09/08 10/08 11/08 12/08 01/09 02/09 03/09 04/09 05/09 06/09 07/09 08/09 09/09 10/09 11/09 12/09

Implement 2-factor

Implement Cosign

Central Authentication Logging

Strengthen Passwords

PennKey Authentication Policies

• Questions?



Documents

Strong Authentication Project Update for NPTF 4/21/2008