Re: Security problem in pam_unix?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 11, 2000 at 09:40:59AM +0000, John Haxby wrote:
> Steve Langasek wrote:
> 
> >
> > If you don't trust the local system administrator with your password, you
> > shouldn't be giving that password to a piece of software that he has control
> > over, *PERIOD*.  He doesn't need PAM's help to get at that information.
> > Whether PAM logs usernames from failed logins is inconsequential in comparison
> > to the problems you face if you believe your system administrator has
> > malicious intentions.
> >
> 
> I *don't* trust the administrator with my password.   It's kept on the other side
> of a one-way function for precisely that reason.   Passwords are not kept in
> clear *PERIOD**.  If you don't understand why, think about how often people have
> different passwords for different machines or purposes.  If you are still don't
> see why, then I'll try to explain.
> 
> jch
> 
> 
> * There are cases where pass phrases need to be available in their original form,
> but, in these cases the software goes to a hell of a lot of trouble to make sure
> that they are properly protected.

The admin can always change the programs you use (login, sshd, ftpd, PAM)
to save the passwords you enter into a file. Nothing prevents that. Even
without this, the encrypted passwords offer no protection against
brute-force programs and lots of cpu/time, which is why we have shadow'ed
passwd files (which keeps them from the luser, but not the admin).

I agree with the premise of not putting the info into the logfiles as
pam_unix does on an incorrect username, but I disagree that it protects
you from the admin. The only thing it protects you from is the case where
you use a network nameserver (NIS/LDAP/KRB) where the passwords (even
encrypted) are not stored on the local machine. Even then, if a cracker
has infiltrated the system enough to get the log files, it only takes a
slightly smarter cracker to start hopping systems on the LAN and
eventually get to the master server.

Moral: If you can't trust the admin, use a different password than you
normally do (always a good idea anyway), or don't use that system. In
these cases, I always use ssh along with an RSA key (where the passphrase
is never sent across the wire, *never*), and I turn my password into
garbage and forget about it, since I don't need it at that point.

Ben

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'





[Index of Archives]     [Fedora Users]     [Kernel]     [Red Hat Install]     [Linux for the blind]     [Gimp]

  Powered by Linux