Proposal for SSN Removal from Account Activation/Password Renewal Process

1. Proposal for SSN Removal from Account Activation/Password Renewal Process Draft – 10/28/2008 14:00PM

2. Problem Summary • SSN must be removed as a basis for identity verification for: • Account Activation • Password Change • Password Recovery • SSN is currently the only near universal shared secret that can be used for identity verification.

3. Challenges • Remote identity verification by shared secret requires: • Secret that is accessible and usable by both individual and us • Secret that is known only to the individual and us • Private communications channel to share the secret • Most alternatives to SSN currently fail one or both of the first two requirements. • SSN almost always provides a reliable fallback of last resort. • Alternative solutions require a compromise between positive identification and convenience.

4. Proposed Solution Summary • Primary Verification • Secret Question/Answer ( SQA ) generates temporary password sent through private communications channel ( PCC ) consisting of external e-mail, cellmail, and/or cell SMS communications. • Secondary or Fallback Verification • PCC or SQA only • Helpdesk physical visit • Supervisor voice verification • Role based business/academic questions • Webcam visual identification (raise two fingers) • Voiceprint • Fax picture identity card • Postal mail • Non-positive identification

5. Secret Question/Answer ( SQA ) • The answers effectively form a password. • A password that violates most best practices for passwords: • Dictionary presence • Public, personal, or guessable information • Complexity rules • Password change and history rules • Answers may not be any more memorable than a password

6. Private Communications Channel (PCC) • To add assurance to the poor SQA password, additional identity verification is carried out using a private communication channel. • The PCC requires an additional, university independent user password and/or physical possession of an object. • The “Private” in PCC is relative.

7. Private Communications Channel (PCC) • External E-mail ( e.g. gmail, live ) • Cellmail • E-mail to cell#@network.org • Requires collection and storage of network information. Recently stopped. • Not sure if all networks provide this service but most do. • SMS • Blackboard Connect? • Campus SMS Gateway? • Outsourced SMS Gateway? • Voice? • Blackboard Connect? • Any cell option is well worth pursuing for benefits down the road in “two-factor” authentication and other uses. Inclusion in the solution at its outset is strongly recommended.

8. Operational Overview

9. Accounts.university.edu Home Page • Activate account for new users • Change password for existing users • Recover from forgotten password

10. Use Case – Activate Account – Primary Method • Student or employee receives email or postal mail upon acceptance with account name and URL: Accounts.university.edu/activate-step-1. • Person visits accounts.university.edu/activate-step-1 with browser. • Answers SQA ( filled in previously from student application or as yet unknown new employee/affiliate process ) • Temporary password sent via PCC on record from student application or as yet unknown new employee/affiliate process. Contains URL accounts.university.edu/activate-step-2 • Accounts.university.edu/activate-step-2 • Enters ID and temporary password • Chance to change SQA • Security Awareness • Change password • PCC information verification ( correction leads to SA or HR self service pages )

11. Use Case –Change Password – Primary Method • Accounts.university.edu/change • Login • Chance to review SQA questions and change • Security Awareness • Change password • PCC information verification ( correction leads to SA or HR self service pages )

12. Use Case –Recover Password – Primary Method • Accounts.university.edu/recover • Enter ID • SQA • Temporary password sent via PCC on record from student application or as yet unknown new employee/affiliate process. Contains URL accounts.university.edu/recover-step-2 • Accounts.university.edu/recover-step-2 • Enters ID and temporary password • Chance to change SQA • Security Awareness • Change password • PCC information verification ( correction leads to SA or HR self service )

13. Basic Tradeoffs – Primary Methods • More convenience • Require only one of SQA or PCC • Allow e-mail PCC • More positive identification and security • Require both SQA and PCC • Require cell PCC

14. Tradeoffs – Recommendations for Primary Methods • At roll-out: • On-campus request • Allow recovery with either SQA or PCC ( e-mail or cell ) individually for all parties • Off-campus request: • Allow recovery with e-mail or cell PCC by itself if student. • Allow recovery with cell PCC by itself if employee. • After stable: • On-campus request • Allow recovery with either SQA or PCC ( e-mail 0r cell ) individually if requested on-campus by all parties. • Off-campus request • Require both SQA and PCC. Cell PCC for employees. Cell or email PCC for students.

