Strong Authentication Project Update for NPTF 4/21/2008.
-
Upload
phebe-rosalyn-long -
Category
Documents
-
view
216 -
download
0
Transcript of 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
Strong Authentication
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
Strong Authentication
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.
Strong Authentication
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
Strong Authentication
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
Strong Authentication
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
Strong Authentication
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
Strong Authentication
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
Strong Authentication
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
Strong Authentication
• 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
Strong Authentication
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.
Strong Authentication
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
Strong Authentication
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
Strong Authentication
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
Strong Authentication
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 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
Strong Authentication
Options and Recommendations Strengthen PennKey Passwords
• 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
Strong Authentication
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
Strong Authentication
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
Strong Authentication
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
Strong Authentication
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
Strong Authentication
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:– 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
Strong Authentication
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
Strong Authentication
Options and Recommendations Supplement Re-usable Passwords: Two Factor Architecture Options
• 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
Strong Authentication
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
Strong Authentication
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
Strong Authentication
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
Strong Authentication
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
Strong Authentication
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
Strong Authentication
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
Strong Authentication
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
Strong Authentication
Design and DevelopmentEnable Multiple Levels of Assurance
Strong Authentication
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?
Strong Authentication
Strong Authentication