1 / 34

Strong Authentication

Strong Authentication. Project Update for NPTF 4/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

rbranch
Download Presentation

Strong Authentication

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

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

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

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

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

  13. Options and Recommendations Strengthen PennKey Passwords • Options: • Increase the complexity of passwords, but allow them to remain shorter. • Transition from a passwordmodel 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

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

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

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

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

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

  19. Options and Recommendations Supplement Re-usable Passwords • 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

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

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

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

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

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

  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 Branan’s Streamlining PennKey initiative Strong Authentication

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

  27. Organization ISC Information Security

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

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

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

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

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

  33. Design and DevelopmentPreliminary High Level Timeline Strong Authentication

  34. Strong Authentication • Questions? Strong Authentication

More Related