Confluence inline encryption / Form encryption

Question

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

Answer 1

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.

Answer 2

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.