Also see:

Introduction

This page is for the analysis of requirements for the Self-Service Password Reset Service.  Please check the attached Software Requirements Specification (SRS) for the latest version of the agreed upon requirements for this service.

Below you'll find discussion questions listed, as well as further details of the analysis, but the latest posted SRS is the current specification, and will be used for formulating a complete project scope.

Discussion Questions

  1. What methods of authentication will be available in the first phase of the service, and what are the reasons behind those choices?  We should discuss as soon as possible, create a future enhancement list based on availability at the end of the planning phase, and remove those that are not appropriate, have a minimum level of security/assurance, or don't end up as a positive ratio of work vs. benefit.

    Current Proposed Choices include:

    1. Secret Questions(out)
      • maybe - recommended to remove - benefits do not justify the amount of work to implement
    2. OTP2SMS(in)(in combination)
      • OK as long as it is not the only method
    3. VT ID(in)(in combination)
      • required - in combination with another method
    4. Knowledge-based Information (in)(in combination)
      • Requirement - no questions asked during PIDGen for any affiliation
      • Requirement - data used must not be easily discovered
    5. Soft Personal Digital Certificates(out)(see future enhancements)
      • excellent future enhancement; not possible by November 1, 2010
    6. Secret Code (Registrar's Orientation Code)(out)
      • only for undergraduate students? (needs more research)
    7. E-Tokens(in)(set as a lower implementation priority)
      • excellent option - easy to implement, but very low impact due to low availability and usage
    8. Trustee verification (web of trust)(out)
      • i.e., ability to list people that can reset a password for someone else
      • future enhancement - tabled for future discussion
    9. Call-in reset(in)(as a user preference, or an administrative denial)
      • this would be a user preference - as an opt-out
    10. Email ticket (in)(in combination)
    11. Remote Authentication via OpenID or other remote IdP (in)(in combination)
    12. OTP2VOICE(out)
      • future enhancement - may be expensive - needs more research
    13. In person reset(in)(mentioned as the default but not included in the implementation)
      • yes - always an option - do not eliminate as an option
  2. Will there be an administrative control function for imposing requirements on authentication methods chosen by user?yes
  3. Will there be an administrative function for setting a user's preferences for them?yes
  4. Should the user be allowed to set password reset preferences, such as what authentication methods they will use?yes
  5. What state should an account be in that would allow a ssr?ACT
  6. What state should the account be in after the reset?ACT
  7. Will the user be allowed (during pidgen preference setting) to delay setting preferences? No, not without setting some minimum set of preferences. Make this look atomic without actually being atomic.
  8. How will deprovisioning of authentication methods be handled? Should be handled out-of-band
  9. Does the red flag requirement need to be more clearly defined? Leave as is and let each service (component) decide what is appropriate
  10. Which remote ID services will be enabled? Facebook(Y), Google(Y), Yahoo(Y), AOL(N), LiveID(Y), MyOpenID(N), Twitter(N)

Needs

  1. PIDgen needs to be modified to gather user information
  2. Maintenance of user information is needed
  3. Maintenance of user preferences
  4. Preferences would be set in PIDGen phase
  5. Need administrative control over all user settings and preferences
  6. Separate services for:
    1. Authentication
    2. Application (i.e., password reset)
  7. At least 2 methods of authentication required.
  8. 4Help's current method of locking an account is to reset the password. This self-service tool would circumvent that process. Therefore, 4Help will need another method of locking an account or the ability to truly lock an account like IMS uses.
  9. Procedure for in-person password reset.
  10. Procedure for accepting faxed, notarized documents for authentication for long distance password reset.

Agreed Upon Authentication Methods

  1. OTP2SMS
  2. VT ID & PID
  3. E-token authentication front door
  4. Call-in reset as a user preference
  5. In-person reset
  6. Knowledge-based questions
  7. Email ticket to 3rd party email address
  8. Remote auth via openId (what are identity proofing requirements?)

Possible Future Enhancement Authentication Methods

  1. Soft PDCs

General Requirements (for PID password reset)

For the most up-to-date requirements please refer to the Software Requirements Specification document. The original requirements and discussion of such below have been superseded by this document.

Note: Greg spoke with Jeb on 9/22/2010 to be sure stakeholders understood that the initial phase of this project is for PID passwords and once complete, later phases will address Banner/Oracle and finally Hokies passwords. Jeb responded that it was understood and he has conveyed that message to Internal Audit. The decision to create one or three requirements documents is up to the project team.

  1. The webUI should provide a usable interface.
    1. ...with a similar look and feel.
  2. All application components should incorporate security measures to defend against known application vulnerabilities, such as those defined by the OWASP Top Ten Project.
  3. Authentication methods used during initial PID credentialing will not be used during self-service password reset.
    1. Needs specificity. Authentication  methods that do not stand up to the test of time...
  4. All components will audit their events by log and logging should adhere to current guidelines.
  5. All components should incorporate appropriate red flag warnings if there appears to be a malicious attack on the system.
    1. Could be more specific once use cases are analyzed. Review during development
  6. An in-person reset will always be available, and while this is a requirement for this application it is out of scope for this project.
  7. All accounts must be in an active state in order to use this service.
  8. Passwords must be in either an active state or an expired state (due to a forced expiration) in order to use this service.
    1. References are to the (future) password change project (forced expiration)
  9. Users must explicitly opt-out of call-in resets if they do not wish to have their password reset by 4Help.
  10. Users must set minimal reset preferences (opt-in or out for call-in resets) during PIDGen.
    1. User must choose call in or not for password reset
  11. Users must acknowledge a warning in the webapp if no options are selected.
  12. Users will be notified after a successful PID/password authentication event if they haven't either changed their reset preferences or reported no changes to reset preferences for 1 year.
    1. After a successful PID/password authentication event in CAS the user will be notified if a user has not set or managed their reset preferences for more than 1 year
    2. after a successful PID/password authentication event = CAS
    3. CAS users will be encouraged (nagged) to manage their preferences if they have not done so for more than 1 year
    4. For Hokies acct's the only place this can be controlled is in a web application, or do a web service call.
    5. Stay away from sending an e-mail notice as it may be viewed as a phish
  13. If a user has opted out of call-in resets, the DAT will only allow IMS to reset the password.
    1. Joyce requested that their be a note in DAT that specifies the user has opted-out
  14. Every effort will be expended to acquire a 3rdparty email address from all users in order to provide effective notification of when the password was reset. {-}This may be done through remote authentication attribute request, and/or{-} This will be done through explicit solicitation of a notification email during preference setting.
    1. What about validating the 3rd party e-mail address?
    2. Perhaps request the e-mail address twice.
  15. Every effort will be expended to prevent unwanted text messages to be sent. For each HTTPS Session, the system will disable the send button for 5 seconds before allowing the user to send another message. The system will not send more than 3 messages to a particular receiver in a ten minute period.
    1. May be tweaked for usability
  16. All password resets will require VTID and PID in addition to OTP2SMS or Remote Authentication.
    1. Marc says this will work for Hokies accts also. If a Hokies acct does not have a PID associated with it it cannot use this service.
    2. Implies that sponsored PIDs will not be able to use this service because they do not have a VTID
  17. Only one mobile number will be in use at a time for this phase.
  18. O-Auth identity providers must comply with version 2.0 or greater of the O-Auth protocol.
  19. OpenID identity providers must comply with version 2.0 or greater of the OpenID protocol.
  20. System will allow for only one remote auth provider at a time to be set as the current provider in their reset preferences.
  21. Users may not use a VT domain account that resides on the Google Application Service for either email or remote authentication settings.
    1. Users may not use a *vt.edu account for either email used for notification or remote authentication settings.

Functional Requirements

For the most up-to-date requirements please refer to the Software Requirements Specification document. The original requirements and discussion of such below have been superseded by this document.

  1. Users will be able to set user preferences for how their password will be reset based-upon available authentication methods on a per user basis during the PIDGen process immediately following the password setting event.
  2. Users will be able to set user preferences for how their password will be reset based-upon available authentication methods on a per user basis at any time after the PIDGen process by accessing a web application protected by PID/password.
    1. specify use of MyVT. Strongly recommend ease of access in MyVT
  3. Users will be provided the opportunity to enter 3rd party e-mail addresses for notification at the end of the preference setting workflow.
  4. Users will be able to authenticate to the reset event via a one-time password sent via SMS.
  5. Users will be able to authenticate to the reset event via a remote authentication process.
  6. Users will be able to authenticate to the reset event via a VT eToken.
  7. Users will be notified of password resets  via 3rdparty email.
  8. IMS will be able to administratively set availability of authentication methods for certain groups or affiliations.
  9. IMS will be able to set a user's set of reset preferences as an administrative function(DAT).
  10. Users will be notified when they either have an account that has no preferences set, or the preferences have not been maintained within a certain time period
    1. FR10. change second part to say... or preferences require maintenance.
  11. Users will be allowed to report no changes to reset preferences in order to satisfy preference maintenance requirements.
    1. FR11. Users will be allowed to report "no changes" to reset preferences in order to satisfy preference maintenance requirements (Note to Kevin, this should be a GR)
  12. During any password change, a user who has no preferences will be forced to set preferences as part of the password change. This does not apply to SSPR.