for revision history prior to 24 Nov 2004, see the topic TWikiSecurity, r1.9 and earlier

Old thoughts, circa 2000

Warning: Can't find topic Main.PrivateButNotTOOPrivate

---

Edit the topic

---

---

This is the PrivateButNotTOOPrivate topic, replicated. It's replicated because kk thought it was relevant to more than the Codev group, and occasionally the Main web gets some use by non-devs; they might weigh in. It orginates there because if non-devs stay in Main to edit they won't be just dumped into Codev.

-- KevinKinnell - 11 Jun 2000

I'm guessing that the flow of edits for Main and Codev webs must have changed since then. This is a wonderful fundamental issue.

-- GrantBow - 09 Jan 2003

I find it amazing. I've been contributing on TWiki.org for over two years and have never read those articles. I tend to not read Main, and only use the TWiki web for reference purposes.

I'd suggest that those articles are moved into Codev, but I don't think anyone will do it.

-- MartinCleaver - 09 Jan 2003

I also found some interesting pages in Main web, also by pure accident. That is why I asked (in RenameMainWebToHome -- RenameTheMainWeb ) to separate Main and User webs. Especially in a site like TWiki.org, with many hundreds of registered users, and many new coming daily, anything other than user in Main web is almost completely and totaly lost for human race , IMHO.

-- PeterMasiar - 10 Jan 2003

---

---

New thoughts for 2004/2005

About TWiki and Security

TWiki's security mechanisms prevent idle shenanigans and petty abuse. Twiki is not, and is not designed to be, "secure". You can lock the doors and windows but there is no deadbolt. By far and away, this level of security is sufficient, twiki.org in operation since 1999(?) after all has not yet been comprimised[*] using any of these vulnerabilities. With that in mind, there a few things the new administrator should be aware of (not a comprehensive list).

[*] in any manner that reveals the exploit. A cracker who was discreet could do all number of things without revealing their presence.

SourceForge

Any twiki hosted on sourceforge has their data and pub filesystem available to be read (but not modofied) by any registered SF developer, which probably means a hundred thousand individuals, at least.

More details in SourceForgeAllowsHtpasswdRead

---

Other known security threats moved to KnownIssuesOfTWiki.

---

Discussion

These known security hazards are compiled mostly from my memory garnered through having been an active twiki.org member over the last few years. None of them or new or have not been discussed before. Some of them may have been addressed within the last year (CairoRelease) -- please correct and update as necessary. Thanks.

I was unaware of the existence of this older topic when I started this. There is some good info and background which should be refactored.

-- MattWilkie 07-Nov-2004

One of the major problems I repeatedly encounter in my profession as a security auditor and which I see inherent in much of TWiki's approach to security is a confusion between the three key elements:

• Identification
• Authentication
• Authorization

But to its credit, at least Twiki tries to address these.

The big confusion, which is common in many other systems, not least of all the major operating systems, is between identification and authentication. The identity is not even accepted until it is authenticated by some login procedure.

We see this confusion creeping in when the SessionPlugin is not used. The user appears to be TWikiGuest even after logging in.

Does this need to be fixed? Yes and no. It does need to be "fixed" in the minds of any developers who work with the security model. It does need to be "fixed" by the use of something like SessionPlugin where applicable.

But the fix I'd really like to see is to the menu bars - the ones at the top and botton of the page body in Pattern skin - the field that says 'Edit'. If the user can't edit the topic don't tell him he can!

Of course this gets back to the "who you are when not editing, are you really TwikiGuest" problem.

-- AntonAylward - 07 Nov 2004

The suggestion from PeterMasiar - 10 Jan 2003 - is a good one. What is in Main that we must protect from user's modifying? We DO want them to modify their own pages, so we can't strap down the whole of Main as modifyable only by the TWikiAdminGroup, which it rally needs to be. Similarly, the TWiki web needs to be strapped down on "production systems".

This is not a problem with TWiki's access control mechanisms, which are adequate for this. It is a problem with the what goes where. As %MAINWEB.PeterMasiar points out, a User web - like the Home file system in UNIX, makes good sense.

-- AntonAylward - 07 Nov 2004