Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!edcastle!aiai!richard
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.unix.admin
Subject: Re: Kmem security
Message-ID: <4331@skye.ed.ac.uk>
Date: 18 Mar 91 15:31:08 GMT
References: <513@bria> <1991Mar12.132003.27383@cs.widener.edu> <14454@ulysses.att.com> <1991Mar13.180300.17697@convex.com> <9103152251.41@rmkhome.UUCP>
Reply-To: richard@aiai.UUCP (Richard Tobin)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 18

In article <9103152251.41@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes:
>Think about it.  Look at the UNIX tools you have available.  Consider the fact
>that /dev/kmem is a file.  When anyone logs in, even root, login has to decrypt
>the password in /etc/password to compare it to the password typed it.  This
>password in memory lays around for a while.

Though the user's password is stored in memory temporarily, it is
*not* the case that the encoded password in /etc/password is
decrypted.  After all, if login could decrypt it, so could you.  The
password the user types is used as a key to encrypt a fixed string
(all zeros) and the result is compared with the data from the password
file.

-- Richard
-- 
Richard Tobin,                       JANET: R.Tobin@uk.ac.ed             
AI Applications Institute,           ARPA:  R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin