If you need per-page or partial page access restrictions, you are advised to install an appropriate content management package. MediaWiki was not written to provide per-page access restrictions, and almost all hacks or patches promising to add them will likely have flaws somewhere, which could lead to exposure of confidential data. We are not responsible for anything being leaked.
For further details, see Security issues with authorization extensions
This extension is currently not actively maintained! Although it may still work, any bug reports or feature requests will more than likely be ignored.
Release status: unmaintained
|Implementation||Tag, Special page|
|Description||Protect areas and sections from access|
|Latest version||2.3b (2007-12-18)|
|MediaWiki||1.8.0 - 1.9.1|
|License||GNU General Public License 2.0 or later|
Welcome to the MediaWiki extension for protecting pages.
PageProtectionPlus (a.k.a PPP) has been created on the base called PageProtection written by Fabian Schmitt. If you are using PageProtection and you are interested why this is a branch and what are the differences please see further section called Why branch?.
The extension is implemented as parser and hook in AlternateEdit. You can have multiple protected and unprotected areas on a single article where only allowed users see the protected areas, all other users see the rest.
0. PHP 5
1. PEAR and PEAR/Crypt_RSA packages.
2. Additionally, you'll need one of these:
3. You also need cryptographic engine(s):
- PHP with libmcrypt – http://mcrypt.sourceforge.net (very okay to have it)
- Crypt_Blowfish – http://pear.php.net/package/Crypt_Blowfish (version 1.1.0RC1 or higher!)
4. Older MediaWiki installations may need ExtensionFunctions.php to be installed.
You can get more info in the Installation Guide
The whole code with installation guide is now available for download from the following locations:
How it works
This is a cryptographic engine used to protect articles and/or articles' sections of MediaWiki. It uses public-key cryptography combined with symmetric-key cryptography to achieve good safety/time factor. In order to work properly it needs RSA key pairs present in PEM files on the application server, which handles encryption and decryption.
When you edit a page
It encrypts sections of text in the articles just before they are put in to the database. To recognize parts which should be encrypted it looks for XML tag called 'protect'. Whenever it finds the opening tag it performs encryption of the text up to the closing tag.
When you read a page
It seeks for 'protect' XML tags and extracts information enclosed within them. It then checks whether a user is allowed to read a certain part of a text. If that is so, it runs decryption engine and replaces cryptograms with plain texts. To decrypt a cryptogram (an encrypted text in other words) it needs a valid RSA key pair present in the keys' heap - a directory containing PEM files.
This extension allows protecting single areas by spanning them with <protect>-tags. The tag has the following parameters:
- users – Comma-separated list of usernames who are allowed to read and edit the area.
- groups – Comma-separated list of groupnames who are allowed to read and edit the area.
- show – Defines, what to do when user has no access to the area. Possible Values:
- warning – Error-message with list of permissions.
- none – Nothing is displayed.
- crypt – Encrpyted text is shown.
- page – Page in "errorpage" is displayed.
- text – Protected text is displayed (the section is marked as readonly).
- errorpage – Page to be shown when show=page is set.
- cipher – Defines cipher to be used for encryption.
Valid ciphers can be found on specialpage called Special:PageProtectionCipherSuite.
- You can put 'rsa' string as a value, which will enable encryption of the whole text with the RSA public key without symmetric cipher in the middle layer. It is powerful, but very very slow (and not recommended for larger pages).
The text between the opening and closing 'protect'-tags will be hidden for users not in the specified lists. Members of 'sysop' always have access.
<protect users="admin1,admin2" groups="sysop"> Database-Settings ;Server : localhost ... </protect>
Why there is a directory for keys, not a one file?
It allows you to generate new RSA key and still be able to read pages encrypted by one of the keys used before. Keys are identified by their IDs (which are parts of fingerprints), so filenames doesn't matter.
There are two exceptions, where the names have matter.
- One is the name default.pem (or other set in $wgPEMfile). The file named like that should contain the default key used for encryption. If you'll change its name, the routine find it in other file and use it when decrypting pages previously encrypted using it. However, a new key pair will be generated for encryption and placed in the file saved under that name.
- Second exception is the name lite.pem (or other set in $wgPEMlite_file). The file named like that should contain the default key used for encryption by using so called 'Pure-RSA' method. If you'll change its name, the routine use it to decrypt pages previously encrypted with it, but a new key pair will be generated for Pure-RSA encryption and placed in the file saved under the name lite.pem or other set in $wgPEMlite_file.
Am I able to decrypt pages from PageProtection?
Yes, the PageProtectionPlus can decrypt pages encrypted using PageProtection.
Am I able to encrypt pages using RSA?
Yes. Pure-RSA is supported, but you won't be able to read the pages encrypted in that way under PageProtection (in case of downgrade, reinstall).
PageProtectionPlus is a branch, since it differs in the most common operations from PageProtection. It uses symmetric encryption for a text and RSA for encryption of randomly generated symmetric key delivered within a header preceding an encrypted text data.
Original PageProtection uses pure RSA encryption, which is strong but it fails with some requirements I needed to be enforced:
- The need of using strong RSA key (more than 2048 bits)
- The need to be able to exchange the default RSA key periodically
- The need that encryption/decryption should be performed fast
- The need that the editor can choose symmetric cipher
- RSA encrypts only the random, symmetric key (by default)
- Texts are encrypted using random, symmetric keys
- There is a key heap - directory containing all RSA keys that are in use
- Asymmetric keys (RSA) are identfied by their IDs
- Encrypted text sections keept in the database have headers
- Code for encryption/decryption is modular – you can adapt a new cipher engine in minutes
- Editor can decide, which symmetric algorithm will be used (the cipher attribute for the protect tag)
- Added i18n
- Added special page containing list of supported ciphers (Special:PageProtectionPlusCipherSuite)
- Texts are passed in binary format to the crypto-engines (base64 enc/dec and headers are handled by new classes)
- ProtectionParser class was forced to not repeat decryption for text areas where it was done already
- classes that are parsing tags were changed a bit to handle new attribute for the protect tag called 'cipher'
- On Xeon(TM) CPU 2.70GHz RSA-encryption of one page (7kB) has taken about 90 seconds before, and now using Blowfish+RSA it takes 3 seconds.
- Extension:PageProtectionPlus/Installation Guide
- Extension:PageProtectionPlus/Developer Notes
- Preventing access, native MediaWiki features.
- Magdalena Madeja, documentation reviews
- Zbigniew Sobiecki, RSA-fingerprints discussion
- Mike Dillon, important parser fix
- Maik Hentsche, important accesslist fix
- Tomek Kaczmarek (tolerance)
- Robert Grobelny (good mood)
- Marcin Gołuch (idea of preventing access in our wiki)
This extension is released under the terms of GPL version 2 or higher.
- Copyright (C) 2006, 2007 Pawel Wilk (pw at gnu.org)
- Portions Copyright (C) 2006, 2007 Fabian Schmitt (fs at u4m.de)