Feature Proposal: Improve default protection of configure script

Motivation

T* project has added a scripted login for configure similar to template login, providing basic protection. As configure is a critical component, it should be protect much more strongly, and default to digest auth to avoid sniffing of passwords.

Description and Documentation

We should be able to both improve on this and simplify it as well by defaulting to htdigest authentication, shipping a "default" htdigest password file, and changing the initial password save code to update the shipped file with the saved password.

Examples

Impact

Minimal impact on configure, which needs code to update the digest file when the password is saved.

No impact on sites choosing to use LDAP auth in apache. This feature would not be used.

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

Apache configuration excerpt for configure:

    <FilesMatch "^(configure.*)$">

        AuthType Digest
        AuthName "Foswiki Administrator Password"
        AuthDigestDomain /bin/confgure/

        AuthDigestProvider file
        AuthUserFile /var/www/foswiki/lib/Foswiki/Configure/resources/.htdigest-admin
        Require valid-user

Sample htdigest file for admin:setup

admin:Foswiki Administrator Password:68dc9ba47fb5d0e1e13a2ea6858c336d

General configure operation remains unchanged,

• the real admin password is set on first run of configure.
• configure is modified to update the admin entry in the .htdigest-admin file
• the $Foswiki::cfg{Password} is unchanged

-- Contributors: GeorgeClark - 19 Nov 2011

Discussion

personally, I'd rather there was a template login to it by default, so that its safe right from the the point where someone does not do apache config (unzip into cgi-bin on a hosting site)

-- SvenDowideit - 19 Nov 2011

So assuming we add a template login as a basic level of security, you are okay with using a default password of "setup" (or similar) - but treating it as a "no password" scenario to require it be changed upon first save?

Some more ideas:

• Include by default a .htaccess file in bin that protects configure. This would be ignored by any site using an apache configuration with allow override disabled, but would be more secure on a hosting site.
• Look for an apache REMOTE_USER of "admin" and bypass template login if Apache has done the authentication? Or can we accept any authenticated user and assume that apache is configured to restrict configure to authorized users.

I would make this a brainstorming topic - because it's probably more at that point than a firm proposal. But those topics in development seem to not attract any attention.

I'd like to somehow

• Make configure secure "out of the box"
• Clear the confusion with protecting configure - it's a common issue for new installations
• Use best practice for securing configure short of https which is probably too complex for many sites.
• Be compatible with alternative security - like protecting configure with alternative authentication - ldap, etc.

-- GeorgeClark - 19 Nov 2011

This has got a bit lost in the snow, but I think it's worth revisiting. Here's a simple proposal:

• Add a template login to configure, using the existing password (which uses crypt, and could potentially use George's JS enhancement for encoding the PW, though I personally think that's overkill)
• Start with an initial null password that is forced to be changed during the first run of configure
• Recommend digest auth in addition to anyone wanting more security, and .htaccess too

A default .htaccess is a fine idea, if you can work out how to point at AuthUserFile without requiring a user edit (which would be too complex for most people)

I would be reluctant to do anything more sophisticated, because complexity always seems to lead to confusion.

-- CrawfordCurrie - 27 Feb 2012

I really don't like passing the password in the clear, especially for something as valuable as the configuration password. I did a quick review of the (tm)wiki version of protecting configure. If I understood that code correctly, they pass the config password as a url parameter in each iteration rather than using a session? (Not really sure - I didn't install it to verify). It's bad enough passing it when changing the password, but on every transaction?

BTW, configure no longer uses crypt. As of distro:5f7d47ed0acc it uses a salted MD5. Not as good as apache-md5, and not compatible with a .htaccess or .htdigest file, but still much better than crypt.

I'm thinking of changing that - to actually use a hash compatible with Apache HTDigest. I think I can still do that without needing any new CPAN modules. No value to changing this again. Configure can still write out a .htdigest file - the hashes don't have to match.

As far as using digest auth, existing sites would not be effected. But the new install would get it by default:

• Add the digest protection for bin/configure to the ApacheConfigGenerator and NewApacheConfigGenerator
• Both of these config files need tailoring anyway, so... (.deb and .rpm installs can tailor it for their package defaults)
  • Add it to the default bin-htaccess file. So any site installing on a hosted server will get it by default
  • Add it to the sample foswiki.conf file.
• Ship a default .htdigest-configure file in some directory that is assured to be writable by the configuration. I think working/configure might be a good location. It is pretty much guaranteed to be writable, and should be reasonably predictable
• When the configure password is created or saved, write out a revised .htdigest-configure file, which we ship by default with an initial password.

By doing this:

• New sites are protected out of the box if they use the sample bin-htaccess or foswiki.conf files, or ApacheConfigGenerator.
• Everyone gets a stronger configure password the next time they change the configure password.
• Existing sites would run with the same protection, unless they use ACG or edit the config files. (yes this is the downside).

-- GeorgeClark - 27 Feb 2012

OK, sounds like a plan; and there have been no real changes to your proposal since first committed, so I'm pushing it to Accepted under the 14-day rule. BTW I totally agree about passing passwords in clear; it's endemic on the web

-- CrawfordCurrie - 28 Feb 2012

I'm working on implementing this. The only thing that has changed is the addition of Session support in configure in 1.2. The final combination:

• Ship sample .htdigest-configure file in working/configure directory
• Adjust sample bin-htaccess.txt files and ApacheConfigGenerator to protect the configure script using this file.
• If configure is run and apache does not provide authentication information
  • If configure password is available, prompt for password before allowing access
• If apache has an authenticated user
  • Configure bypasses the initial password prompt.
  • If more than 1 hour has lapsed, the user is prompted anyway. (Session timeout overrides apache auth, requiring a re-validation.)
• When the use sets or changes the Foswiki admin password
  • If .htdigest-configure file in working/configure directory exists, the "admin" entry will be updated with the new password.

-- GeorgeClark - 12 Jun 2012

This work was made moot by the 2.0 configure changes. Discarded.

-- GeorgeClark - 5 Jul 2015