Improving password security

Brian Holt brian at apollo.COM
Tue Dec 6 08:35:00 AEST 1988


In article <2220 at cuuxb.ATT.COM> dlm at cuuxb.UUCP (Dennis L. Mumaugh) writes:
>In article <716 at quintus.UUCP> ok at quintus.UUCP (Richard A. O'Keefe) writes:
>>Not so trivial if the revised crypt() is an RPC call to a "crypt server";
>>then you would need read access to the crypt server code as well.  [This
>>would be one occasion when the added cost of an RPC call would be welcome!]
>>
>After battling a recalcitrant NFS system for this last four days, this
>hits home!   You assume that 
>	1). The network is working
>	2). The RPC and the TCP/UDP underneath are working
>	3). The RPC server is running and sane
>	4). The RPC data base is sane.
>All of the above would be required for one to login.  Any one
>thing wrong and you couln't login.  Remember most work stations
>and general customer machines boot into multi-user automatically
>and not everybody has diskless workstations.  One could not login
>even as root to fix things.
>
Another approach to this was detailed in a paper given at
the Jan. 1988 Usenix Conference ("A User Account Registration
System for a Large (Heterogeneous) UNIX Network"; Pato, Martin
and Davis).  This details Apollo's new heterogenous distributed
registry.  It is based on NCS, and runs on Apollo's, Sun's,
Vaxen, etc.  The idea is to have a distributed, replicated
database that is accessed via RPC mechanisms.  In addition, 
a local cache keeps track of verification information for
the most recently (most frequently? Not sure) accessed accounts.

I don't work on this, I just use it, and it all seems to 
work well, certainly better than the hassle's I've heard of
with other approaches.  

Please read the paper (it's in the conference proceedings, p. 155) 
before asking further questions.

		=brian


Here's the abstract (reprinted without permission):

Three problem areas arise when considering a user registration
system for a large heterogenous distributed computing environment.
Large environments demand controls on the complexity of administration.
heterogeneitty requires an examination of the notion of identity in the
network as well as the interoperability of software on different
hosts.  Distribution raises the problems of availability, reliabilty
and security.

Generally available UNIX environments (4.3 BSD and AT&T System V.3)
provide few tools for solving these problems.  Account administration
is typically handled through manual editing of a single /etc/passwd
file.  Consistency is maintained on multiple machines by periodically
copying the /etc/passwd file to each machine in the network.  For
large networks, with thousands of users and machines, these mechanisms
are clumsy and error prone, and they vest too much power in a single
system administrator.

RGY is a replicated user registration system built on Apollo's 
portable Network Computing System (NCS).  The system consists of
a set of daemons which maintain a replicated user registration database.
Remote access to the user registration database is provided at
each client site through remote procedure calls ina portable
subroutine library that replaces the getpwent(3) and getgrent(3)
C library calls.  Weakly consistent replicatino provides a high degree
of availability and reliability.  Propagation of individual 
updates is performaed yielding an inexpensive mechanism for
maintaining consistency.  Updates are secureely performed using
authenticated interfaces, allowing any client site to update the 
database.


-- 
Internet: brian at apollo.COM            UUCP: {decvax,mit-erl,yale}!apollo!brian
NETel:    Apollo: 508-256-6600 x5694         Home: 617-332-3073    
USPS:     Apollo Computer, Chelmsford MA     Home: 29 Trowbridge St. Newton MA
(Copyright 1988 by author. All rights reserved.  Free redistribution allowed.)



More information about the Comp.unix.wizards mailing list