Feature Proposal: User home pages should not be write-protected

Motivation

Locking down user home pages was added to DakarRelease. It is a requirement to work around the issue of sending password reminders.

This is bad for several reasons:

• A typical TWiki installation behind firewall (TWikiMission) uses external authentication (LDAP, NIS etc) where password reminders are not applicable
• It sends the wrong message. Wiki collaboration needs to be open for all. Locking down ones home page brings us back to the database world with tight access control, which is the opposite of free form wiki collaboration. Lets remove that mental barrier to collaboration
• Other users can't fix typos on user home pages
• Other users can't send a message to another user (barn star etc)

-- PeterThoeny - 10 Oct 2005

i think thats a crap option. locking user topics is not-wiki - see the converstaions that occur on c2.com on user topics. a better option might be to store wikiName - email info somewhere else (in a registration only topic / data file. but thats not great either, just better than de-wiki-ing user topics.

eg

• can you edit GrantBow's topic to inform people of his gone-ness?
• can WillNorris fix my spelling mistakes on my topic if he sees them? (thanks Will smile

-- SvenDowideit - 16 Dec 2003

Impact and Available Solutions

Possible solution is to store e-mail addresses internally in TWiki (and keep the e-mail in the user home page). Whenever a user saves his/her own topic the internal address gets updated (and ignored if someone else changes the e-mail address)

Documentation

Examples

Implementation

---

Discussion

I am carrying over the constructive part of the discussion from Bugs:Item593.

-- PeterThoeny - 10 Oct 2005

• RegisterCgiScriptRewrite described this issue.
• RegistrationAsPlugin detailed a proposal

-- MC

If I recall correctly, we discussed to add the e-mail address to the wite protected TWikiUsers topic, e.g.

• SomeUser - somelogin - someuser@somwherePLEASENOSPAM.org - 05 Oct 2005

-- PTh

In retrospect might be better to have them completely invisible, as it is too easy to filter out the spam filter.

However, now we have the UserList topics does anyone except the administrator need access to view TWikiUsers?

We do need to ensure the login name is viewable by the user, but that might be better as a lookup displayed on the user's home page.

-- MC

I understand the points made, and don't like locking down home pages, but I can't see us coming up with an alternative in the immediate future.

-- CC

i also do not like home pages being locked down by default. as previously stated, it's not very wiki-like. otoh, it's not as if home pages have been promoted very heavily for the purpose of communication (like on usemod.com et al); rather, it's more about configuration settings. so there is some tension here as to what they're supposed to do.

-- WN

Anything that helps fix this collaboration issue should be done. This design issue could be a reason to delay the Dakar release if nobody is actioning on it.

-- PTh

I would like to brainstorm on a workaround for DakarRelease. How about this: The configure has a new switch to disable password reminders by e-mail. This makes sense for default TWiki installations that rely on external authentication (LDAP, NIS, AD, Kerberos). With the disable switch on, the write protection of user home pages can safely be removed. This is a simple solution that requires minimal code changes.

-- PeterThoeny - 10 Oct 2005

oh, how things change, and how things stay the same I still see locking home pages as a 'crap option'. But the trips around public TWiki's that i've done due to the security alerts has made me decide that we should lock everything down by default . From that default, TWiki administrators can open up as much as they feel able to take care of.

As to the 'nobody is actioning it' bit - its honestly not useful to delay for something that is unactioned. That would mean we'd never release - Develop, and thus Dakar is based on the prinicpal that if its important enough, it is being actioned, and if there's no-one actioning it, then obviously no-one sees it as important enough to them.

So. If you think its important, write some code, write some docco, do.

• Hmm, I aleady work several hours a day for the open source TWiki community, including weekends. Are you suggesting that I should do even more? I rather delegate and let the actual contributors and experts fix the issues. -- PeterThoeny - 10 Oct 2005

-- SvenDowideit - 10 Oct 2005

Regarding PTh's idea for a new configure switch: I'd second that as a workaround, especially because we already have a suitable switch for that: $cfg{PasswordManager}. If set to 'none', TWiki doesn't do any password management. What could be done to improve things is passing this variable to the templates so that they can react to it similar to the ALLOWLOGINNAME -> LoginName handling in TWikiRegistration (Dakar's version, of course). I'll try to collect some patches.

However, what I'd actually like to have is a separate configure switch or maybe a TWiki preference controlling exactly that feature: should changes to user's home page be initially restricted to their owner? But this should be treated as a feature request....

-- HaraldJoerg - 10 Oct 2005

I very much object to PeterThoeny's use of the phrase "a typical TWiki installation" and then claiming it is an intranet installation.

A simple search of Google shows many hundreds of Internet based implementations of TWiki.

• This is based on the focus we defined a long time ago in the TWikiMission. I wholeheartedly support the use of Internet based TWikis, they are vital to the success of TWiki (last but not least for publicity and Google ranking). But without focus we'd end up just as "yet another Wiki" in the marketplace. A good proxy on actual use is the TWikiInstallation directory. -- PeterThoeny - 10 Oct 2005
  • That's a nice listing but its WRONG. Filtering for "internet" at TWikiInstallation and visiting the sites shows that many of them are either unavailable or are not longer using TWiki. There is not simple way apart from contacting the staffers to determine if TWiki is still being used behind the firewalls listed. Its seems to be a 'write once but don't verify or update' topic and cannot be considered authitative. I'm sorry, Peter, I consider a Google search to be more up to date.
  • Focus should be based on function and corporate value, not on which side of the firewall the wiki runs. What makes TWiki distinctive is that it is an application builder - even without sophistocated plugins. It should be able to stand on that merit alone. -- AJA

-- AntonAylward - 10 Oct 2005

Having the home pages editable is a security risk

Assumption: The policy of the wiki is that postings are 'accountable', that is the identity of the poster can be determined. This is I post something but sign it "PeterThoeny" the logs and RCS show who really made that change. This assumption does not in any way mean that anonymous (guest) postings are excluded. This assumption is essential in many corporate settings.

IF there is the ability to request a new password by means of an automated mechanism (as there is with Dakar) AND user home pages are not protected THEN an attack mode exists:

• look at TWikiAdminGroup to determine the identity of a member of the admin group
• a guest, edit that person's home page to change the e-mail address to that of a throw-away account at gmail/hotmail/yahoomail owned by the atatcker
• request a new password for that person to be sent by mail to the throw-away address
• retreive the password and log in
• reset the e-mail address
• now, with admin rights, perform various nefarious activities. Do even more if TwikiShell is installed.

At present in Dakar, the password generation and reset is handled by the main body of Register.pm. Rather than merely having a switch in configure, ALL of the password and authentication (but not the authorization) mechanism should be migrated out of the body of Register.pm and into the LoginManager code.

-- AntonAylward - 10 Oct 2005

Good point Anton. A public site with the existing code base is vulnarable if the user home pages are not locked down.

• The above sequence applies also to the Dakar code base. It is making the home pages writable only by the owner that is the solution and it applies to both Dakar and Cairo.
• It also applies to intranet (i.e. non-public) sites as well. Its well established that many hacks come from disgruntled employees. As I say above, corect attribution is important in corporate intranet settigns as well. -- AJA

Lets focus on what can be done with the limited time we have for Dakar.

• What can be done is include in the setup documentaiton a note telling the installer that home pages aer protected by defualt - as they should be, sicne security should allways be shipped turned "on" - and instructions with how to turn it off. Not changes to the code base or the NewUSerTemplate needed. (Which is a moot point since many sites both 'internal' and 'external' are going to edit their registration forms and user templates anyway! -- AJA

-- PeterThoeny - 10 Oct 2005

I just realize that upgrading TWiki.org to Dakar will bring a nightmare in maintenance. Assuming we will lock down 18K user home pages (is there a script?), we will get many reports of not being able to edit one's home page. It is very likely that many people have an outdated e-mail address in the home page. FWIW, I currently get around 5 requests a week to reset the password.

-- PeterThoeny - 10 Oct 2005

yes, but i'm sooo much happier to create a maintainence nightmare than continue to leave known security issues. and really, the wikipedia experience shows, that many hand make light work.

btw - I have a huge objection to the idea that you delegate anything. TWiki and open source is not about demanding, or even asking for anything. its all about creating interest in things.

-- SvenDowideit - 10 Oct 2005

May be delegation is the wrong word, although some voices in the community say that I do not delegate enough.

I am all for nurturing a fun place for contributions as we have seen in many places, such as the explosion in Plugins after introducing the Plugins API.

So, on the maintenance nightmare, is it me who is supposed to pick up the additional work on TWiki.org?

-- PeterThoeny - 10 Oct 2005

How about a BeforeSaveHandler in the Main web that says no one except the home page owner/admin can change the topic when an @ sign is inserted in the text.

Its crap but 1) it could be a plugin 2) it might be quick to implement.

