[pmwiki-users] Problem with AuthUser

Patrick R. Michaud pmichaud at pobox.com
Tue Dec 6 16:05:33 CST 2005


On Tue, Dec 06, 2005 at 09:46:28PM +0100, Joachim Durchholz wrote:
> >This method has even worked well on sites consisting of hundreds of
> >authors (especially since authors are able to set their own passwords
> >and share them with trusted colleagues).
> 
> Um... I'm feeling uncomfortable with that :-)
> 
> As an author, I'd have to know all the passwords that were given to me, 
> and produce the right one for each page that I want to edit (or access). 
> This can become unmanageable quickly.

In my (limited) experience authors tend to cluster a fair bit, with 
very few instances where an author needs to participate across
independent groups.  What tends to happen is that the passwords are
simply re-used among a larger and larger community.

Also, PmWiki allows pages to have multiple passwords, so that
I can tell one group of authors one password and another group
a different one.

But ultimately, any claim that remembering passwords is too much of
a burden on authors fails to acknowledge reality, which is that
even account-based systems require people to remember all the
passwords they use and which ones apply where.  (There is possibly
an argument that account holders at least get to choose their own
passwords and thus would be more likely to remember them.  However, 
this is somewhat countered by the fact that any account holder who 
decides to use a common password among multiple sites/systems is 
actually reducing overall security, not increasing it.)

> Next thing is: I can't abstract with a password-based protection scheme. 
> With user accounts, I can create groups of users, and give that group 
> (say) read rights on a given group of pages.

Yes, it's possible to abstract -- just abstract based on multiple
passwords (where a "group" corresponds to "people who know the 'xyz'
password").

> And, lastly: with a password-based scheme, it's difficult to exclude 
> somebody. (Not a nice thing to happen, but sometimes it's necessary.) 

I've never run across this situation myself, so PmWikiPhilosophy #3 has 
applied for me here.  I'm not saying it doesn't or can't happen, just 
that access revocation seems to be pretty rare.  (In most of my
environments there have been other punishments, threats, or avenues 
available outside of the wiki for dealing with malcontents.)

But if I needed to exclude someone I'd just change the password and 
communicate the new one to the group (exclusive of the pariah).  
If that didn't work, *then* I'd see about going to an identity-based 
scheme, and then possibly only for the affected pages.  But just
because there's a chance of needing to exclude someone in the future
isn't sufficient for me to adopt identity-based management now,
especially since the identity-based approach can be added later
with little loss in continuity.

> For password-based auth, I'd have to change all the passwords that he 
> knew, and change them for all the pages that they were set on. As an 
> admin, I may not even know all the passwords; I'd have to tell everybody 
> that I'd recommend changing passwords because such-and-so got offended 
> on that particular PmWiki site and may return as a vandal.
> With account-based auth, it's no problem to delete (or at least lock) 
> the account.

I don't disagree at all with any of the above analysis, but I think we 
often overlook the possibility of alternate avenues of enforcement that 
don't require technical measures.  At the University, site vandalism 
would be against the student or employee codes of conduct and would 
quickly result in suspension of computer privileges, loss of course
credit, and even expulsion from the University.  In the research
institutes, such actions would've been grounds for dismissal.

And although we can delete or lock an account, a dedicated vandal will
simply switch to other attack vectors, such as compromising or obtaining
another account for mischief.  So, deleting or locking a vandal's
account is still only the beginning of a solution, and not a complete
one.

> At least that's the reasoning why I'm generally in favor of 
> account-based auth. I'd be curious to hear how you're handling these 
> issues with password-based auth; I've always loved opportunities to 
> learn :-)

My ultimate answer is that I haven't had to handle these issues with
password-based auth because they've never arisen for me, or when they
have come up I've always had another (external and/or often superior) 
avenue available for dealing with the issue that didn't require 
revoking the simple password scheme.  Maybe I'm just really lucky, 
but I've been doing systems like this for over five years in some 
fairly public contexts and it's worked out okay so far.

There's one last point I need to make here, which is that if the
environment I'm in already has a mechanism available for identity
management and password recovery (e.g., an Active Directory Server,
LDAP server, MySQL database, etc.), then I would almost always use 
that in preference to the simple password-based scheme.  In such an
environment the issues of account maintenance are already being
handled, so that identity-based authorization actually becomes
simpler than password-based for both the wiki admin and any page
authors.  (This is also why I've been fairly insistent that AuthUser
be able to support multiple authentication sources.)

Pm




More information about the pmwiki-users mailing list