Subject: Re: Centralized User and Password Management
To: NetBSD Users <email@example.com>
From: Dick Davies <firstname.lastname@example.org>
Date: 11/29/2004 13:07:51
* John Nemeth <email@example.com> [1116 21:16]:
> On Apr 17, 5:57pm, Dick Davies wrote:
> } * Tillman Hodgson <firstname.lastname@example.org> [1103 22:03]:
> } > On Thu, Nov 25, 2004 at 04:52:39PM -0500, Greg A. Woods wrote:
> } My understanding of PAM/Kerberos is sketchy, but I assume the client
> } just blindly sends its user/pass to the server (which then gets a ticket
> The client would have to send whatever the server wants, which
> would be dictated by the protocol being used. With my understanding of
> Kerberos, the client would only send the username to the server. The
> server would send back some information encrypted with the user's
Kerberos doesn't rely on shared secrets like that.
There's a good walkthrough of Kerberos at:
> } on the users behalf to validate the passphrase?), since
> } PAM is fundamentally user/pass based.
> PAM is not fundamentally user/pass based. It is in fact not based
> on any particular authentication method.
No, but every PAM module I've seen relies on a 'username' and 'password'
if you think of 'password' as 'string of bytes used to authenticate user'.
This isn't a good fit to ticket-based authentication.
> } server identification (there are no tickets coming back from the
> } server to the client). You'd have to rely on SSL CRLs to 'untrust'
> If you use Kerberos, you would get the appropriate information
> back. You'd just have to have a secure way of storing the TGT so that
> different applications could get to it.
In practice i believe each server ends up holding a TGT (or more sensibly
a service ticket) for each client that has authenticated to it with pam_krb5.
The point i'm making is with this setup I have to give my principal and
passphrase to a remote machine which I can't be sure is who it says it is.
> } I gave up and went to ldap auth - it has its warts but load balancing
> } works well, and it feels like a better match to pam, plus it does
> PAM is fully modular and thus can use any protocol you want.
I'm not sure what your point is. i'm saying pam_krb5 is more of a hack than
pam_ldap, since an ldap bind is a better fit to pams mechanisms than asking
a server to obtain a service ticket on your behalf (which is the only way to
map user/pass (or whatever you prefer to call it) based authentication to
ticket based auth.
> } But the single password feature is definitely a double-edged sword,
> } especially when keyloggers are so prevalent. You need to be careful about
> Keyloggers would record all passwords entered, so it doesn't
> matter how many passwords are used, unless you restrict the places from
> which they can be entered.
What I mean is that with a single password for everything, the potential value of
a stolen password is much greater. If I use subversion from windows and
a keylogger steals the password, the attacker only gains access to other things
that use .htaccess. If I'm using mod_auth_ldap, the attacker has my ssh/pgsql/etc etc
If we can hit that bull's-eye, the rest of the dominoes will fall like a
house of cards... Checkmate! - Zapp. Brannigan
Rasputin :: Jack of All Trades - Master of Nuns