Would it work?

M.

-- MartinCleaver - 11 Oct 2005

Wouldn't that mean that other users cannot edit the home page? Back to the same issue as ALLOWTOPICCHANGE.

-- PeterThoeny - 11 Oct 2005

I mean that any other user's edits would be filtered to ensure they could not type an @ sign. They could make any change as long as it did not include an @. In fact, given that emails are stored in the Meta data we could discard any changes another user made to Meta data.

Or translate it some way, for example changing @ signs to an HTML hex entity.

-- MartinCleaver - 11 Oct 2005

Who is investigating this?

-- MartinCleaver - 21 Oct 2005

Well, "investigate" may be a bit high, but I've taken a closer look at the code when customizing TWiki for my employer's corporate intranet. And I have some years experience in writing user management software, authentication schemes in particular.

I am optimistic that it isn't too difficult to completely and securely remove write protection for user home pages in many circumstances, in particular those mentioned by PTh at the beginning of this topic: "A typical TWiki installation behind firewall (TWikiMission) uses external authentication (LDAP, NIS etc)"

I've such a setup up and running in my company and could try to suggest a patch against Dakar which is compatible with TemplateLogin and HtPasswdUser.pm / ApacheHtPasswdUser.pm as well - it's only that my recent suggestions in that direction did not draw any comments. It looks like everyone else needs a solution for TemplateLogin. So maybe my installation is the only "typical" one around....

