|
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 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.