Feature Proposal: It would be great if users could add personal data to topics, viewed by their own only

Motivation

I have used this wiki to work, and to store information, and i have missed the feature of adding "personalized" data, to be read only by me. One can always make information visible based on user login, but that is not very "safe", specialy with the raw view feature.

Description and Documentation

Create a MACRO much like STARSECTION/ENDSECTION

%STARTENCRYPT%

infomation to be stored in the Topic, encrypted

%ENDENCRYPT%

Examples

If you type:

My boss is hard work person</em>

%STARTENCRYPT{user="MyUser"}%
and a cheap bastard prick 
%ENDENCRYPT% 

The topic created would have the following

My boss is hard work person
%STARTENCRYPT{user="MyUser"}%
U2FsdGVkX18UKqG9+RMYRCH+oY//WiDpLTh1ne9T3Ckhu0B9RQLlH+LtRSH1iMsi 
%ENDENCRYPT% 

which is the encryption of the sentence above using openssl (openssl enc -a -bf -d) with password "123. The password could be retrieved from user password.

When the topic is rendered the user would see:

My boss is hard work person and a cheap bastard prick

Whereas someone else would see (encrypt information is hidden) My boss is hard work person

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: RuiProcopio - 28 Feb 2009

Discussion

mmmm, it'd also be interesting to do the same for a group..

-- SvenDowideit - 28 Feb 2009

Not that I totally disagree, in fact in the past I'd hoped for just such a feature. TWiki had a similar plugin which didn't work on 4.2

However can you expand on your thought of the insecurity with raw view? I'd not myself seen a weakness (other than that having physical or root access to the server gives you the plain text of the topics, but that's obvious and expected). Did you mean in relation to comment tags perhaps?

For your scenario above, I put the sensitive content in another topic with restricted view/change permissions. Then Include that topic into the public one, with warn=off set. Only those with permission see the protected topic see that included text inline, and the protected topic is safe from searches.

The encryption as I view your spec, wouldn't prevent an admin level person from decrypting the message so it provides no physical access protection. It would however seem to prevent a Wiki admin from viewing the text. That could potentially create problems for spamming, XSS, or other attacks that might render and affect some wiki users, but which were not readily noticed, or searchable by an admin.

With my end user hat on, I like encryption. With my IT Manager hat on, it's use/abuse gives me pause. For that reason I'd be in favor of the text only decrypting for the person who encrypted it. Not for an entire group or list of users that could be set by the person setting the encryption. Unless the plugin also stripped or encoded any HTML/TML. My 2 cents.

-- CraigBowers - 13 Jun 2009

The main motivation i had for this were "side notes". As i said, i used foswiki (TWiki actualy) to work... used it to build some "followup tools" to follow some open issues during SW developement (thats what i used to do). Many times i wanted to keep my personal notes together with the "official" ones, but without the possibility of the customer to see them (for personal use only).

I guess your solution is very good and it would do the trick. But some kind of plugin/application should allow it to be as easy as just typing in the notes... and not create another topic, editi it, save it, change its permissions.... it should be "automatic".

Any suggestions on that?

As you may have guessed, i'm not very skilled in foswiki

Thanks for your comments

-- RuiProcopio - 13 Jun 2009

That's a useful application. I can't provide you much additional help, as I'm not a developer. But you might have a browse through the extensions here and see if you can get there with an existing combination. Another approach to your example would be to try something with http://www.foswiki.org/Extensions/TopicCreatePlugin

The idea being that you'd create a new support topic that would automatically have a child private notes page created at the same time. Seeing as it would be created with a template, you could have the permissions created automatically, and the inline include in the parent topic. So once you add content to the private notes topic below, it would show up inline.

-- CraigBowers - 20 Jun 2009

This raises a couple of questions:

• How is the key safely stored? Normally (using Func) you cannot get to the user's password.
  • If the user password is used, what happens if the user changes password? Data will be lost.
• What happens if the user leaves the company, without a centrally stored key? Data will be lost.
• If you do store keys centrally, data can potentially be read by admins.

So I am thinking of:

1. User can set the key in his/her user topic: ENCRYPT_KEY
2. The actual key is a combination of this variable, the wiki user name, and a key stored in Configure (to make it site specific)
3. Other users (admins) will only be able to get to the decrypted contents if they can pose as this user.

Using this scenario, the topics can be retrieved when the user is gone and an admin is able to log in as this user.

But that is also a security problem: the admin can do this any time:

1. Admin gets to the password file and comments out the current user entry+password (and he will be able to restore it)
2. He adds a new entry using his own password
3. On the wiki he logs in as the user and reads the topics

This could be countered by not storing ENCRYPT_KEY in a topic but by asking the user to enter it and pass it (double encrypted) to the session cookie. This should only be asked to users who have CHANGE access, so viewers won't see the prompt. But without the key "on paper" the data will be lost if the user forgot the password or left the company.

Perhaps these 2 concepts cannot be reconciled. If so, it could be a plugin configuration.

Possible library to use: CBC.

-- ArthurClemens - 25 May 2012

This is related to the more general problem of storing user secrets in a secure way on the server side, normally solved using the concept of a secured wallet that is unlocked by the user interacting with the system. Information stored inside the wallet is then used by the system on behalf of the user to perform a specific service,

• like decipher a certain area of a topic, or
• access a user's imap folders.

Let me broaden the range just a bit more. While it might not lend itself to EncryptDataInTopics itself, it still outlines the honey pot the fingers are in with this proposal.

Both of the described scenarios (encrypt topic data, access a personal imap folder) share in common that nobody else but the authenticated user and the system he uses should be able to perform this service. This also includes things like indexing the secured content to make it available to full-text searches performed by this user. Any further processing of secured services and content must of course guarantee that no information is disclosed to non-authorized people.

Computing a search index for secured content also means that the system needs access to that data in an unattended way while these operations happen offline, that is not part of the process where the user interacts with the site using a browser. As a consequence the system needs to use the users passwords to temporarily unlock secured content while processing the content (index the imap folders). So question remains how to store these passwords on the backends in a secure way without running in a similar disaster as Sony did.

Is there a way of implementing a secure online wallet? I haven't found anything for web applications yet. But maybe I haven't searched long enuf.

Note, that we normally never store any passwords but a hash value computed on the base of a password when the user authenticates on the site. Also, there are a lot of configurations where a user authenticates to a foswiki site using different means instead of authenticating using passwords.

-- MichaelDaum - 28 May 2012

Changing to ParkedProposal. No committed developer.

-- Main.GeorgeClark - 03 Nov 2015 - 15:45