On Sat, May 5, 2012 at 6:25 AM, Stefan Sperling <s...@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.
