Question

I'm new to Twiki as of yesterday, and running into some problems. I'm able to install and run version 4.0.2 without problem, but I can't figure out how to configure what I presume must be a common case. I want to set up an internal Wiki, which will be used by a small and preset group.

I'm using Apache and Linux, and am fluent in both. I'm running on a server over which I have full control. I am happy writing and patching Perl, although I'd rather not get far away from the release version for maintenance reasons.

Here's what I want:

1) I want to avoid passwords ever being sent in plaintext.

2) I want non-authenticated users to see nothing: no view, no edit, nothing.

Is there an established way of doing this? The closest I have come so far is to run the entire site under SSL and password protect the entire twiki directory. This will probably work (I don't need new user registration) but it seems like overkill. Am I missing some more elegant solution?

In particular, is there any way to have only the scripts that exchange password information running under SSL? I looks like I can do this by changing Twiki.pm::getScriptURL() to special case certain scripts, but this doesn't seem too maintainable.

Thanks for any suggestions.

Environment

-- NathanKurz - 09 Apr 2006

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

1) Avoid passwords ever being sent in plaintext: Put your whole TWiki installation under SSL, e.g. twiki/bin and twiki/pub. This has some performance implications. I am not sure if it is possible to apply SSL just partially (just for registration and login.)

2) Non-authenticated users see nothing: Require a valid user for the twiki/bin and twiki/pub directories.

-- PeterThoeny - 09 Apr 2006

As an alternative, you could rely on Apache's mod_auth_digest, which is a lightweight solution if all you want is avoiding to send plain text passwords. It has problems with MS IE as browser, with a more or less ugly workaround (see http://httpd.apache.org/docs/2.0/mod/mod_auth_digest.html). TWikiUserAuthentication shows how to activate apache login with /bin/configure.

-- HaraldJoerg - 09 Apr 2006

natlogin uses SSL for login by default. natlogin needs merging back to the code base. Perhaps you can take on this merge process?

-- MartinCleaver - 10 Apr 2006

Thanks for the quick responses. Unfortunately, I'm still pretty much where I started. As Peter suggested, putting the entire site under SSL and requiring a valid user for the entire twiki directory seems like the only reasonable solution.

The only other possiblity is to use session based authentication, split between http/https using mod_rewrite and modifications to TWiki.pm, and serve all /twiki/pub pages through viewauth (or view, since that will be protected as well). But I'll start here (all SSL) and try to do that switch if performance becomes a problem.

I did look at mod_auth_digest, and while it is little better, it still doesn't solve the passwords being sent in plain text when they are chosen and when they are changed. I searched a bit for natlogin, but found very few results, and as well I'm afraid it is too far off-topic for me to work on right now.

Notes for anyone else contemplating this:

1) If you are going to require authentication for view, it cannot be through Basic Auth else the password will be plaintext. So if anything is going to be non-SSL, login must be done once and maintained via a session.

2) You'll need to change to using absolute URL's for everything, otherwise the password data in form might be sent first in plaintext before being redirected (I think).

3) Probably you want to take a default secure approach: have everything served by the SSL host unless explicitly listed as an insecure script. Define 'insecureHost' in config, and then have a list of 'insecureHostScripts' that use this host, and then change TWiki.pm:getScriptURL to use this list.

-- TWikiGuest - 10 Apr 2006

Those who come here to look for uncencrypted transfer of passwords, without the other requirements of Nathan (no view access for the rest): Have a look at UsingSslForAuthenticationOnly.

-- JoachimSchrod - 30 Apr 2007