Re: Self-service password reset approaches

["Burton, Abigail F" <afburton () BCM EDU>]

Phishing has tell-tale signs. Massive amounts of outbound emails from the compromised email address. Sent folder has 
hundreds of sent emails not generated by the actual user. User will receive NDR spam and that is enough of an annoyance 
to let the user know something is wrong. I am not sure what you may have within your institution to possibly alert 
questionable events but we do receive reports.

Holding a user accountable for responding to a Phishing site is another matter...

Thanks!
abby

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Kevin 
Shalla
Sent: Tuesday, February 14, 2012 2:36 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] Self-service password reset approaches

If the villain has not changed the password, then how do we know the account has been compromised?  If the account 
owner thinks the account has been compromised, but the old password still works, then we suggest that he change the 
password (with the usual change password facility), and then we try to figure out who the villain is and what he did.

On 2/14/2012 2:18 PM, Roger A Safian wrote:
I was trying to figure out what happens when an account is compromised and the villain has NOT changed the password.  
(phishing)  How do you know who is the account owner of more than one person knows the password?  It sounds like the 
answer is you make come in.

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Kevin 
Shalla
Sent: Tuesday, February 14, 2012 1:58 PM
To: SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV EDUCAUSE EDU>
Subject: Re: [SECURITY] Self-service password reset approaches

I'm not sure what the real question is here.  If the account is compromised and the villain changed the password so the 
account owner cannot log in, then we may lock the account if we think it's really been compromised, but require the 
owner to come in to get a new password (or if the owner had already set up a backup e-mail, then the person can reset 
the password by using a link sent to that backup e-mail account).

On 2/14/2012 8:58 AM, Roger A Safian wrote:
What happens when an account is compromised?

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Kevin 
Shalla
Sent: Tuesday, February 14, 2012 8:57 AM
To: SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV EDUCAUSE EDU>
Subject: Re: [SECURITY] Self-service password reset approaches

We're not using Telesign, but it reminds me of a system we use here for authentication during telephone calls.  When 
someone calls us and we need proof that the person is who he says he is (like wants to talk about confidential 
matters), we ask him to go to a certain Web page, login there, then read the one-time-use generated token.  The 
telephone operator then enters this on a different Web page, and it indicates which netID generated that token.  It's 
much more secure than asking a bunch of questions, and hoping that only the correct person can answer those questions 
correctly.

On 2/14/2012 8:41 AM, Theresa Rowe wrote:
We've recently looked at a product that does use the phone to send a separate code:  Telesign 
(telesign.com<http://telesign.com>).  Any comments from a current user out there?

Theresa
On Tue, Feb 14, 2012 at 9:37 AM, Roger A Safian <r-safian () northwestern edu<mailto:r-safian () northwestern edu>> 
wrote:
In my mind, there's no doubt that security Q & A's are considered effective by both the users and the help desk team.  
OTOH, from the security point of view they are a huge risk.  Especially in education.  Our constituents are too young 
for many questions to be effective, so things like "what street did you grow up on?" or "What was your first car?" may 
in fact be the street they live on, or the car they drive, now.  In addition, people choose poor questions if they can 
make their own.  "What color is an orange?"  The number of compromises of celebrity accounts shows just how risky these 
questions are.  Personally I'd love to ditch them, but, I would need something more effective, and some way to pay for 
it.  I'd like to see something tied to their phone.  Maybe they register their cell, and we sms them a temp password.  
Not ideal, as people can be overseas, but I think it would be safer.

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () 
LISTSERV EDUCAUSE EDU>] On Behalf Of Theresa Rowe
Sent: Tuesday, February 14, 2012 8:00 AM
To: SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV EDUCAUSE EDU>
Subject: Re: [SECURITY] Self-service password reset approaches

We are looking at these processes, too.  I am surprised to read Steve's response about phasing out security questions 
and answers.  We just implemented this in 2011 and it has been very helpful.  With multiple campuses and online 
learning, we can't expect our constituents to visit campus.  We accept a faxed photo identity, along with other 
security information, and will call back with IDs and a pin reset that is forced on first login.

Account claiming - specifically providing the student ID number - is our biggest challenge.  How are you folks handling 
that?  We used to have a discovery web site, but we were told it wasn't FERPA compliant to display student ID like 
that.  Then we switched the site to email the ID, but that didn't work because the individual didn't have access to 
email if they hadn't set it up, and they needed the ID to set it up (catch-22).

Appreciate the discussion -
Theresa
On Thu, Feb 9, 2012 at 4:53 PM, Steve Werby <steve.werby () utsa edu<mailto:steve.werby () utsa edu>> wrote:
Dave,

It's good to see others considering the progressive approach that other industries have already adopted. Security 
questions are fraught with problems and put the users' accounts with other organizations at risk.

We've been designing and developing a system to move from password resets via answering security questions to resets 
via unique code sent to an alternate email address or mobile phone number via SMS. It's entirely optional, but since 
we'll be phasing out (and deleting) the security questions and answers, the next available disclosed alternative will 
be a physical visit to an authorized office who will require ID to be displayed. We're bundling the new process with a 
change from a typical password complexity/composition policy to a 15+ character passphrase. We're doing usability 
testing with a range of users right now and our pilot starts in March.

--
Steve Werby
Information Security Officer
Office of Information Security (OIS)
The University of Texas at San Antonio

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () 
LISTSERV EDUCAUSE EDU>] On Behalf Of David Curry
Sent: Monday, February 06, 2012 8:18 AM
To: SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV EDUCAUSE EDU>
Subject: [SECURITY] Self-service password reset approaches

It's been a few years since this has come up on the list, so here goes.

For various administrative reasons having nothing to do with security we need to make some big changes to our 
self-service password reset approach, and I'm trying to capitalize on the opportunity to improve its security at the 
same time. At the moment, we do what (we think) many other schools do -- provide student id number, netid (username), 
and date of birth, and you can reset your password. The problem with this is, of course, it was never that hard to come 
up with that information in the first place, and the combination of students doing more and more stuff online and the 
growing use of social media makes it just that much easier.

So... what other approaches are you taking?

There is of course the "pick a few security questions" approach. But it's hard to come up with a set of questions whose 
answers aren't trivial to guess (either because they have little if any entropy or because the answer is on Facebook). 
And if you do manage to come up with a set of hard questions, people can't remember what their answers were. Do you use 
this approach? If so, how have you addressed these problems?

We've been tossing around the idea of using something similar to the "email confirmation" links you see many forum-type 
websites use. In this approach, we would ask the user for some identifying information (netid, student id number, etc.) 
and then look up the email addresses we have on file. The user could choose any non-university email address in the 
list, and we would send a randomly-generated URL to that account, which the user could then click on to reset his/her 
password. Users for whom we have no alternative email on file (or for whom all the ones we have on file are "no good") 
would have to call the help desk. Does anybody use an approach like this? How well is it working (or not working)?

Any other "interesting" approaches out there?

Thanks,
--Dave



--

DAVID A. CURRY, CISSP * DIRECTOR OF INFORMATION SECURITY

THE NEW SCHOOL * 55 W. 13TH STREET * NEW YORK, NY 10011

+1 212 229-5300 x4728 * david.curry () newschool edu<mailto:david.curry () newschool edu>




--
Theresa Rowe
Chief Information Officer
Oakland University




--
Theresa Rowe
Chief Information Officer
Oakland University