Penn Strong Authentication Project Update: Enhancing Security Measures

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