15. Operational Overview – Fallback Verification • Assumption: SQA and PCC unsuccessful/unavailable • PCC or SQA only • Helpdesk physical visit • Supervisor voice verification • Role based business/academic questions • Webcam visual identification (hold up two fingers) • Voiceprint • Fax picture identity card • Postal mail • Non-positive identification

16. Use Case – Activate Account – Fallback Methods • Postal mail to address of record with temporary password • Physical helpdesk visit for employees • Emergency vouch for identity and unregistered PCC on case by case basis • Physical visit or academic questions for students • Enrolled classes • Grades • Application information

17. Use Case – Recover Password – Fallback Methods • Physical helpdesk visit • Supervisor voice verification • Helpdesk call • Supervisor physical helpdesk visit • Role based business/academic questions • Helpdesk call • Forwarded to student/employee/affiliate business analyst • Classes, grades, HR info, ??? • Postal Mail to Address on record

18. Basic Tradeoffs – Fallback Methods • More convenience • Allow third party vouch • More security • Require positive identification by physical visit

19. Tradeoffs – Recommendations for Fallback Methods • Physical visit or supervisor vouch for employees or affiliates • Physical visit or academic questions for students • Enrolled classes • Grades • Residence hall • Last resort (No physical access to university. No university vouch unavailable). Consideration must be given to sensitivity of account. • Postal mail to address on record. • Trust in third party vouch ( e.g. distance learning physical ID check, validated remote higher ed personnel physical ID check ) • Webcam visual identification (raise two fingers) • Fax picture identity card

20. Physical Helpdesk Visit • Dedicated, locked down machine(s) • Helpdesk checks ID • Helpdesk logs into computer and enters user’s ID • User goes through standard account activation process: • SQA set • Security Awareness • Change password • Verify PCC information ( change leads to SA or HR self service pages )

21. Helpdesk Computers • Computer Security Controls • Screensaver timeout • Session timeout • Kiosk style configuration lockdown • No ability to backtrack through screens

22. Supervisor Vouch • Helpdesk receives call, claimed identity, supervisor name, unregistered PCC. • Helpdesk verifies supervisor and contact information. Confirms with supervisor over phone by helpdesk initiated call. • Helpdesk logs in and initiates password recovery for claimed identity and unregistered PCC or • Supervisor must physically visit helpdesk and do same • Portal sends temporary password through unregistered PCC.

23. Architecture and Implementation • New functions • New data • Policy vs programming • Futures • Migration • Costs

24. New Portal Functions • Ask/Verify/Set SQA • Verify email, cell phone, cell network. Redirect to SA or HR self service pages for change. • Generate temporary password • Generate email/cellmail/SMS according to user preference and policy • Receive temp password • SQA set • Security Awareness • Change password • Verify email/SMS. Redirect to SA or HR self service pages for change.

25. New LDAP Data • Cell number ( from peoplesoft ) • Cell network ( from peoplesoft ) • External e-mail address ( from peoplesoft ) • PCC User Preference ( email/cellmail/SMS ) • SQA ( from collegenet/portal activation ) • Temporary password and expiration date ( generated by portal ) • Random salt for default password ( generated by managed-accounts ) • Default Password - REDACTED ( generated by managed-accounts )

26. New Managed Accounts Functions • CollegeNet -> JCC ( SQA, email, cell, cell network ) • Random default password salt -> LDAP for new accounts • Default password -> LDAP for new accounts • SQA, email, cell -> LDAP for new accounts

27. Data Storage and Flow - SQA • User selects questions and provides answers • Collegenet application ( new students ) • Hire process ( new employees ) • Affiliate process ( new affiliates ) • Portal ( existing population ) • SQA for new students, employees, and affiliates loaded into LDAP • LDAP becomes SOA • All changes & administration done in portal

28. Data Storage and Flow - PCC • User provides e-mail, cell#, cell network • Collegenet application ( new students ) • Hire process ( new employees ) • Affiliate process ( new affiliates ) • Portal ( existing population ) • PCC data for new students, employees, and affiliates loaded into LDAP • Peoplesoft remains SOA • Portal uses LDAP for look-ups • Portal directs user to SA or HR self service pages for changes

29. Data Storage and Flow – Default PW • Managed accounts generates random salt for new accounts and stores in LDAP • Managed accounts generates default password unique to individual using reproducible algorithm making use of random salt. Sets as password for new accounts. • Accounts portal administrative console changes password of “disabled” accounts to default password.

