How do you distribute credentials, as well as identify and authorize a system user, relatively securely, especially in a remote situation? Secondly, how do you handle remote resetting of lost passwords or usernames?

Tom gave a demonstration of how they initialize accounts at the University of Memphis to new students and faculty using two-stage authentication. They wanted a non face-to-face method to distribute credentials and do password resets in a relatively secure manner. It's not desirable to rely on easily found information such as date of birth, social security number and mother's maiden name. At U. Memphis they chose to distribute a randomly generated account initialization code via the U.S. mail as the first stage. It's long, and random, 1951 K21V 674I V106 0L03 is an example, to make it difficult to memorize or guess yet still easy to type in. With this code the user visits the web site http://iam.memphis.edu and completes the second stage of activation by entering the code along with their name and date of birth. Once matched the user can claim the account username, select a password, and setup three security questions along with their e-mail. U. Memphis also has a system where you swipe your id card to activate an account but are moving away from that method since you can't really tell who is swiping the card.

The three security questions will be used for re-authentication of the account, and all three must be answered correctly for success. The questions are stored as attribute values bound to a username. Two questions are selected from a drop down menu and the user enters the third. Questions such as "What is your favorite color" don't work because people later often can't remember what they picked. While the two drop down questions were selected after user studies for likelihood of being remembered, such as "what was your first pet's name," there is always the difficulty of trying to pick questions that the user will remember the answer to but no one else knows. For the user-entered question, a thing such as the password being part of the question is blocked. There is debate over whether a user-entered question is a good idea or bad one but there is no universal consensus. If the user fails to re-authenticate they must either be snail mailed a new code or re-authenticate in person. The help desk cannot set or retrieve the password to prevent misuse by any support personnel.

At Chicago they let them pick their own question and answer. The answer has to have a minimum length of eight characters. All capitalization, punctuation and spaces are removed in order to try to generate a match without it being too fuzzy. Users also can't have the answer as part of the question. They've been using it for a couple of years with few problems. It is one option among several offered for re-authentication.

In general 100% authentication of identity is not possible or necessary; the goal is reasonable assurance of ID. There is no one size fits all solution; it needs to be adapted to the situation. The level of assurance needed for a hospital login may be higher than that needed for a university e-mail account. That level needs to be balanced against what's reasonable for the environment in question. The ID information being assessed comes from human resources, registrars or provost office and there has to be some level of trust that they have verified the information.

Some universities require an individual to show up in person during business hours to activate an account. In some places a return trip is required. This can be difficult for weekend, evening, and remote students. In some cases, if a credit card is used to pay for a class then activation information will be mailed to the billing address. Other options mentioned were mailing a computer-generated password, certified mail, splitting the key into two parts and distributing it via e-mail and snail mail.

At the University of Chicago e-mail account information is mailed to a new student at a pre-existing e-mail address to save the expense of snail mailing it. However, the student must first get a student ID card and that student number is used to get the e-mail account information. In that instance they get no other services than e-mail. At other universities more services may be granted initially. This emphasizes the difference between authentication and authorization.

Is it possible for a service to see a time stamp so it's knows the last time it was re-initialized and if there are multiple re-authorizations/attempts in a short time so a warning flag could be set? Not really. One item of note, e-mail to user for re-authentication should have a date in the header. If it doesn't it may float to the top of the user's e-mail after an elapsed period of time and the user may panic that they're being hacked because they think the reset e-mail is new and there is no date to show otherwise.

There was brief discussion of how to reset passwords and help desks. Some institutions let the help desk set a flag that allows the user go back and walk through the setup process again, others require a snail mail or physical presence to distribute the reset password, some allow a direct reset. In the case of malicious attempts to reset passwords from outside there is an audit trail, with data being distributed across different databases to thwart retrieving all information associated with an account.

The key questions to consider in how to distribute credentials:
What's reasonable?
What hurdles exist to users in the process?
What's initially accessible (what services does it provide access to)?
How much access should the helpdesk have?
How will re-authentication be handled and how many gating points?
Trusting frontline offices to do their work?