20080805 - August 5, 2008 Meeting Notes

Challenge/response Considerations - Brian Early

Attendees:

• Joyce Landreth
• Cathy Winfrey
• Ken McCrery
• Susan Brooker-Gross
• Kevin Rooney
• Karen Herrington
• Rhonda Randel
• Brad Tilley
• Kim Homer
• Ismael Alaoui
• Marc DeBonis
• Mary Dunker
  

Agenda: Brian Early shares his experiences with challenge/response for CNS guest access to wireless network service.

Brian - It is a balancing act between system-generated Q vs. self-generated Q. Letting users specify questions is a bad idea. Normally they pick questions that are easy to guess. Can ask them to specify the question as well as the answer for mitigation, but in general, the average person uses easy questions. BOT attacks can feed in top 30 cities to respond to question asking where someone was born. Mother's maiden name is bad. Don't make self-generated the only way. Might specify one question of their own, and pick others from a list provided by the system. Brian found a goo list of sample questions. (see COLA: Create a guest account) For example, "What is your library card number?" "what is your Frequent Flyer number?"  Google on "secret questions" should produce results such as http://www.syngress.com/solutions/268_hack_Code/Using%20Secret%20Questions.htm . CNS did not encrypt answers so NOC could look at questions. Encryption/hash might be appropriate. Password reset screen doesn't give you your question. It pops up list of all questions and the person must choose the question again.

 CNS monitors attacks. COLA monitors failed login attempts based on IP address. Threshhold logs after 4 attempts. Sends e-mail after 10 failed attempts.

COLA requires 2 questions be answered.

Guest wireless has 2 password change mechanisms. Automated mechanism generates random PWD and sending in e-mail in addition to allowing questions to be answered.

Others might select photo. or Site key + phrase you make up.

Look at Treasury.direct and ing.com

Capitalization might be ignored. Exact match more secure. Could compress spaces. If period is at end, must match in COLA. Local liaisons can reset in Athletics.

for Hokies, OU admins can reset Marc will ask how they verify the person. (Marc - Will ask this at the WUG 8/7)

*Ask Carl for unauthenticated access pages for self-service PWD reset.

Q: If Brian had to do it over again, what would he change? Not enough feedback to change anything. 1-1/2 years. Might have changed that sponsor admins had to come to training.
Career services has guest accounts without questions. NOC has no way to verify info. Auto reset involves clicking link, sending to e-mail account, where person is sent a link to receive random password that they must later change.

Incentive to not change: When they call, the PWD is reset to temporary and in 48 hours, when they go to set it, they will need to create questions.

For Hokies, to force PWD change, they would have to make IRM & Help desk go through a web interface to reset PWD.  (Marc - Specifically, if we want to force people to build Q&A pairs we'll need to disable the default mechanisms to change/reset a password and build a web app to do this which forces the building.  If we still want to allow IRM & Help Desk to reset without having the user build them, then we don't have to change the SOP).

Joyce: using same questions for PID/PWD and Hokies PWD.  (Marc - I think we can use the same Q&A pairs IFF we determine that PID/PWD and Hokies ID/PWD are equivalent from a LOA standpoint.)

Might request VT ID# in addition to their challenge questions. 

Could you use PID to reset Hokies ID & vice versa? Currently you use PID to upgrade from contact to Account. Probably not. Can reset w/eToken cert.  (Marc - I'm on the fence of allowing PID -> reset - > Hokies, Hokies -> PID, etc)

IF PID cannot reset Hokies and vice versa, then the challenge questions should not be interchangeable.

Hokies should not be able to reset PID. Possibly, PID could reset Hokies. Could have separate question pairs for each.  (Marc - Can somebody elaborate on why they should not?  Because PID has access to more "important" information?  Because if we allow reset either way or bi-directional we suffer greater exposure if/when an account is compromised?)

If you rename a PID, you cannot keep same Hokies Id name.  (Marc - Specifically, if a PID is _recycled_ the UID will not match and we'll get a alert for manual intervention in our system since it would look like a rename attempt)

We should base our decisions on the deprovisioning we should be doing, not what we do. 

Decisions made:

1. At minimum, to reset password, user should have to enter VT ID# along with answers to challenge questions.
2. If a user authenticates with PDC on eToken and enters VT ID# that corresponds to that PDC, they will be allowed to reset PWD without answering challenge questions. This is because there is a higher LOA in the identity of the user of the PDC/eToken credential during authentication than in the PID or Hokies credential.

Questions prompted from meeting:

How many questions should be asked? Of those, how many should be self-generated and how many system-generated?

1. After selecting x number of questions, should the entire list be presented at PWD reset time, so the user must know which questions they elected to answer?
2.  Would/should NOC be able to see questions and/or answers in order to reset PID/Hokies PWD?
3. Should knowledge of PID/PWD allow a person to reset Hokies PWD without answering questions? (Mary thinks the general consensus was, "no.")
4. Should knowledge of Hokies ID/PWD allow a person to reset PID PWD without answering questions? (General consensus was, "no.")
5. Should there be one set of challenge questions/resposes that allows reset of both/either Hokies or PID password? Marc pointed out that if we do not allow #3 or #4, then it does not make sense that we should have a single set of questions that serve both PID and Hokies. This makes sense, but having 2 sets of questions is more cumbersome than one set.
6. Should questions/responses be encrypted when stored?
7. Should questions be drawn from existing Banner information?
8. Should we include an automated mechanism similar to CNS, where a random password is generated and sent to the user? (Mary thinks consensus on this was, "no."
9. Do we need/can we get unauthenticated network access to a page that allows the user to reset the password? (Ask Carl Harris.)