On Sat, May 5, 2012 at 6:25 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Fri, May 04, 2012 at 11:17:58PM -0400, Nico Kadel-Garcia wrote:
> > Now, all that said: I *loathe* HTTP/HTTPS password based acces, because
> > there is no way to prevent your clients form storing passwords locally on
> > Linux or UNIX hosts. They don't *have* to use the kwallet or
> gnome-keyring
> > tools, and you can't make them without snooping on them all the time.
>
> There are more authentication options available in httpd than just
> BasicAuth.
>
> Some are single-sign on solutions and don't require any password at all.
> Kerberos and SSPI for example. If httpd admins configure the server with
> one of these authentication options no password will ever be stored.
> Alas, whether you can use these options depends on the existing
> infrastructure -- same story with SSH though.
>
Well, yes. There are SSL key based authentication methods, for example. And
in theory, Kerberos can work out. Unfortunately, few small sites set up
Kerberos, and even sites that do don't mandate the use of the keys. Let's
actually look at the RHEL 6 mod_auth_kerb settings, shall we?
#<Location /private>
# SSLRequireSSL
# AuthType Kerberos
# AuthName "Kerberos Login"
# KrbMethodNegotiate On
# KrbMethodK5Passwd Off
# KrbAuthRealms EXAMPLE.COM
# Krb5KeyTab /etc/httpd/conf/keytab
# require valid-user
#</Location>
Not active by default nor configuerd for Subversion, that's OK.
KrbMedhodK5Passwd Off:, that prevents the use of pure password negotiaton
and forces clients to use Kerberos tickets. Except...... if you have RHEL 4
systems, or Subversion clients from older but still active systems, you're
screwed and must use password negotiation. That means password storage on
the client, of your *Kerberos passwords!!!!!*
Note the unlisted default setting "KrbAuthoritative On". That one, set to
off, allows authentication to be passwd to other modules.
Also note: if the user is not in Kerberos, this becomes unusuable. Many
system accounts, such as "named" and "root", would benefit from centralized
source control access to a read-only repository. (I'm preseint about just
such a setup for BIND in June.) Setting up Kerberos authentication for
system rather than user accounts becomes.... an adventure that could
require a lot of thought, especially for unattended operations.
So it's potentially *better* to use Kerberos, but it does present
configuration issues. It's certainly not plug and play, and it's very easy
for people to wind up storing their passwords in the clear again, only this
time tied to their Kerberos passwords.
Received on 2012-05-05 13:07:00 CEST