[pmwiki-users] questions about user authentication
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
>>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?)
>>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
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
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
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
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
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
Just my 2c.
More information about the pmwiki-users