we are running a confluence 4.2.3 installation as our primary wiki. Even if we make use of page permissions and user management, we still can not store certain kind of data in the wiki like encryption keys, purchase prices and so on.

I was googling around a lot and I've seen different plugins for safely storing passwords like vault plugin or a plugin for sending a page encrypted using e-mail.

This is not what I'm looking for. I need something to store a document which is being encrypted either on clientside or immediately on server side so the information can not be retrieved by an administrator.

I would prefer a clientside implementation, because if its encrypted on the server it may still be intercepted by an administrator.

Of course the encryption could only be symmetric as it must be possible to be decrypted by anyone who knows the right passphrase.

The users currently all run Firefox 10 (yes, 10 as it's certified by atlassian) and a browser plugin maybe fine, too.

Let me rephrase the idea:

  • User types 'Price of car is €29.000' to a textbox
  • Plugin (either browser specific or confluence) detects submission of form
  • Plugin asks for passphrase (or uses default)
  • Plugin encrypts to 'Cevpr bs pne vf €29.000' (hopefully not rot13 ;))
  • Plugin encrypts form data and sends the encrypted form to server
  • Server does not know anything about encryption and happiliy stores data
  • Admin not happy, as she cannot read sensitive information from db

Any suggestions and ideas are very welcome.

Thanks in advance


Lock The Text might do the trick for you; it works on any/all text fields in firefox, and does require a user to press a button, but it's a lot better than copying all the values in a field into some other window for encryption. An alternative plugin is CryptFire, but I haven't used that one.

However, I think your goals might be flawed. Which is a nice way of saying: this is a terrible idea. Here's why:

You're correct in observing that Confluence is primarily a public-access-oriented wiki, and shouldn't be used to store confidential stuff. However, giving a bunch of users a passphrase and trusting them to encrypt stuff browser-side is even less secure, IMO, than just using Confluence permissions to lock users that shouldn't have access out of pages with confidential info (not that I'm suggesting you do that; it's still very insecure). What happens when a user uses a different browser than the suggested FF10, and doesn't encrypt the data? Or what if someone lifts the key from a user's workstation (probably a much less physically and infrastructurally secure machine than the Confluence server)? Or what if a user just...I dunno, forgets to encrypt something confidential?

The real solution is to use one of the password managers you dismissed; they are the right tool for the job, and using a public wiki to store data that is encrypted on an opt-in, per-user, and per-browser basis seems heinously insecure. If you want to look around for a password manager, I suggest KeePassX. It's minimal, cross-platform, and does exactly what you need it to; no more, no less.

Of course, that's ignoring the elephant in the room: if your internal wiki server isn't secure on the back end, or that you are worried that "administrators" might try to retrieve documents after they're received but before they are encrypted on the server side, you should probably seriously re-examine your internal network security, and the trustworthiness of your admins.

If you're worried about storing encryption keys specifically, and if you don't want to use a generic password manager, there are a number of good cross-platform utils out there that are specifically made to store PGP data in an easy-to-manage vault/keychain with a master passphrase; just ask Google. If you are managing SSH keys, there are a ton of centralized-management utils out there. May favorite is to use Puppet and ssh::auth, but that is a very large hammer and takes quite a bit of work.

  • Hello Zac, thanks for your feedback. In general we do trust our employees and admins, but there is stuff which is not for their eyes. We would have the same problem on any computer system, if someone can become superuser, she could read the data. So either way we would need encryption. In this case we look at the wiki like a folder on a fileserver. Even there the admin could read the files. At this point you would want to protect certain data. We're not trusting a bunch of users to encrypt their stuff, but we want to be able to protect certain data for certain users.I need to think about it. – user118305 Aug 6 '12 at 14:06
  • I think the goal of needing your confidential stuff encrypted and controlling access to the key (rather than the content) is good. I just don't think trying to hack encryption functionality onto something (Confluence) that is designed to disseminate, not protect, content is a good idea. – Zac B Aug 6 '12 at 14:47
  • I marked your answer, because we will reconsinder saving sensitive data in confluence. Maybe we will use Truecrypt containers on a network volume – user118305 Aug 8 '12 at 7:33
  • That's a good solution. If you really enjoy wiki-based/web-based management of that data, you could store the file for something like tiddlywiki (google it) in an encrypted volume/file, and only decrypt it when necessary. – Zac B Aug 8 '12 at 17:36

An alternative approach may be to use Redaction, Content Security for Confluence. It is a Confluence add-on which allows you to hide sensitive content on a Confluence page or blog, making it available to only desired users/groups.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy