🚀 go-pugleaf

jfh@rpp386.lonestar.org (John F. Haugh II) writes:

>In article <Bu9ILz.4Fy@cck.coventry.ac.uk> ccx009@cch.coventry.ac.uk (Adam Bentley) writes:
>>I've got  John F. Haugh II's  package but its way off being ready to go 
>>especially on an old 4.2 unix without things like password aging.

>You can just turn aging off when you build Shadow.  If there are other
>problems, please report them to me as bugs and I'll get them fixed.

>Actually, a better person to get ahold of is Steve Simmons.  He did a
>significant amount of work in that area.  I don't know where he is
>hiding these days ...

I'm still alive (buried alive?) and kicking.

Our (my) work on the BSD version of the shadow utilities went out the
door along with co-workers and support for such things in one of our
regular re-orgs at ITI.  I have several versions of the code, one of
which ran under Ultrix 3.1 and another which ran under SunOS 4.0.3.
There was also some code for a Gould Powernode, but I believe that it
got merged into the Sun version.  If there is interest I can make it
available for anon ftp.

The SunOS code and most of the Ultrix code consisted of an earlier
version of John's work, some freed BSD stuff, and a few odds and ends
I threw in.  In particular we'd developed our own password aging
code as AT&T style was a bit less than we needed.  There are also
patches to the Ultrix login source for 3.1.

There was one bit I'm proud of which John didn't pick up (I'm not
complaining; it was definitely "non-standard").  When converting to
shadow passwords, the new /etc/passwd file normally gets converted
to something like

  scs:x:10:20:....

Instead, my version did

  scs:WMMXAlZzpoIx4:10:20:....

where "WMMXAlZzpoIx4" was a randomly generated string.  In addition,
the name of the shadow file was site-configurable.  Thus it was not
possible for the cracker to easily determine if a given site used
shadows by simply examining the password file.  One copy of our
password file with these junk strings drifted thru the cracker
community for a while, much to my amusement.  Note that you should
change the random string when changing the password.

In the course of working on this, I learned several things.  First,
John writes pretty decent code.  Second, there are far too many
utilities which break when you put in shadow passwords.  Pcnfsd, uucpd,
either rlogin or telnet -- just too damned many things.  I patched
things right and left, and still didn't find them all.  Screensavers
were a particular problem, as you either need to make them suid root or
give them up.

As a correlary to this, I thought a lot about a "password verifier",
some utility program which could be used to determine if a given
password was correct or not without having to actually expose the
password either in cleartext or by encrypted string.  I came to the
conclusion there is no perfectly safe way, but you can make the window
very very tiny.  You open a pipe, fork the program that wants to do the
verify, the child execs the verifier, then writes the password to the
verifier on the pipe.  The child returns the verification by its exit
status.  The password should never be placed in the environment, and
the instant it is no longer needed should be overwritten in the
buffers.  Reasons are left as an exercise for the reader. :-)  Note
that at that time I thought the Needham and Schroeder (sp?) algorithm
was patented or I would have used it to encrypt/decrypt the
communication.

A third complicating factor could be called "keeping up with the
vendors".  DEC does some interesting and useful things in their logins,
and getting (buying) new copies of the Ultrix source to keep in sync
was simply not possible.  I could probably have retrofitted, but the
management decision was to use the stock Ultrix stuff instead.  C'est
la guerre.

Other interesting issues I recall --

 o  What should one do about expired passwords?  Throw them from
    login into passwd?  Throw them out?  How long should you let
    them go?

 o  Should rsh work if the password is expired?  Think carefully....
    How about rcp?

 o  How long before expiration should you start warning users?  How
    do you make it site-configurable?  Can you reconfigure it without
    modifying login?

 o  Should account expiration be a separate issue from password
    expiration (it was in our version)?  What does that mean to rsh,
    rlogin, rcp?

 o  You definately need some utilities to print the age and expiration
    data in a human-readable fashion.  Setting them in a human-readable
    fashion is a good idea too.

Sigh.  There were other things, but that's a off-the-top-of-the-head
list.  Maybe someday I'll get a client willing to pay for this stuff.
Until then, folks are welcome to it.
-- 
 "When Dexter's on the Internet, can Hell be far behind?"
		-- Steve Simmons, scs@lokkur.dexter.mi.us