more secure gringotts, password, maybe client side decryption

[Michael Grant]

It's not ideal to have the db and the trac.ini with the key on the same machine. With this info, it's possible to decode a gringott.

Perhaps there could be some way to make this more secure by somehow splitting the public/private key in such a way that the private key was not stored on the server at all.

I don't have any perfect ideas how to do this. Some (perhaps bizarre) ideas that come to mind:

1. use ssl and a client-side ssl certificate. Make the gringott an iframe that encrypts with the client certificate such that only the client can see it. The problems with this are numerous. If using a web server like apache, trac couldn't just create a new instance of itself on a port to serve up the data to the iframe encryted with the certificate. This idea almost certainly won't work.

2. Could use something like ​http://www.hanewin.net/encrypt/ to decrypt the gringott on the client side via javascript. Unfortunately this has problems. If someone can get at your web server, they can rewrite the javascript decrypter to just steal your password. Maybe this could be avoided with a signed java applet running in th browser? A bit heavy weight though, will be very slow and java isn't available everywhere.

3. Put a password on the key that is sent to the server. Before the gringott is decoded, the user must submit the password. ColinG noticed that this probably wouldn't work as something would cache the plain text on the server. If the caching could be avoided, then this may be the simplest method. The data then is only as secure as the password which may be sent in the clear and subject also to someone messing with the server.

4. Instead of using gringott, store a file in the wiki that you locally encrypt with gpg (or pgp). Not at all as convenient as gringott. Also requires special software installed on the browser, so forget about getting at your lost passwords from an internet cafe (something I would fear doing anyway!)

In short, I don't have a great solution. It seems 3 is the easiest and most implementable solution, though your data is only as secure as the password and it may be sent in the clear unless your trac using https. Care would need to be taken not to cache anything.

Each gringott should be able to have it's own password (and own key) associated with it.

There could be an option for a master key/password.