-- HaraldJoerg - 25 Oct 2005

Great - I look forward to your evaluation...

-- MartinCleaver - 25 Oct 2005

Ok, here's a first patch. However, I don't think it will stop here.... but maybe it's better to take one step at a time.

Here's what it does:

• On registration, only ask for a password if there's a PasswordManager configured in TWiki. If you are using LDAP or NIS (or NTLM or Kerberos), I guess that setting TWiki's PasswordManager to 'none' is the only sensible thing to do.
  • If you are using LDAP or NDIS you should be switching in an alternate PasswordManager which handles the appropriate interactions with those systems. In most cases password changes will be NOPs though you may choose to implement a redirect to a corporate password change service. You should never have the password manager set to 'none' unless you really mean "no passwords" CC
    • I beg to differ. "No passwords" is different from "no password management by TWiki". They are only identical if TWiki is your only way access to a server (as in internet TWikis). At work we have windows domains and manage our passwords by <CTRL>-<ALT>-<DEL>, there's no need to even try to duplicate that in TWiki, especially if you look at the background of this topic. In every case where the Apache server borrows from NTLM or Kerberos authentication, TWiki may well enough rely on that. And, to be honest, I'm waaaay to lazy to write an alternate PasswordManager. -- HaraldJoerg
  • This is achieved by adding one more entry to TWiki's constantTags hash, and by referencing this entry in TWikiRegistration.
    • That's the same trick as is already used for AllowLoginName in the same topic.
      • OK, makes sense - %REQUIREPASSWORD% CC
    • By the way: I wonder whether we should create a function %CFG{...}% which gives access to the whole configuration instead of increasing constantTags one by one....
      • No. That was a deliberate security decision. Making the config hash public is equivalent to dropping your trousers and saying "go on, take your best shot" CC
        • Agreed, though it has a smell of "security by obscurity". -- HaraldJoerg
• When creating the user's home page, check whether there's a password manager in place. If 'none', then we can avoid the write protection for the new home page because there is no password-induced security hazard.
  • In NewUserTemplate, I added a variable %WRITEABLEUSERHOMEPAGE% before the notorious Set ALLOWTOPICCHANGE phrase. If there is a password manager, this variable is empty, if the password manager is 'none', it is '#'.
    • Hmmm. Rather than trying to make the template conditional, it would be easier to do this from code, when the topic is first written. There is no way to make a "Set" conditional. CC
  • Unfortunately this can't be checked with an = IF{ }: Empty expression

= construct in NewUserTemplate, it has to be done explicitly in Register.pm.

• • • Right. CC
• If a TWiki admin wants to write protect or not to write protect user home pages regardless of the PasswordManager setting, she can do so by replacing %WRITEABLEUSERHOMEPAGE% in NewUserTemplate by either nothing or by '#'.
  • I don't think that will work. Set is parsed out of the topic a long time before any variable expansion is done, so your protecting variable will always block evaluation of the Set CC
    • I think this is a misunderstanding. If an admin explicitly writes #Set ALLOWTOPICCHANGE in NewUserTemplate then newly created user's homepages are initialized writeable from that point on, if an admin explicitly writes Set ALLOWTOPICCHANGE in NewUserTemplate, then they are protected. Of course this doesn't effect users who already have registered, but I suppose these users already have taken their decision whether they want the # or not. -- HaraldJoerg

I've not yet done automated tests, the rollback is a bit difficult (unregistering users, deleting htpasswd entries, ...).

