[pmwiki-users] questions about user authentication

Joachim Durchholz jo at durchholz.org
Wed Apr 13 10:06:43 CDT 2005


Patrick R. Michaud wrote:

> On Wed, Apr 13, 2005 at 02:15:47PM +0200, Joachim Durchholz wrote:
> 
>>>Q2: What sorts of features are needed for users who have forgotten
>>>their passwords?
>>
>>A "mail-me-a-new-password" feature.
>>(Don't mail existing passwords. Some users have a single password for 
>>everything, from POP retrieval to on-line banking. That's also the 
>>reason why passwords shouldn't be stored in the clear.)
> 
> PmWiki has never stored any of its passwords in the clear.
> The feature will likely be "mail me a link that lets me set a new
> password for a short period of time".

That's an excellent model.

>>>Q3: Is there anyone who has an immediate need/use for authenticating
>>>via an LDAP or Active Directory Server?  (If so, is there an LDAP or
>>>AD server somewhere that I could test against?)
>>
>>Not me.
>>I already mentioned I'd like to use PAM :-)
> 
> Do you want to use PAM in the sense of authorizing against the
> user accounts already on the system (which PAM supports) or 
> some arbitrary database of passwords (which PAM doesn't support)?

Well, I would have liked the latter. I don't know why PAM doesn't 
support it - it sure would have made that framework far more useful. 
(OK, one could write a patch that does it - PAM is open source after 
all. Call it UserPAM and make it a shared library for loading as a PHP 
extension... I'm not sure that this would appeal to administrators 
though. I certainly would be rather cautious unless there's at least a 
reasonable user base and a track record of having few security issue, 
but them I'm one of the more paranoid types around...)

I'm not sure that the former is worth the effort. It's sure a great time 
saver for those who have root access to the machine with their PmWiki 
installation (I do), but I'm not sure that the user base warrants the 
effort.
What mechanisms do you want to use? Does it need a PHP extension library 
- and, if yes, which one?

> If the former, that's very easy for me to add -- I'll probably code
> it up today.

Just make sure that the PAM service name is configurable! Many software 
packages mistakenly use a hardcoded service name, to the effect that 
only a single instance of that service can run on a machine.

Hmm... an alternative would be to include some installation-specific 
data in the service name. Something along the lines of

   "PmWiki$ScriptUrl"

On the plus side, that would make sure that every installation has a 
definitely-useful PAM service name. On the minus side, a service name 
like PmWiki/var/www/some.domain.tld/pmwiki/pmwiki.php it very ugly, and 
prevents moving around PmWiki directories.

Don't know what's best here...

>> A HTTP interface to any of these authorisation mechanisms would be 
>> helpful, but I'd first turn to webmin instead of PmWiki. If would
>> be a waste not to take advantage of their accumulated server
>> management and security expertise :-)
> 
> Yeah, the webmin-based solution ends up being the same as the PAM
> one.  I'll code it up.  One downside of this approach is that
> (currently) passwords would often be sent across the wires in 
> cleartext, which is bad for passwords that are also system logins.

Oh, anybody who uses webmin on a non-SSL connection is compromising his 
system anyway.

However, the beauty of shoving off responsibility is that, well, you 
aren't responsible. That's a Good Thing; having security-related code 
tends to have security-related bugs, which requires hotfixes and 
whatnot. To avoid that, it's better to stay away from security as far as 
possible (say, by just providing the interfaces and letting admins hook 
that up with the basic security framework of their server).

> We'd have to add a mechanism to allow PmWiki's passwords to be sent 
> via a secure connection, which PmWiki doesn't currently have but 
> can probably be added w/o too much trouble.

The initial attempt rarely is trouble, but security tends to become far 
more complicated than one would have thought initially. I am 
administering osCommerce installations, and typically 50% of all 
troubles are related to https in one or the other form. Typical problems 
include:

1. Not switching SSL on and off at the right time
    (i.e. not having a solid design which links should be https:
    and which should be http:).
2. Certificate installation in the server.
    One would think that this process is described in detail,
    but it's a complicated process and usually fails at first attempt.
3. Making sure that any included resources on an SSL-encrypted page
    (images and CSS) have an https: link. If they don't, browsers will
    complain that the page contains a mixture of secure and insecure
    resources.

Problems 1. and 3. can be eliminated by running the entire wiki under 
SSL. However, this is already covered by PmWiki - simply install it with 
http:// in $ScriptUrl and any other URL-related variables. Or configure 
the web server to redirect all non-SSL URLs to https:// ones.

For the security-minded, it would be worthwhile to write code into 
config.php that checks whether it's running under SSL, and terminate 
with an error message if it isn't. A Cookbook recipe could handle that 
(it may already exist, I dimly remember having seen somebody talking 
about the SSL_* variables needed for this kind of check - and most of 
the overhead is ensuring that the web server indeed provides these 
variables, the actual check-and-abort is a two-liner in PHP.)

Problem 2. is nothing that PmWiki can do anything about, so it's good 
enough as it is for that.


There is *one* reason to make PmWiki SSL-aware at the core: CPU load.

SSL generates considerable amounts of CPU load (I wouldn't be surprised 
if it doubled or tripled the CPU needed to generate a page). Many sites 
analyse which pages need encryption, and make sure that the remaining 
pages are delivered unencrypted. However, this requires considerable 
effort to avoid problems 1. and 3., both in design and in testing/debugging.
My experience with osCommerce was success on 1. and miserable failure on 
3. Problem 3. is particularly nasty since browsers usually don't tell 
you which URLs are at fault.
Problem 1. is nasty for PmWiki. Since there are many different 
environments in which PmWiki can be installed, each with special 
requirements about what to encrypt and what can stay in the clear, it 
would be quite difficult to set up a policy that suited all needs. The 
usualy way out of such a situation is "make everything configurable", 
but most web administrators have no experience (nor expertise) in 
setting up a security concept. Again, I arrive at the conclusion that 
SSL awareness for PmWiki is of dubious value.


Anyway. I guess the summary of this lengthy rambling is this:

By default, PmWiki will run under SSL just fine; security issues can be 
handled by the administrator, and don't place much of a burden on him 
that he doesn't already have.
Any move for making PmWiki SSL-aware is an optimisation with a lot of 
attached strings, not something that gives us new functionality. From 
this perspective, it seems that SSL awareness should take a back seat 
right now.


Just my 2c.

Regards,
Jo



More information about the pmwiki-users mailing list