SUMMARY (2): Password lifetime without enhanced security?

From: Bernt Christandl <beb_at_rosat.mpe-garching.mpg.de>
Date: Tue, 28 Mar 95 13:44:47 +0200

Dear Alpha-Managers,

meanwhile i've got three responses to my first summary and i think
they could clarify very good, why you cannot have password lifetimes
under osf/1 v3.0 without enabling C2 security
(done by digital, see below ;-)

Thank you all again!

Bernt
                                                                     
-------------------------------------------------------------------------
- Bernt Christandl / Max Planck Institut fuer Extraterrestrische Physik -
- D-85740 Garching / Phone: +49/89/3299-3346 / Fax: +49/89/3299-3569 -
- Internet: beb_at_mpe-garching.mpg.de -
-------------------------------------------------------------------------

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Return-Path: tpb_at_zk3.dec.com
To: "Bernt Christandl" <beb_at_rosat.mpe-garching.mpg.de>
Subject: Re: Password lifetime without enhanced security?
In-Reply-To: Your message of "Mon, 27 Mar 95 08:25:03 +0200."
             <9503270625.AA25664_at_o01.rosat.mpe-garching.mpg.de>
Date: Mon, 27 Mar 95 08:41:56 -0500
From: "Dr. Tom Blinn, 603-881-0646" <tpb_at_zk3.dec.com>
X-Mts: smtp

> Dear Managers,
>
> is it possible to establish a password lifetime (OSF/1 v3.0)
> without using the enhanced security?
>
> Thank you.

Sure. It's possible to do nearly anything with UNIX provided you are
willing to persevere.

Here's a way to do it:

You set up a shell script that runs under cron whose role in life is to read
the /etc/passwd file periodically, and compare the passwords in the file (in
encrypted form, of course) to those in some other file maintained by the
script. This second file contains both the user id, the encrypted password,
and the date on which the password is last known to have changed. Whenever
a user's password has not changed in the appropriate interval (base on the
age of the "last known change" in the database), the script takes some
action that is deemed appropriate, such as changing the password in
/etc/passwd to one that isn't known to the user, or otherwise invalidating
the user account, or alternatively, notifying someone (site security admin)
or whatever. If you're using hashed passwords, then you need to also update
the hashed password database if you change /etc/passwd. And, of course, if
you're using YP (NIS), then you have to do this on the master server and be
sure to propogate the changes to the secondary servers.

Or did you want Digital UNIX to do this for you without using enhanced
security?

Tom
 
 Dr. Thomas P. Blinn, UNIX Software Group, Digital Equipment Corporation
  110 Spit Brook Road, MS ZKO3-2/U20 Nashua, New Hampshire 03062-2698
   Technology Partnership Engineering Phone: (603) 881-0646
    Internet: tpb_at_zk3.dec.com Digital's Easynet: alpha::tpb

  Worry kills more people than work because more people worry than work.

     My favorite palindrome is: Satan, oscillate my metallic sonatas.
                                         -- Phil Agre, pagre_at_ucsd.edu

  Opinions expressed herein are my own, and do not necessarily represent
  those of my employer or anyone else, living or dead, real or imagined.
 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Return-Path: scott_at_zk3.dec.com
Date: Mon, 27 Mar 1995 14:06:16 -0500
From: Larry Scott USG <scott_at_zk3.dec.com>
Message-Id: <9503271906.AA02964_at_alpha.zk3.dec.com>
To: beb_at_rosat.mpe-garching.mpg.de
Subject: Re: SUMMARY: Password lifetime without enhanced security?

Bernt,

> here is the summary to my question, whether one can have something
> like password lifetime without enhanced security (under osf/1 v3.0).
>
> response one: "me too" i'd like to know...
>
> response two: (from dec) "nope."
>
> response three: (this one one is the good one!)
>
> "i use the XIsso-Security under /usr/tcb/bin/ to do that"

I agree with "response two". The password lifetime is stored in the
authcap file along with the corresponding password. Unless you use the
authcap files (enhanced security), you can't get password expirations.

Hope this clarifies.

larry

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Return-Path: pdf_at_porthos.ucs.mun.ca
From: Paul David Fardy <pdf_at_porthos.ucs.mun.ca>
To: "Bernt Christandl" <beb_at_rosat.mpe-garching.mpg.de>
Subject: Re: SUMMARY: Password lifetime without enhanced security?
Date: Tue, 28 Mar 95 01:39:19 -0330

Your message dated: Mon, 27 Mar 95 13:00:57 +0200
>My first glance at the manpage (man XIsso) says, that XIsso is part
>of the enhanced security.
>
>Now i have to learn how to use IXsso without enabling enhanced security.
>As i understood response three this can be done somehow.

XIsso won't work without C2 and you won't get password expiration without
going to C2. The expiration is by done timestamping password modifications
in /tcb/files/auth/b/beb (/tcb/files/auth/p/pdf, etc.), and setting default
time limits in /etc/auth/system/default. These files are part of DEC's
C2 package. You won't be able to implement a non-C2 password expiry short
of replacing /bin/passwd. Effectively, C2 replaces /bin/passwd because
it replaces the shared library functions passwd uses.

Actually shadow passwords is a more important feature of C2. By hiding
the crypted passwords you don't really have to worry much about
expiry. You just have to worry about people monitoring the network.

You should also note that XIsso and XSysAdmin suck. We have 3400+
users and XIsso likes to create sorted lists of users (by name).
Improvements in the sort algorithm have reduced the sort time from 25
minutes to 1.5 minutes. I ended up writing perl scripts to do the work.
X interfaces don't allow batching and XIsso is difficult to make use of
via cron.

        Paul Fardy

--
Paul David Fardy                     Memorial University of Newfoundland
Systems Programmer                   Elizabeth Avenue
Technical Support Group              St. John's, NF  A1C 5S7
Computing and Communications         CANADA
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Received on Tue Mar 28 1995 - 06:45:36 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:45 NZDT