On Apr 5, 2007, at 5:15 PM, Martha McConaghy wrote:
Perhaps I should have said "self-service" which seems to be a
common term
(I've been googling..).
We want to implement a system that would allow users to reset their
forgotten
passwords, have secret phrases to validate ID, etc. I've found some
commercial
solutions that we will look at, but I'd also like to look at open
solutions, if there are any. I haven't stumbled across any on
Google yet,
but figured this group would know if anyone would.
There may be such a thing.
However....
Is the volume of requests you get really more than your system
administration staff can handle? ("Yes" is an OK answer.)
I ask because automated password reset systems, unless designed very,
very carefully, can lead to trivial denial of service attacks or
account hijacking. Consider the following scenario.
Student S has left himself logged in at a lab and walks away.
Student M sees this and pounces on the computer before the
screensaver can pop or the idle timer can logout. Student M knows
that once he has logged out, he can no longer get back in. But if he
drops a .forward file in place pointing to some place he controls,
and then triggers a password reset, boom, he's in.
This is only somewhat harder if you have a "security question". If
the question is chosen from a list of pre-specified questions, then,
well, "blue" as a favorite color works pretty often. The city you
were born in may not be much of a secret. And your high school
mascot is probably a lion, a wildcat (that's mine), or a viking. If
you let people pick their own security questions then you have to
find a way to not let them ask questions like "The answer is
'swordfish'".
Note that it's not, usually, a lot harder to social-engineer your way
around a helpdesk or system administrator, but people who will sit
down at an unoccupied machine and be nefarious are often not up to
picking up the phone and pretending to be someone else. Of course,
if your reset procedure is "we have set your password to your student
ID number, but you must change that the next time you log in," then
that means that anyone who *does* trigger such an attack after
swiping someone's ID from their lunch table knows the new password.
An approach I've seen used with success is that you generate a new
one-time password and print it out, and that the person who requested
the change has to come to the computing center and present ID to
claim the piece of paper with the new password on it. This, however,
is likely to be insufficiently convenient for your users, especially
during high-intensity high-stress portions of the academic year. And
good luck getting someone with tenure to actually trek across campus
to get his or her new password.
Of course, the common attack you want to defend against might be
entirely different. I'm just saying, be *very* certain that this is
really what you want to implement.
Adam
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
