[Pmwiki-users] Easily Hackable?

[H. Fox]

Patrick R. Michaud wrote:
> Another set of thoughts that occurred after I sent my previous message...
> 
> When evaluating the security of a system, one often has to
> evaluate the system's security in relation to the alternatives.
> Thus, KC's original post was:
> 
>      I  had  a non-profit client reject my proposal for implementing a wiki
>      because  they  heard wikis are "hackable" and are concerned because an
>      affiliate had porn and other stuff put onto their site.
> 
> If the non-profit client doesn't choose wiki, what will they choose
> as an alternative?  One very common alternative is hosting a web site
> on a commercial web-hosting provider, where the HTML pages are edited/
> authored locally and then uploaded to the server.

Actually I think PmWiki has advantages if they're doing it that way.

First, most, if not all commercial servers I've had experience with do 
not provide much protection from other users on the same server. 
(Protection for the server itself is another story.)

Fore example, I've seen database passwords stored in world-readable 
directories (previous discussion regarding DB passwords not 
withstanding).  Since PmWiki doesn't need to use a DBMS, this wouldn't 
be a problem.

Second, what is there to keep someone from taking advantage of PmWiki to 
rapidly develop their pages offline, then using SCP to publish them to 
the production server in the normal manner?

Essentially you could have wiki content in a read-only directory on the 
commercial server, couldn't you?  (I tried it, and it didn't work. 
"Cannot acquire lockfile" was the error message.  I'm sure it could be 
done, though.)

>>    1. If the admin decides to change the password to a group or page, he
>>       has to distribute that password to everyone who needs it.
> 
> This is true in traditional web publishing also--the web hosting
> account password usually has to be shared among the people responsible
> for maintaining the site.

And the password for publishing to the production site could be 
different from the passwords for editing content.  I believe that in 
large organizations the permission to publish rarely given to the 
authors; instead it's the responsibility of server administrators or a 
single author or subset of the authors.

The point is: permission to author and permission to publish can be 
separated if you are using PmWiki.

>>    2. Passwords  are  sent  to  the  server in plaintext.

Not necessarily.  If PmWiki doesn't have a "force into SSL mode" feature 
now, I'm sure it could be added in the future.  ;)

SquirrelMail has a plugin for this.

     [The Secure Login plugin] is a simple plugin to automatically
     turn on SSL security during login if it hasn't already
     been requested by the referring hyperlink or bookmark.

     Primarily this utility is intended to prevent plain text
     passwords and email contents being transmitted over the
     internet[...]

http://www.squirrelmail.org/plugin_view.php?id=61

Hagan