MediaWiki was not designed to support per-page or partial-page access restrictions. If you require this level of control, you are strongly advised to use acontent management system that supports it natively. Patches or third-party extensions claiming to provide access control, when in use with MediaWiki, may not work in all cases, potentially exposing confidential data.Use them at your own risk.Neither the MediaWiki developers nor the Wikimedia Foundation are responsible for any data leaks that may result.This message is added to all extensions of this nature and may not reflect the actual security status of this extension. For more information, seeSecurity issues with authorization extensions. |
Release status: stable | |
|---|---|
| Implementation | Hook,Special page |
| Description | Page-level symmetric and asymmetric encryption in a dedicated namespace, completed with disposable access codes and access management |
| Author(s) | thomas-topway-it (thomas-topway-ittalk) |
| Latest version | 1.2.2 (2024-09-27) |
| Compatibility policy | Master maintains backward compatibility. |
| MediaWiki | 1.35+ |
| License | GNU General Public License 2.0 or later |
| Download | |
| |
| |
| Translate the PageEncryption extension if it is available at translatewiki.net | |
PageEncryption implements page-level symmetric and asymmetric encryption based onSodium andDefuse php-encryption library. It includes a special page by which to manage asymmetric keys or disposable access keys to grant registered or external users access to encrypted articles, and it works withWikiEditor in a transparent way (withVisualEditor is not yet guaranteed to work, see#Known issues section) within theEncrypted: namespace.
PageEncryption in yourextensions/ folder.wfLoadExtension('PageEncryption');
php maintenance/run.php update (this will create the necessary database tables that this extension needs)composer update --no-dev in the extension's folder, to install the required PHP libraries| PageEncryption does not perform client-side E2E encryption and therefore assumes that you trust the system administrator or the wiki is self hosted. Don't use this extension if you cannot check the integrity of the extension server-side, or the system administrator isn't legally bound not to tamper with it! |

PageEncryption provides an encrypted namespace (Encrypted:) where authorized users (users with rightpageencryption-can-manage-encryption) can create/edit protected articles.
The extension works in a transparent way, first requiring to set a global password to create the necessary keys stored on the server, and then setting a cookie with the user-key by which to encrypt/decrypt the articles in the relevant namespace.
The password and the user-key are never stored on the server and the symmetric and asymmetric keys can only be used in conjunction with the user-key, so there is no way for system administrators (unless the extension itself has been hacked before you set the key)to access your confidential articles/data. To learn more how it works take a look to the following:Encrypting account data with the user's login password, and the following:Modern PHP data Encryption/Decryption with Sodium extension.
PageEncryption is therefore an optimal solution when you agree with system administrators (or the wiki is self-hosted) to take all the possible measures to protect your data, and you want to safeguard them from possible attackers.
Besides the symmetric encryption used for personal use, PageEncryption allows to encrypt any article in theEncrypted: namespace with the public key of an user registered on the wiki (provided that they have been added to the group "pageencryption-recipient" and they have created a key-pair) in order to grant access to them on an individual basis. For this to work, the recipient must be added to the group "pageencryption-recipient" and they have to create their keys when entering the wiki.
PageEncryption also allows to set disposable access-codes/urls to provide external visitors with a secret code or url through which to access confidential articles. The secret code and url can be used only once and again they are not stored on the server. You can use them to grant a single access to the recipient of sensitive data ensuring that nobody else will get access to them: of course in this case it is the editor responsibility to provide the secret key or url only through trusted channels. (a future version of the extension will include an interface to enter the access code separately from the url, this way the url and the code can be sent to the recipient using separate channels)
Also note that all encrypted versions of an article/page are relative to a given revision, therefore external users (or registered users with public key) will be able to access only the specific revision encrypted at a given time, therefore as one might expect the method doesn't grant access to future revisions of the same article/page.
In order to encrypt articles either for personal use, or to securely share them with specific recipients, just create an article in theEncrypted: namespace as you would do with standard wiki articles. After setting the keys through the popup (it shows up automatically when needed), the article content will be encrypted/decrypted transparently as long as you are the editor.
The lock icon on the right informs that the article is encrypted.
The history can also be accessed seamlessly:
On the other side, this is how the article appears when accessed from unauthorized users (including wiki administrators/sysops)
Note that if you forget the PageEncryption password, or the protected key on the server will be lost, your articles cannot be recovered. |
If you want to grant to other users on the same wiki or to external users, access to an encrypted article, this can be done by the special page "Manage access" reachable either from the actions menu and the list of special pages.
Access can be granted in the following ways:
1) by creating an arbitrary number of disposable codes/url by which to grant to external visitors one-time access to them, also setting an expiration date for the access code/secret url
2) adding registered users to the "pageencryption-recipient" group (or assigning the "pageencryption-can-handle-encryption" right) and encrypting the article revision with their public key (once that they have entered the wiki after being added to the group)
Once the code/secret url is generated, you can provide it to your recipient through a secure channel (for instance by an encrypted chat message, sms, or secure email message) and the extension will record access time and other access-related information, if enabled.
By contrast, if you have granted access to the article using an asymmetric key (only for registered users who have created their keys) you can send them the url of the article and they will be able to access it in a transparent way after signing in to the wiki and by entering their PageEncryption password.
The extension creates the followinguser rights.
| right | description |
|---|---|
pageencryption-can-manage-encryption | Can manage encryption |
pageencryption-can-handle-encryption | Can handle encryption |
| group | pageencryption-can-manage-encryption | pageencryption-can-handle-encryption |
|---|---|---|
sysop | v | v |
bureaucrat | v | v |
pageencryption-admin | v | v |
pageencryption-recipient | x | v |
The extension redefines theRevisionStore andRevisionLookup services, and manipulates (i.e. encrypts/decrypts) theRevisionRecord as soon as it is retrieved from the database. Cache is disabled for theEncrypted namespace, andmakeAutoSummary onManual:Hooks/MultiContentSave is disabled as well. The extension does not manipulateEditPage throughManual:Hooks/AlternateEdit as one might expect in similar cases. (thanks to the mocked-up RevisionRecord handled at a lower level).
For professional support please write at the email address postedhere