Security issue with pam-krb5 ?

Matthijs Mohlmann matthijs at
Thu Aug 28 15:33:18 EDT 2003

So when i login on my workstation:

auth       requisite
auth       requisite
auth       required
auth    sufficient nullok
auth    required nullok
account    required
session    required
session    optional
session    optional standard noenv
password   required nullok obscure min=4 max=8 md5

Then is my login procedure not secure.

Then my question is: How can i make this secure ?

This file isn't correct. I have my session and account information in a
LDAP database. I haven't right the time to change it.

Sorry about my horrible english :)

On Wed, 2003-08-27 at 21:47, Steve Langasek wrote:
> On Wed, Aug 27, 2003 at 03:37:24PM -0400, Brian Davidson wrote:
> > On Wednesday, August 27, 2003, at 02:16 PM, Matthijs Mohlmann wrote:
> > >Am i right when i say libpam-krb5 send's the password cleartext over 
> > >the
> > >network ?
> > In a nutshell, yes.  The username & password is still sent across the 
> > network to the daemon as if you weren't using libpam-krb5.  Instead of 
> > checking the passwd file, libpam-krb5 attempts to obtain a TGT from 
> > your KDC.  Successfully obtaining a TGT means you are authenticated.
> libpam-krb5 does *not* send passwords across the network; it is the client
> software that would be sending passwords across the network in the clear
> if being used from a PAMified network server.  This is not a function of
> libpam-krb5, but a function of PAM itself.  Any communication between
> libpam-krb5 and the KDC is properly secured.
> > If you use libpam-krb5 for telnet, then your username and password go 
> > across in plaintext.  Same for ftp.  If you use ssh, then they are 
> > encrypted.  Anything running over SSL should allow you to *relatively* 
> > securely use libpam-krb5 for authentication.
> s/libpam-krb5/PAM/
> > The downside is that a modified libpam-krb5 on a system could steal 
> > passwords & stash them in a file.  "Pure" kerberos won't allow that to 
> > happen, since hosts never receive the user's password.
> Right.

More information about the Kerberos mailing list