Opened 10 years ago

Last modified 18 months ago

#3803 new enhancement

more secure gringotts, password, maybe client side decryption

Reported by: Michael Grant Owned by:
Priority: low Component: GringottsPlugin
Severity: normal Keywords: encryption
Cc: Trac Release: 0.11


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.
  1. Could use something like 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.
  1. 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.
  1. 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.

Attachments (0)

Change History (1)

comment:1 Changed 18 months ago by Ryan J Ollos

Owner: Colin Guthrie deleted

Modify Ticket

Change Properties
Set your email in Preferences
as new The ticket will remain with no owner.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.