• OK, please stick with it - automated tests are really important! CC
  • Sigh I know, I know.... On another topic I've found a pointer to CPAN:WWW::Mechanize::TWiki, I hope this will help out... -- HaraldJoerg

-- HaraldJoerg - 28 Oct 2005

Just rewinding a moment to requirements. The requirement is that a user's home page should be writable only by the user and by system admins.

• I thought it is excactly the other way around: TWiki had to introduce write protection for user homepages because of the trouble with password management, and people seem to be unhappy with that. Look at this topic's name.... -- HaraldJoerg

Writability of home pages should be controllable from a central place. Right? And this password manager approach is just a way of achieving that; there is no explicit requirement to make it dependent on the password manager, no?

OK, assuming that, isn't there a much simpler approach (for Dakar at least)?

1. In the WebPreferences in the Main web, add
   • Set ALLOWWEBCHANGE =
2. In Main.TheUser, add:
   • Set ALLOWTOPICCHANGE = TheUser

1 will prevent any user writing any topic in the Main web (it says "no one is allowed to change topics in this web"). 2 will override that restriction for TheUser for the Main.TheUser topic only, as topic controls are evaluated before web controls.

Isn't that what you wanted?

• Isn't that pretty much what I've got with Dakar? -- HaraldJoerg

-- CrawfordCurrie - 31 Oct 2005

Following up on SVen and Lavr's conversation on IRC.

Peter stated why he is unhappy with it:

1. A typical TWiki installation behind firewall (TWikiMission) uses external authentication (LDAP, NIS etc) where password reminders are not applicable
   • I don't think this is relevant CC
2. It sends the wrong message. Wiki collaboration needs to be open for all. Locking down ones home page brings us back to the database world with tight access control, which is the opposite of free form wiki collaboration. Lets remove that mental barrier to collaboration
   • Agreed. The reason for the lock-down was because TWiki stores secure information on a page that should be insecure for best collaboration. Users email addresses should not be stored on home pages; if they weren't, there would be no reason to lock down.
3. Other users can't fix typos on user home pages
   • duplicate of reason 2 CC
4. Other users can't send a message to another user (barn star etc)
   • duplicate of reason 2 CC

As I read it, there is really only one reason, and that is reason 2 above. IMHO that's actually a rather good reason to dislike it.

Mucking around with permissions on home pages is not going to solve this. The only sensible solution is to move email addresses out of user topics. Here is how this can be done:

1. move the handling of the email into the password handler
   • the default HtPasswdUser could simply look up a file that maps wikinames to emails. If there is no mapping in the file, it can fall back to the current method of looking in the user topic (with a BIG RED WARNING).
   • write an upgrade script to grep all the emails out of user topics and create the initial file from existing user topics
   • this actually makes much more sense for sites using other authentication methods, such as LDAP, where email is typically held on the LDAP server. I had exactly this problem - overriding TWiki email addresses - myself years ago....)
2. (the hard part) extend the registration code to support email change requests in the same way as password change requests
3. Revert to writable home topics

Arguably a lot of other user info should be moved out-of-band this way, but email is the only really important one.

I reckon this could all be done by someone familiar with the code, and who also writes tests, (e.g. MartinCleaver) in half a day.

[[CC}]

I have a fix that supports storage of emails in the PasswordManager. It defaults to the user topic if a valid email can't be found in the user db. For the HtPasswd password manager, The email addresses are stored in the "info" field in the .htpasswd file.

I can check this in, and then this problem will go away. However, I can't fully test it, because I can't send mail from my test installation. If someone is prepared to work with me to test it (via IRC), I would be happy to check it in.

Note that the Func::wikiToEmail API already supports this method of getting emails, so the impact on any plugin that uses that API will be zero. If any plugins don't use the API, then there may be trouble.

CC

Well my merlin.lavrsen.dk machine is all dedicated to testing so tell me how I can help testing.

You seem to have the right idea.

I agree 100% on what you say. The only reason for suggesting ALLOWTOPICCHANGE on user topic as short term is that I am afraid it cannot be made stable in one week. But we can give it a try.

Does your idea also include a method for the user or admin to change the email address? Not only at the registration.

-- KennethLavrsen - 20 Jan 2006

Yes. In the interests of KISS, the admin can only change it by editing the .htpasswd file. The user has an interactive page.

-- CrawfordCurrie - 21 Jan 2006

CC committed his patch to SVN (Bugs:1461) - thanks!- and the registration and change e-mail address procedures are updated. Those who can, please help out testing this.

-- SteffenPoulsen - 21 Jan 2006