Path: utzoo!utgpu!watmath!clyde!att!cuuxb!dlm
From: dlm@cuuxb.ATT.COM (Dennis L. Mumaugh)
Newsgroups: comp.unix.wizards
Subject: Re: Improving password security
Summary: RPC depends upon netnworking
Keywords: password, security, crypt server via RPC
Message-ID: <2220@cuuxb.ATT.COM>
Date: 22 Nov 88 03:23:36 GMT
References: <21670@pbhya.PacBell.COM> <27987@tut.cis.ohio-state.edu> <716@quintus.UUCP>
Reply-To: dlm@cuuxb.UUCP (Dennis L. Mumaugh)
Organization: ATT Data Systems Group, Lisle, Ill.
Lines: 23

In article <716@quintus.UUCP> ok@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.

Hmmmmm.  Do you plan for a trap door in the code if RPC fails?
How about if it is just extremely slow.  How do you know the
difference [cf.  Turing Halting ]?
-- 
=Dennis L. Mumaugh
 Lisle, IL       ...!{att,lll-crg}!cuuxb!dlm  OR cuuxb!dlm@arpa.att.com