Release status: beta
|Implementation||Hook, Special page|
|Description||Page level encryption based on defuse/php-encryption and OOUI|
|Latest version||1.0 (2023-06-15)|
|Compatibility policy||Master maintains backward compatibility.|
|License||GNU General Public License 2.0 or later|
|Quarterly downloads||3 (Ranked 155th)|
|Translate the PageEncryption extension if it is available at translatewiki.net|
PageEncryption implements symmetric, page level encryption based on the php-encryption library. It includes a special page where to manage disposable access keys to grant external users one-time access to confidential data, and it works with WikiEditor in a transparent way (with VisualEditor is not yet guaranteed to work, see #Known issues section) for the
- Download and place the file(s) in a directory called
- Add the following code at the bottom of your LocalSettings.php
<!-- place after the registration of other extensions!! --> wfLoadExtension( 'PageEncryption' );
php maintenance/update.php(this will create the necessary database tables that this extension needs)
composer update --no-devin the extension's folder, to install the required PHP libraries
- Done – Navigate to Special:Version on your wiki to verify that the extension is successfully installed.
PageEncryption enables an encrypted namespace (
Encrypted:) where authorized users (users with right
pageencryption-cancreateencryption, by default set to all registered users) can create/edit protected articles.
The extension works in a transparent way, first requiring to set a global password to lock a password-protected key 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 key can only be used in conjunction with the user-key, so there is no way for system administrators (unless the extension itself has not 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.
PageEncryption is therefore an optimal solution when you agree with systems 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 editor-relative global symmetric key, PageEncryption also allows to set disposable access-codes to provide external visitors with a secret code or url through which to access confidential data. 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. (currently there isn't yet an interface to enter the secret code, although this is the most secure method, because it allows to send the url of the document and the code through separate channels ‐ so please rely on the secret-url until the first stable release)
Still in the first stable release of the extension, PageEncryption is planned to feature an asymmetric mode as well, by which users registered on the wiki can access confidential articles/pages an arbitrary number of times (technically, as it is known, the extension will create a private/public key pair for registered users and then will encrypt a given page revision using their public key).
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 using the key which is then given to them, therefore as one might expect the method doesn't grant access to future revisions of the same article/page.
In order to register a global symmetric key, just go in the
Encrypted: namespace, and create/edit an article (you must be the article unique editor in order for this to work). A popup appears and you can set your global password.
As mentioned, the global password, used to create an userkey only stored client-side, is never stored on the server.
(when you logout or the cookie is deleted, the global password must be re-entered again, in order to create the same user-key to encrypt/decrypt pages/articles, however note that if either the password or the protected-key (registered on the server) are lost, encrypted pages/articles cannot be recovered. For this reason the first stable release will also include a step where users can save the created protected-key locally).
As long as you are the editor of a protected article, you can read/edit it seamlessly.
including the history
Manage access keys
For each protected article/page of which you are the editor, you can create an arbitrary number of disposable codes by which to grant to external visitors one-time access to them, also setting an expiration date for the access code/secret url. Conversely to the global password, the generated secret key is stored server-side in an encrypted format (although this might change in future versions of the extension) so you can retrieve them easily (through your global password) at a later time, without prejudice to safety.
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.
Note in general the secret-url is only conceived to encourage external users to sign-in to the wiki and to access the protected articles addressed to them on a regular basis using an asymmetric method
How it works
The extension redefines the RevisionStore and RevisionLookup services, and manipulates (i.e. encrypts/decrypts) the RevisionRecord as soon as it is retrieved from the database. Cache is disabled for the
Encrypted namespace, and
makeAutoSummary on Manual:Hooks/MultiContentSave is disabled as well. The extension does not manipulate
EditPage through Manual:Hooks/AlternateEdit as one might expect in similar cases. (thanks to the mocked-up RevisionRecord handled at a lower level).
- VisualEditor might not work correctly on certain installations (the author hasn't yet enough data about that, so in case please report the issue in the Extension_talk:PageEncryption talk page.)
- simple form/UI by which to enter an access code (instead than just using the secret url)
- asymmetric encryption for registered users
- encrypt/decrypt uploaded images seamlessly