1. What can be implemented to protect unwanted SMS messages from being sent?
2. What should we say to the user concerning the use/exposure of their cell number?
3. Should we be concerned about the sms message being intercepted if we only accept the message if it is given through the current web session it was sent from?
4. Is this a sufficient secret key:
    SecureRandom random = new SecureRandom();
           String skey = new BigInteger(35, random).toString(32);  (this results in 7 alphanumeric characters like '7a0ltar' - noting that alpha characters are lowercased.)
5. How long should the sms key be good for (e.g. 5 minutes?)?
6. Is VT ID and otp2sms sufficient for authentication?
7. Should the user be allowed to setup more than 1 remote id provider?
8. Is VT ID and a single successful remote auth event sufficient for authentication?
9. Do we need something else like captcha to slow the app down to mitigate scripting?

Attendees

Kevin Rooney, Randy Marchany, Mary Dunker, Michael Hosig, Daniel Fisher, Karen Herrington, Greg Kroll, Ismael Alaoui, Philip Kobezak, Susan Brooker-Gross, Doug Atwater

Meeting Notes

• Kevin gave an overview of the project
  • Focus for this group is authentication to the application
  • Opt in/out for preferences. Reversible via MyVT.
  • Notification scheme for notifying user that something was done with their account.
  • May use OTP like VASCO. May use OpenID. Keys are passed in secure sessions.
• Question #1. Randy commented that the window of opportunity for a hacker is very small so securing the appl is all that may be required. Other use cases are malicious spamming, and owned account.
• Demo
  • Demo uses e-mail to send SMS message, actual application will use SMS gateway.
  • Mary: since we are planning to allow use of eTokens we should include that as a default preference to opt out of.
  • There is no way to know that a user has an eToken (unless used to login to appl.) automatically, that web service does not exist today. Ismael commented that something could be written to do this but there are currently no plans to do so.
  • If certs are allowed for general authentication perhaps they should not be allowed to reset your password???
  • If we are trusting OpenID providers to reset a password why are we not allowing someone’s Hokies password to reset their PID password?
    • ITSO (Randy) said we should allow a user to reset PID password using their Hokies credentials, i.e., resetting an LOA 2 with an LOA 2. Same risk as allowing a sys admin resetting user’s passwords.
    • For phase 2 or 3 should we should include a checkbox to opt-out of having an OU admin to reset a password
  • Reason for even allowing preferences is a comment from IA to allow users to opt-out of a call-in password reset by 4Help.
    • If user opts-out of call-in password reset we need to be very clear that it means they MUST show up in person for a password reset.
    • Need administrative override by IMS for preferences. Need strict policies & procedures for this.
    • Discussion about the possibility of presenting the user a list of preferences specific to their role and information we have on them at reset time not collecting it beforehand.
    • Perhaps present user with a list of options available for them but do not present the actual values, e.g., say “use your cell phone number” but do not show them the cell phone number.
    • This would mean the reset application would no longer use preferences but would rather present the user with options that are available to them based on information we have collected from them. This also means that a user would not be able to opt-out of any methods to reset their password (except perhaps not allowing resets by calling 4Help) rather they would be presented with all options (dynamically) at reset time.
    • We are going to split this into (1) limited preference setting (opt-out call in to 4Help), and (2) presenting user will all their available options from data collected.
  • OpenID
    • Provider only passes back the users OpenID identifier in a URL. No other attributes.
    • Kevin explained technical details on how the different providers implement and use OpenID. Yahoo is different from Google.
• ITSO likes the concept and is OK with the proposed implementation.
• Questions
  1. -
     • According to Randy and an e-mail from the FCC the moratorium on cell phone numbers being protected from telemarketers is expiring soon and cell phone numbers will be released.
     • Force the user to enter VT ID number + PID
     • Those present were in favor of tying the ticket sent back to the user to a particular web session, usual web session timeout is 15-30 minutes. More important is the SMS message timeout, which is relatively short.
     • Kevin will come up with a number of times a user could send a request for reset using SMS and send to this group, e.g., 3 times in 10 minutes.
  2. –
     • Need to talk to legal
     • Perhaps give the ability to “label” phone numbers when multiple numbers are supplied by the user, e.g., home, Greg’s cell
     • In the case where a user changes their cell phone using something like Hokie SPA they would have to go back and verify that cell phone can use SMS messages, we cannot assume it works and just accept the change from Hokie SPA.
     • Need to keep this number separate from everything else and not sent to any other system, e.g., Banner
     • Need to provide a way to expose and change this number, e.g., MyVT
     • Since there is no phone number manager program user will have to live with having to enter the same number in multiple places
  3. –
     • SMS messages can be sniffed even if it is difficult
     • ITSO says we should require that OTP only be sent to same web session it was sent from.
     • ITSO = Yes
  4. –
     • Why not just numeric to make it easier on user? To avoid problems with O’s and zero’s, L’s and one’s, etc. Perhaps 7 alphanumeric characters is overkill.
     • Using alphanumeric gives greater entropy
     • A usability question
  5. –
  6. –
     • Yes
  7. –
     • May be a security concern to display too much information on the reset screen (assuming we are presenting all options we collected data for).
     • Kevin does not like the idea of using more than one cell phone number.
     • Future enhance a multi-value
  8. –
     • E.g., OpenID
     • Add requiring PID also
     • Yes
  9. –
     • Could use server side validation if many request come quickly
     • Is using captcha worth the hit in usability? General opinion is probably not.
• No showstoppers
• Group is OK with auth methods discussed