• View
• Edit
• History
• Print
• Backlinks

PageFileFormat-Talk

Page data is not encrypted inside page files

As far as I know, nothing prevents someone from using "grep" or other tools from searching
for data inside page files. Can the PmWiki program setup a method to encrypt/decrypt page file data? gnuzoo June 27, 2024, at 04:21 PM

If an attacker has access to the disk files, it is game over. If you store the encryption password on the disk, the attacker could "grep" for it. If you type the password when you access or edit a page (and save it say in a cookie), the attacker could modify local scripts to retrieve it. In addition, the wiki would be unreadable for visitors who don't know the password. These recipes claim to do this, and they are not immune to an attacker with access to the disk:

You could use a browser-based extension that encrypts and decrypts a portion of the page on the browser not on the server, without ever sending the password to the server. (The wiki search would not work.) However with access to the disk files, the attacker could add a JavaScript that captures your key presses, or reads the edit form or the page text after it is decrypted so again game over.

Using encodings such as base64 or rot13 without a password, or Cookbook:CompressedPageStore, would prevent `grep` from finding the text, but an attacker with access to the disk files can just read the logic and use it to extract the text, so again game over. --Petko June 27, 2024, at 05:08 PM

EditCrypt uses PHP MCRYPT which is deprecated - see PHP mcrypt gnuzoo June 27, 2024, at 06:59 PM

WikiSh - Peter Bowers abandoned this prerequisite for WikiShCrypt and it is not maintained. I think if might likely not work at all - and even be dangerous to try. gnuzoo June 27, 2024, at 06:48 PM

None of these, even if maintained, or any other anyone creates, will work if as you postulated an attacker has access to the disk files. --Petko June 27, 2024, at 07:00 PM

Let me shorten that - "None of these will work".
Another way someone might get access to the disk files is from a backup. Someone copies files from a secure area to non-secure for a backup. Whoops!
If they have access to files, they still would have to decrypt them to get the content of the text. Most people would not be capable of doing this.
No, you would not use this to protect top secret nuclear weapon technology, but it does help keep honest people honest. PmWiki went to great lengths
to have passwords, but not page encryption. Passwords are pretty easy to break, so why bother even using them? Oh, perhaps they are better than not having them.
This is my feature request to add an opt in for an admin password for page store encryption. gnuzoo June 27, 2024, at 07:49 PM

Cookbook:CompressedPageStore appears to be similar to what I am looking for, but gzip is not really 'encrypted' gnuzoo June 27, 2024, at 09:27 PM

Considering your earlier comment about PmWiki able to run on older PHP versions, I'm surprised you feel PmWiki should tell people "Your pages are safely encrypted" when they are not, and when there is no secure way to implement it. To your point about an attacker accessing your backups, I'd better just use standard encrypted backups instead.

Obviously, we can't stop anyone from writing a recipe, and nothing in the core prevents from doing that, but it may be misleading and unsafe, a false sense of security. I wish we had a wiki-marketplace where people like you could request new features and how much $/€ would implementation, documentation, maintenance, and support be worth to you, and developers who agree on the $/€ for their work, could implement these as cookbook recipes, document them, maintain them, and support them. --Petko June 28, 2024, at 08:01 AM

Design choice

> I regret
> all history and metadata are kept in the same files in pmwiki, I
> also guess it might impact a bit the performance if it loads the
> whole data when reading the content of the files, but I may be wrong
> on this point.

Data and history data in PmWiki's files are always stored 
most-recent-first, so PmWiki almost never has to read the entire
data file except when editing a page or displaying history.
When simply reading or scanning a page, PmWiki will stop reading
the file as soon as the first history entry is found.

Storing data and metadata in a single file was a very conscious 
design choice in PmWiki -- I wanted pages to be well encapsulated
and didn't want to ever have to worry about them getting out-of-sync.
Keeping them separate is also a perfectly valid design choice; for
my needs it just made much more sense to keep it all together.

> I also regret line breaks and such are mangled in pmwiki, which
> means you can't easily edit your data from outside a web browser,

I agree a fair bit on this point -- there are many times that I
wish for a plainer-text version of the files.  That's actually
quite pluggable, however; we could certainly have a module that
stores the files in a more plaintext form.  But there's also a
very strong issue of security at play -- part of the advantage
of PmWiki's encoding is that it also limits a variety of attack
vectors.

Message from Pm at the mailing list. [1]

File extensions

I am trying to use a php replace tool, but it requires a file mask to identify the file; .htm, etc. Are pmwiki page files of any particular type? What would the file extension be? Jagtig.

The files are named Groupname.Pagename, there is no extension, or a tool could consider the extension to be .Pagename which changes for each page, eg. the file containing this page would be named pmwiki/wiki.d/PmWiki.PageFileFormat-Talk. --Petko November 02, 2011, at 09:19 AM

Observations

I had a bunch of pages incorrectly attributed to the PmWiki group in my instance, so being the admin I decided it would be easier to take care of this via the "backdoor". I changed the name of a bunch of files to the new group from the old, and everything seemed to work fine. I used VI to peer inside and noticed that the "name" attribute was equal to the old filenames. BE CAREFUL if you choose to edit pmwiki page content files in an editor like VI. You can lose all of your content so make sure to back everything up first! (I did)Most of my resaved files were fine, but files that had "line too long" issues in VI, clobbered all content. I did some further research and discovered that pmwiki will actually change the internal name file attributes if you just go into each page thru the pmwiki interface and Save them. No changes are necessary and the name attributes correct themselves once saved. --JJ

Perl snippet to pmwik-ize text:

    sub wikiize_text {
        my $t = shift @_;

        $t =~ s/%/%25/g;
        $t =~ s/\</%3c/g;
        $t =~ s/\n/%0a/g;
        return $t;
    }