Strong Authentication

1
Strong Authentication

• Project Update for NPTF
• 4/21/2008

2
Agenda

• Review Project
• Background and Goals
• Methodology
• Implementation Requirements
• Review the Options
• Recommendations
• Challenges and Risks
• Resources and Schedule for Development

3
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

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

5
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

6
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

7
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

8
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

9
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

10
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

11
Options and RecommendationsEstablish Central
Authentication Logging

• 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

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

13
Options and Recommendations Strengthen PennKey
Passwords

• 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_at_pM versus theredandtheblue

14
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

15
Options and Recommendations Strengthen PennKey
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

16
Options and Recommendations Strengthen PennKey
Passwords

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

17
Options and Recommendations Update Web
Authentication Infrastructure

• 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

18
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

19
Options and Recommendations Supplement Re-usable
Passwords

• Options
• Hardware tokens
• Software tokens
• Virtual two factor
• Biometrics
• Recommendation
• Use Hardware tokens as Penns 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

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

• 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

21
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

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

• Decouple from Kerberos, enable on a
  per-application basis
• Pros
• Variable levels of assurance based on data
  sensitivity
• Works directly with Cosign
• Cons
• Doesnt 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

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

• 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

24
Options and Recommendations Enable Multiple
Levels of Assurance

• 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
  identitys validity
• Level 3 - Highest confidence in the asserted
  identitys 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
• Universitys academic, research, or
  administrative functions
• Individual user
• Personal safety

25
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 Branans Streamlining PennKey
  initiative

26
Design and Development

• 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

27
Organization
28
Design and DevelopmentEstablish Central
Authentication Log

• 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

29
Design and DevelopmentStrengthen PennKey
Passwords

• 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

30
Design and DevelopmentUpdate Web Authentication
Infrastructure

• 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

31
Design and DevelopmentSupplement Reusable
Passwords

• 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

32
Design and DevelopmentEnable Multiple Levels of
Assurance

• 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

33
Design and DevelopmentPreliminary High Level
Timeline
    Identify Vendor / Trial Testing Identify Vendor / Trial Testing Identify Vendor / Trial Testing Identify Vendor / Trial Testing Identify Vendor / Trial Testing Identify Vendor / Trial Testing Contract Contract Contract Contract Integration Integration ISC Pilot Broader Pilot Broader Pilot Support Ongoing Rollouts Support Ongoing Rollouts
Development Development Development ISC Pilot Rollout and Transition for all websec applications Rollout and Transition for all websec applications Rollout and Transition for all websec applications Rollout and Transition for all websec applications Rollout and Transition for all websec applications Rollout and Transition for all websec applications Rollout and Transition for all websec applications Rollout and Transition for all websec applications Rollout and Transition for all websec applications Rollout and Transition for all websec applications Rollout and Transition for all websec applications Rollout and Transition for all websec applications      
  Develop Infrastructure Develop Infrastructure Develop Infrastructure Develop Infrastructure Get Data / Develop Query Tool Get Data / Develop Query Tool Get Data / Develop Query Tool Get Data / Develop Query Tool Fraud Detection Fraud Detection Fraud Detection Fraud Detection  
  Development Development Development Development User Password Change Grace Period User Password Change Grace Period User Password Change Grace Period User Password Change Grace Period User Password Change Grace Period User Password Change Grace Period User Password Change Grace Period User Password Change Grace Period  
First Draft of Policies First Draft of Policies First Draft of Policies Public Comment and Review Public Comment and Review Public Comment and Review Public Comment and Review Public Comment and Review Public Comment and Review Public Comment and Review Public Comment and Review Public Comment and Review Public Comment and Review Public Comment and Review 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 2-factor Implement 2-factor Implement 2-factor Implement 2-factor  
  Implement Cosign Implement Cosign Implement Cosign Implement Cosign Implement Cosign  
  Central Authentication Logging Central Authentication Logging Central Authentication Logging Central Authentication Logging Central Authentication Logging  
  Strengthen Passwords Strengthen Passwords Strengthen Passwords Strengthen Passwords Strengthen Passwords  
  PennKey Authentication Policies PennKey Authentication Policies PennKey Authentication Policies PennKey Authentication Policies PennKey Authentication Policies                          
34
Strong Authentication

• Questions?