Hello all,
As we know, one of the most commonly requested features is per-page protection / ACLs. That's obviously problematic[1] because MW was never designed for this.
However, what if the respective wiki page's contents were en- and decrypted (e.g. with JavaScript[2])?
As far as I can tell, that would circumvent the most common problems (like transclusion workarounds).
(I just had this idea when looking at the TiddlerEncryptionPlugin[3] for TiddlyWiki[4] - so it might not be well thought through!?)
Any comments?
-- F.
[1] cf. http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions
[2] Relying on client-side functionality would be somewhat problematic, obviously - but not really a huge issue, especially if it only affects a few sensitive pages. Plus in corporate intranets, where per-page restrictions are probably needed most, there should be a pretty homogeneous environment, which makes it easy to ensure that JavaScript is available.
[3] http://tinyurl.com/23g65m (http://remotely-helpful.com/TiddlyWiki/TiddlerEncryptionPlugin.html#TiddlerE...)
However, what if the respective wiki page's contents were en- and decrypted (e.g. with JavaScript[2])?
What's your plan for communicating keys? You are likely to just move the security issues from the articles themselves to the keys, which isn't a great improvement.
What's your plan for communicating keys? You are likely to just move the security issues from the articles themselves to the keys, which isn't a great improvement.
I'm not entirely sure what you mean...
For starters, I was thinking of having the user choose any custom key or "password" (as long as the page is not encrypted already, of course), so you would actually have to type in that password and reload the page to decrypt.
Communicating those keys to the authorized people would be a bit cumbersome, of course - so in later (post-proof-of-concept) versions, you might have user groups, so the encryption would take place automatically.
Again, this is just a silly idea (not even a concept) for now - I was simply inspired by that TiddlyWiki plugin.
-- F.
On 15/08/07, Frederik Dohr fdg001@gmx.net wrote:
What's your plan for communicating keys? You are likely to just move the security issues from the articles themselves to the keys, which isn't a great improvement.
I'm not entirely sure what you mean...
For starters, I was thinking of having the user choose any custom key or "password" (as long as the page is not encrypted already, of course), so you would actually have to type in that password and reload the page to decrypt.
Communicating those keys to the authorized people would be a bit cumbersome, of course - so in later (post-proof-of-concept) versions, you might have user groups, so the encryption would take place automatically.
Communicating the keys to the authorised people is exactly what I'm talking about. Even with user groups, if the decryption is taking place client-side (which is what you're suggesting with Javascript), the key needs to be transferred somehow. If you have way of working out who to send the key to, you could just use the same system to send the page itself and not worry about encryption.
Communicating the keys to the authorised people is exactly what I'm talking about.
In a public, decentralized wiki, that would certainly be a problem. In a corporate environment (where this is be needed most) though, it would "only" be cumbersome.
Even with user groups, if the decryption is taking place client-side (which is what you're suggesting with Javascript), the key needs to be transferred somehow.
True. So, what if we move away from the client-side en-/decryption and insert a step in between retrieving the page contents from the database and sending it to the client: 1. retrieve page contents 2. retrieve password* (blank by default) 3. decrypt contents with password (no check whether it worked) 4. send decrypted page * either via user groups, or with a simple input field for the password
Hmm ... so I guess having user groups might not be feasible after all. But for crude (but simple and workaround-proof) protection, client-side en-/decryption would work!? (Though things like link analysis, job running, transclusion etc. would obviously not be possible... )
-- F.
In a public, decentralized wiki, that would certainly be a problem. In a corporate environment (where this is be needed most) though, it would "only" be cumbersome.
Yes, it would probably be doable in a corporate environment, however I imagine there are better ways of doing it than a wiki with a cumbersome encryption system hacked on. Is there any great need for the restricted pages to be alongside the unrestricted ones? Put them on a password protected server and be done with it.
Yes, it would probably be doable in a corporate environment, however I imagine there are better ways of doing it
Well, I haven't come across any so far; I haven't tried all of the security extensions, but that's mainly because it seems that they all are vulnerable to workarounds.
Only the PageSecurity extension seems to be truly secure. But that one's cumbersone to set up and, more importantly, not easy to use - plus it doesn't seem to be actively maintained anymore (no update for MW 1.10).
Is there any great need for the restricted pages to be alongside the unrestricted ones? Put them on a password protected server and be done with it.
You mean set up a separate wiki for every single group (say, one for "confidential", one for "secret", and a third for "top secret")? Or maybe there is a way to use .htaccess for this ... although, that would be very vulnerable to transclusion workarounds!?
-- F.
I was thinking of using .htaccess for this myself, with a pattern match. So e.g. something like the pseudocode
<LocationMatch "Key"> <LIMIT GET PUT> require user me </LIMIT> </LocationMatch>
would only allow access to pages with Key in their name to me.
What do you mean by transclusion workarounds?
Oliver
On 15 Aug 2007, at 14:14, Frederik Dohr wrote:
Is there any great need for the restricted pages to be alongside the unrestricted ones? Put them on a password protected server and be done with it.
You mean set up a separate wiki for every single group (say, one for "confidential", one for "secret", and a third for "top secret")? Or maybe there is a way to use .htaccess for this ... although, that would be very vulnerable to transclusion workarounds!?
oliver@gtwm.co.uk / 0845 456 1810 / 07814 828608 The Old Bank, 4 Ravenhill Rd, Swansea SA5 5AW, UK
NOTE No contracts may be concluded on behalf of GT webMarque by means of e- mail communications. The contents of this e-mail are confidential to the intended recipient at the e-mail address to which it has been addressed; it may not be disclosed to or used by anyone other than this addressee, nor may it be copied in any way. If received in error please return to sender via e-mail.
DISCLAIMER Please note that neither GT webMarque Ltd nor the sender accept any responsibility for viruses transmitted via e-mail. It is your responsibility to scan attachments (if any).
What do you mean by transclusion workarounds?
Well, imagine you try to protect [[secret:WorldDomination]]. You couldn't directly access that site, because Apache would recognize the URL. However, you could still access the contents of that page by adding the following to any non-restricted page: {{secret:WorldDomination}} - here MW would simply pull the contents of that protected page from the database and include it in the non-restricted page.
-- F.
Ah, I see. And there's no way to turn transcluding off? I can't find a configuration setting for it.
On 15 Aug 2007, at 14:59, Frederik Dohr wrote:
What do you mean by transclusion workarounds?
Well, imagine you try to protect [[secret:WorldDomination]]. You couldn't directly access that site, because Apache would recognize the URL. However, you could still access the contents of that page by adding the following to any non-restricted page: {{secret:WorldDomination}} - here MW would simply pull the contents of that protected page from the database and include it in the non-restricted page.
-- F.
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
!DSPAM:505,46c306e897651572219304!
oliver@gtwm.co.uk / 0845 456 1810 / 07814 828608 The Old Bank, 4 Ravenhill Rd, Swansea SA5 5AW, UK
NOTE No contracts may be concluded on behalf of GT webMarque by means of e- mail communications. The contents of this e-mail are confidential to the intended recipient at the e-mail address to which it has been addressed; it may not be disclosed to or used by anyone other than this addressee, nor may it be copied in any way. If received in error please return to sender via e-mail.
DISCLAIMER Please note that neither GT webMarque Ltd nor the sender accept any responsibility for viruses transmitted via e-mail. It is your responsibility to scan attachments (if any).
Ah, I see. And there's no way to turn transcluding off? I can't find a configuration setting for it.
Turning transclusion off entirely would be a bad idea, as it's one of MW's most powerful features.
However, there's $wgNonincludableNamespaces (MW v1.10+): http://www.mediawiki.org/wiki/Manual:%24wgNonincludableNamespaces
-- F.
However, there's $wgNonincludableNamespaces (MW v1.10+): http://www.mediawiki.org/wiki/Manual:%24wgNonincludableNamespaces
Note that there might still be other risks with that .htaccess approach: http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions
Nevertheless, I'd be interested in a quick to tutorial on how to set this up.
-- F.
Another of MW's most powerful features (shared with all wikis AFAIK) is the ability to create new pages from links. I've always felt that this was the real downfall of page-by-page security... users will unintentionally create unprotected pages. But I think we've had this conversation before, months ago!
Jim
On Aug 15, 2007, at 9:33 AM, Frederik Dohr wrote:
Ah, I see. And there's no way to turn transcluding off? I can't find a configuration setting for it.
Turning transclusion off entirely would be a bad idea, as it's one of MW's most powerful features.
However, there's $wgNonincludableNamespaces (MW v1.10+): http://www.mediawiki.org/wiki/Manual:%24wgNonincludableNamespaces
-- F.
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
mediawiki-l@lists.wikimedia.org