Main Nav

We're updating our Self Service Password reset system.   Currently students, faculty and staff have to initialize it by answering a series of questions.  Then when they forget their password, they simply enter their ID #, answer the questions (Mother's Maiden Name, First Pet Name, etc.) ... and they get their password reset.  Unfortunately, few choose to initialize it, so they can't use it when they need to.
 
We want to move to a process where we use their ID Number, plus have them verify with information already in our system.   Is anyone else doing this, and what "identifiers" are you using that you consider unique enough that others won't know.  We're considering DOB, last 4 of SSN, etc.   Some feel that last 4 of SSN (used in this way) is a violation of FERPA.  Others (like me) do not believe it is because it's not being disclosed to anyone (just used by the owner to verify identification).

Thoughts!  What's everyone else doing in this area.
 
 
 
 
Carmen A. Rahm
Asst. VP for Info. Technology
Central Washington University
400 East University Way
Ellensburg, WA  98926
Direct Phone:          (509) 963-2925
Mobile Phone:         (360) 271-2992
ITS Office Phone:   (509) 963-2333
ITS Homepage:       www.cwu.edu/~its
GO GREEN! This email uses 100% recycled electrons.
No electrons were harmed while composing this message.
********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Comments

Carmen,

Here is a link to 34 CFR Part 99 (http://www2.ed.gov/policy/gen/guid/fpco/pdf/2012-final-regs.pdf).   I’ve read it.  Would your plan be a violation?  I can’t say for sure, but my take was that they prefer what you are doing now (Challenge/Response questions) to using DOB, SSN or a portion of SSN, or student ID numbers.  In other words, the questions provide an opportunity for the user to insure that only he or she knows the answer.   Your mother’s maiden name is not recorded in any documentation on campus.  And even so, there’s no rule that says you have to actually put down your mother’s maiden name as long as you can remember what you answered.  As with color or a pet’s name, the only one who knows the answer is the individual who answered it.

We used DOB and Student ID before the proposed rule emerged in March 2008. Once I read it, I decided it wasn’t worth effort or risk.   We built our own password reset system based on questions and answers.  Our account requests are electronic and we require that the questions be answered prior to the account being generated.  If a previously existing user can’t change his or her password because of failure to answer the questions, they are usually out of luck until they come to IT Support with an ID.  That almost never happens at this point. . .

In any event, you may wish to check with your institutional counsel.   Good luck!

Bill Schleifer

Bill Schleifer

Chief Information Officer

Rivier College

Nashua, NH 03060

603.897.8630



IT Support will never ask for your password.   Never email your password to anyone!

Carmen, I’m not a FERPA expert, but I would steer clear of SSN.  It is a high profile identifier that seems to be a natural target for various laws at the state and federal level.  For example, in New Hampshire,

“Under no circumstances shall the department of education obtain or use a social security number as an identifier for any pupil.”  (http://www.gencourt.state.nh.us/rsa/html/XV/193-E/193-E-5.htm)

It is also a common trigger for security breach notification laws (http://www.ncsl.org/issues-research/telecom/security-breach-notification-laws.aspx).

You might argue that your use of the last four digits is not covered by such laws and regulations, but why add the risk? 

 

Tom Franke

University System of New Hampshire

 

Message from dthibeau@post03.curry.edu

Carmen,

I tend to agree that there are ought to be no issues with the last four digits of the SSN in that it’s only being displayed for the student, however, if local laws prevent you from asking for it or using it, well then clearly it won’t be an option.

We use a web portal for single sign on to all our applications.  The first time a user logs in they are required (not an option) to respond to five challenge questions.  These can be used (three selected at random) to obtain a forgotten password.  We also have their non-college issued e-mail address from their application, and if they ask, we will forward their password to that address but we have not automated a reply to that address – not a bad idea though!

We have a fairly small student body (less than 4,000) and used to have several hundred password reset issues each year.  Since we went to single sign on that number has dropped to under 50 per year and most of those are new students who have never logged in, and simply lost their credentials.

Good luck with whatever you decide.

Dennis Thibeault

CIO, Curry College

 

Message from dabantz@alaska.edu

For those using similar techniques, [how] have you addressed security concerns or risks associated with (1) maintaining unencrypted passwords and (2) sending them by email?

David Bantz



On Mon, 7 May 2012, at 15:50 , Thibeault, Dennis wrote:

We also have their non-college issued e-mail address from their application, and if they ask, we will forward their password to that address

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Related to Dave's questions.

1.We send a link to the alternate email address that when they click the link it forces them to set the new password. The actual password is never sent.

2. We send a text message to their cell phone when the request comes in saying a password change was requested and sent to the alternate address.

3. In looking at the request we base the request on risk. 

a. If it is coming from on-campus and the device has successfully logged in previously (because it has our portal cookie on it) we allow this without additional security questions.

b. If the device is coming from off-campus but has our cookie on it we will validate one security question and send the link to the alternate email address.

c. If the device doesn't have our cookie on it we require up to 3 security questions be answered. Some were user self-selected but others are derived from our SIS data. We really expect that people have used the device to log in before and should have the cookie present.

d. Finally, you can't do a password reset from an IP out of the country unless it is from a device with out cookie indicating you successfully logged on it before.

jack




Message from dabantz@alaska.edu

Plus, the last 4 of SSN are a "sequence number" - essentially random - while the other digits are based the year and place the number was requested, so more susceptible to guessing.


On Mon, 7 May 2012, at 17:13 , Harris, DP (LLU) wrote:

********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.

Message from dabantz@alaska.edu

Thanks Jack.

Your process avoids both the risks I alluded to: passwords are not sent in email, hence there's no need to store unencrypted passwords anywhere.

David Bantz

On Mon, 7 May 2012, at 17:13 , Jack Suess wrote:

Related to Dave's questions.

1.We send a link to the alternate email address that when they click the link it forces them to set the new password. The actual password is never sent.

2. We send a text message to their cell phone when the request comes in saying a password change was requested and sent to the alternate address.

3. In looking at the request we base the request on risk. 

a. If it is coming from on-campus and the device has successfully logged in previously (because it has our portal cookie on it) we allow this without additional security questions.

b. If the device is coming from off-campus but has our cookie on it we will validate one security question and send the link to the alternate email address.

c. If the device doesn't have our cookie on it we require up to 3 security questions be answered. Some were user self-selected but others are derived from our SIS data. We really expect that people have used the device to log in before and should have the cookie present.

d. Finally, you can't do a password reset from an IP out of the country unless it is from a device with out cookie indicating you successfully logged on it before.

jack




Message from brivers@uga.edu

If done wrong, the use of any portion of the SSN can lead to risk of enumeration attacks.  We’ve even seen vulnerabilities to this on commercial IDM systems.  In the worst case, because the system has access to PII, a security breach on it could lead to data exposure of the SSN itself.  Avoid using it.    As Jack said, when you establish an authentication pair, create Secret Questions.  It is best to let the user pick these questions if your system can support it.  They are easier for them to remember and it verifies your service to them.

 

Brian Rivers

Information Security Officer

University of Georgia

 

Thanks for all the feedback. We have the capability of "forcing" everyone to answer the challenge questions, and plan to do so in lieu of using the SSN digits. Our process will be very similar to what you described. Again, thanks for the feedback from everyone. Carmen A. Rahm Asst. VP for Information Technology Central Washington University 400 East University Way Ellensburg, WA 98926 Direct Phone: (509) 963-2925 Mobile Phone: (360) 271-2992 ITS Office Phone: (509) 963-2333 ITS Office Fax: (509) 963-1385 ITS HelpDesk: (360) 271-2992 ITS Homepage: www.cwu.edu/~its Go Green: Emails use 100% recycled electrons! >>> "Thibeault, Dennis" 05/07/12 16:51 PM >>> Carmen, I tend to agree that there are ought to be no issues with the last four digits of the SSN in that it's only being displayed for the student, however, if local laws prevent you from asking for it or using it, well then clearly it won't be an option. We use a web portal for single sign on to all our applications. The first time a user logs in they are required (not an option) to respond to five challenge questions. These can be used (three selected at random) to obtain a forgotten password. We also have their non-college issued e-mail address from their application, and if they ask, we will forward their password to that address but we have not automated a reply to that address - not a bad idea though! We have a fairly small student body (less than 4,000) and used to have several hundred password reset issues each year. Since we went to single sign on that number has dropped to under 50 per year and most of those are new students who have never logged in, and simply lost their credentials. Good luck with whatever you decide. Dennis Thibeault CIO, Curry College
Message from shelf@westernu.edu

Jack is right on in his approach, and I’d like to add re. key security principles (again, I refer folks to the Web Application Hacker’s Handbook, and a new edition is out, http://goo.gl/sUIKk, —think like the “enemy” to defeat him):

 

1.       If you do send a password reset “hot” link, make sure it expires in a pre-set time;

2.       Use an out of channel, e.g., cell phone, alternate e-mail, etc., method to inform the account holder and to verify key changes;

 

3.       Perhaps most importantly and often missed in technical solutions: ALWAYS notify the account holder of the password or any key change. People (hackers) are and will ever be, more clever than our machines or verification schemes. We can partly manage this, in addition to our technical means, by automatically informing users when key changes occur, and induce their index of suspicion and action to notify us if something seems amiss.

 

Great discussion, all!

 

Sincerely,

 

Scott Helf, DO, MSIT

Chief Technology Officer-COMP

Director, Academic Informatics

Assistant Professor

 

Department of Academic Informatics

Office of Academic Affairs

College of Osteopathic Medicine of the Pacific

Western University of Health Sciences

309 East 2nd Street

Pomona, CA  91766

 

909-781-4353

shelf@westernu.edu

 

www.westernu.edu

 

 

 

 

From: The EDUCAUSE CIO Constituent Group Listserv [mailto:CIO@LISTSERV.EDUCAUSE.EDU] On Behalf Of David Bantz
Sent: Monday, May 07, 2012 6:29 PM
To: CIO@LISTSERV.EDUCAUSE.EDU
Subject: Re: [CIO] Use of SSN (last 4) as Identify Verification

 

Thanks Jack.

 

Your process avoids both the risks I alluded to: passwords are not sent in email, hence there's no need to store unencrypted passwords anywhere.

 

David Bantz

 

On Mon, 7 May 2012, at 17:13 , Jack Suess wrote:



Related to Dave's questions.

 

1.We send a link to the alternate email address that when they click the link it forces them to set the new password. The actual password is never sent.

 

2. We send a text message to their cell phone when the request comes in saying a password change was requested and sent to the alternate address.

 

3. In looking at the request we base the request on risk. 

 

a. If it is coming from on-campus and the device has successfully logged in previously (because it has our portal cookie on it) we allow this without additional security questions.

 

b. If the device is coming from off-campus but has our cookie on it we will validate one security question and send the link to the alternate email address.

 

c. If the device doesn't have our cookie on it we require up to 3 security questions be answered. Some were user self-selected but others are derived from our SIS data. We really expect that people have used the device to log in before and should have the cookie present.

 

d. Finally, you can't do a password reset from an IP out of the country unless it is from a device with out cookie indicating you successfully logged on it before.

 

jack

 

 

 

Is this a custom built  or third-party application that you use to do this?  Sounds neat!

 

Chad

 

Sent from my mobile device

 

From: The EDUCAUSE CIO Constituent Group Listserv [mailto:CIO@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jack Suess
Sent: Monday, May 07, 2012 8:13 PM
To: CIO@LISTSERV.EDUCAUSE.EDU
Subject: Re: [CIO] Use of SSN (last 4) as Identify Verification

 

Related to Dave's questions.

 

1.We send a link to the alternate email address that when they click the link it forces them to set the new password. The actual password is never sent.

 

2. We send a text message to their cell phone when the request comes in saying a password change was requested and sent to the alternate address.

 

3. In looking at the request we base the request on risk. 

 

a. If it is coming from on-campus and the device has successfully logged in previously (because it has our portal cookie on it) we allow this without additional security questions.

 

b. If the device is coming from off-campus but has our cookie on it we will validate one security question and send the link to the alternate email address.

 

c. If the device doesn't have our cookie on it we require up to 3 security questions be answered. Some were user self-selected but others are derived from our SIS data. We really expect that people have used the device to log in before and should have the cookie present.

 

d. Finally, you can't do a password reset from an IP out of the country unless it is from a device with out cookie indicating you successfully logged on it before.

 

jack

 

 

 

Close
Close


Annual Conference
September 29–October 2
Register Now!

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.