× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: How to preserve password change date
  • From: "Kempter, Eric" <EKempter@xxxxxxxxxx>
  • Date: Wed, 19 Nov 97 09:36:00 PST


At a former position, we had a security procedure very similar to the one   
that Dave describes.  When a new user profile is set up, the profile is   
set up as expired so that the user must change their password when they   
initially sign on.   This way the user should be the only one that knows   
their password.  I was relatively certain that our security integrity was   
intact until one day.
I was showing a new employee and their supervisor how to change their   
password on a new profile.  Everything went smoothly, the supervisor and   
I both looked away as the user entered and confirmed their new password.   
 As I was walking away, I heard the supervisor ask the new employee what   
their password was.  I returned and asked the supervisor why she wanted   
to know.  It turned out that the supervisor required all of her employees   
to give her their password so that she could access their e-mail if they   
called in sick.  She then proceeded to show me her list of names and   
passwords for every person in customer service (25 people at the time).   
 She was also telling her employees where this list was kept in case they   
forgot their password and needed to look it up.  Talk about your security   
holes!

Eric Kempter
Sr. Programmer/Analyst
E-Mail: EKempter@smsocs.com


 -----Original Message-----
From: midrange-l-owner [SMTP:midrange.com!midrange-l-owner@mcs.com]
Sent: Wednesday, November 19, 1997 3:23 PM
To: 'MIDRANGE-L@midrange.com'
Subject: RE: How to preserve password change date

>If I ever get the time...

Come on, Paul! How long is going to take for someone with your
experience to put a proper procedure in place?

The usual standard is to set the password either equal to the newly
created ID, or to a randomly generated value. When a disabled ID is
reset the same thing happens; the password is set back to the standard
value, but expired. This gives the user some confidence that they, and
only they, know the password. We _never_ ask for a user's password, and
if they volunteer the information, as they sometimes do, we immediately
reset them. Maybe the user just did, or is about to do, something they
shouldn't and they want to cover themselves by making sure that it could
have been someone else.

We additionally have an overnight process that disables unused IDs if
they are 3 days old, and any IDs that haven't signed on for 90 days, so
they have to call the help desk to get them re-enabled. The help desk
(have a procedure to) positively identify each caller who requests a
password reset.

We then delete IDs that haven't been used for 6 months (so far I've hit
the managing director and the head of HR, but they obviously hadn't felt
a need to use JDE, and why should they?) and ID's of terminated
employees. This all makes it harder for IDs to be misappropriated.

There's some delay in the termination process so I occasionally get a
call from someone complaining that they can't sign on and the help desk
can't re-enable them.

Me:     What's your ID, Don?
Caller: JRCO.
Me:     Err... according to the HR report you don't work here
        anymore, and your name is Jeff.
Caller: Oh, well, actually that was my predecessor's ID. You see,
        we're so busy up here there's no time to go through the
        formalities, so Jeff just gave me his password and I use that.
Me:     Not any more, it seems.
Caller: So if you could just reset it for me I'd appreciate it.
Me:     Sorry, it's history.
Caller: Can you create an ID for me?
Me:     Sure. Fill in the forms, get them signed by your manger,
        bring them to the help desk and they'll assign you a
        network ID. When they've done that...
Caller: But I haven't got time to do that. I'm really busy.
Me:     Not any more, apparently.

Occasionally there's a certain Schadenfreude in the life of a system
administrator.  :-)

Dave Kahn, TCO, Kazakstan
=========

kahn@tengizchevroil.com   (to November 25)
dkahn@cix.compulink.co.uk (from November 26)

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.