30. Data Storage and Flow – Temp PW – PCC delivery • Generated by portal on the fly • Account activation • User Password recovery • Administrative recovery ( helpdesk, vouch, etc. ) • Random, fourteen character string made up of easily read characters ( e.g. no ‘o’s, ‘0’s, ‘1’s, or ‘l’s ) • Good for twenty-four hours • Hashed, then stored in LDAP along with expiration date/time • Sent via PCC • Password accepted by portal in recovery/activation process part 2 • Hashed and compared to LDAP value • Check expiration date

31. Data Storage and Flow – Temp PW – Postal Delivery • Generated by portal administrative interface • Random, fourteen character string made up of easily read characters ( e.g. no ‘o’s, ‘0’s, ‘1’s, or ‘l’s ) • Good for 10 days • Hashed, then stored in LDAP along with expiration date/time • Portal generates letter. Puts in queue. • Daily process prints generated letters. Need envelope stuffing and mailing process. • Send via Postal Mail • Password accepted by portal in recovery/activation process part 2 • Hashed and compared to LDAP value • Check expiration date

32. SQA Recommendations • Provide user with list of eight questions from which they must choose three to answer. • Opinion rather than truth questions to deter public information attacks and avoid storing personal information. • Remove case and white space from answers to ease repeatability and parsing. • Require a minimum length (3?) answer for each question • Add additional identity verification using the PCC for activation/recovery requests originating off-campus.

33. PCC Recommendations • In some situations, the private communication channel can be used as a fallback mechanism by itself if SQA answers are forgotten or not available. • LDAP stores PCC user preference but portal can limit user choice and choose method of transmission on the fly according to policy.

34. Policy Design • It is strongly recommended that the following policies be configurable, rather than hard coded, so they can be changed to meet changing environmental and business needs. • Enable/Require SQA, PCC, or both for what population. • Enable/Require email, cellmail, and/or SMS PCC for what population • Temporary password characteristics – length, expiration time • Number of secret questions required • Consideration should be given to storing configuration data in a directory, not in the application.

35. Miscellaneous Design Issues • Use of generic classes to allow for future expansion. For example: • ID-Verification (e.g. SQA, PKI-Certificate, RemotePictureID, OpenID, RemoteShibboleth, SecureID, LaptopFingerprint, VoiceID) • PCC (e.g. email, cellmail, SMS, WiFi, IM) • LDAP Directory (e.g. eDirectory, OID, ActiveDirectory, OVD) • Administrative functions should be moved off the home page to decrease clutter and end user confusion. ( e.g. accounts.university.edu/admin )

36. Administrative Functions • Helpdesk ‘user present’ password recovery. • Helpdesk ‘user not present’ password recovery ( sends temporary password to provided unregistered PCC ). • Helpdesk ‘disable account’ ( sets account password to default and disables LDAP account )

37. Administrative Functions • Account status query: • Active • Disabled • Waiting for activation phase 1 • Waiting for activation phase 2 ( SQA answered, temp password send to PCC ( list ) • Awaiting recovery phase 2. ( SQA answered, temp password sent to PCC ( list ) • Logging • SQA failed/answered from IP address • Phase 2 activation/recovery failed/succeeded from IP address • Change password failed/succeeded from IP address • PCC send failed

38. Migration • Current students, faculty, staff, affiliates, and graduates • Collect SQA and PCC information during normal password change cycle explaining the change online as well as through out of channel communications. • New Students • Implement CollegeNet application process already discussed. • New Employees • Need to come up with point in business process where identity can be verified and SQA/PCC information collected. ( I9 form fill out time?) • New Affiliates • Need to come up with point in business process where identity can be verified and SQA/PCC information collected. Vendor vouch?

39. Cost Summary • Extensive changes to accounts portal • Business process re-engineering for account activation prerequisites in student acceptance and employee hiring. • Convenience and complexity impact on end user • Increased frequency of fallback scenarios. • Increased support complexity and sensitive user interaction required in fallback scenarios. • Increased outright failures of identity verification process in certain remote situations requiring acceptance of risk associated with poor verification or significant end user impact on accessibility. • New LDAP attributes • Changes to ID generation script • Requires registration of external email and/or cell phone information for off-campus account activation and password recovery • Requires SMS gateway if that option chosen over or in addition to cell@network email.