Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!ames!joyce!sri-unix!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.unix.wizards
Subject: Re: /etc/shadow
Message-ID: <701@quintus.UUCP>
Date: 18 Nov 88 09:22:45 GMT
References: <17568@adm.BRL.MIL>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 19

In article <17568@adm.BRL.MIL> rbj@nav.icst.nbs.gov (Root Boy Jim) writes:
>? From: Doug Gwyn  <gwyn@smoke.brl.mil>
>? It bothers me that some network protocols send unencrypted passwords
>
>Perhaps I don't understand the problem fully, but it seems to me that
>I could just write a client that sends, say, the login name and the
>encrypted password (which I got from reading the password file) over
>the net and masquerade as a legitimate host.

Simple answer:  use two encryption functions.  A password PP then goes
through two stages:
  TP :=	encrypt(PP) for transmission to:(H)	   -- at calling site
  FP :=	encrypt(TP) for inclusion in:(/etc/passwd) -- at site H
The password which is sent of the net in this scheme is TP, which is
_not_ stored in /etc/passwd; _that_ one is FP.  TP would be stored
nowhere.  It would be vulnerable to a /dev/kmem watcher, but there is
a way around that:  when the caller says "I want to send a password",
site H sends back a one-time encryption function.  The next time PP is
sent to H, TP may be completely different.