I would tend to agree with you. In fact I completely agreed with you until I looked into this a bit. And yes, ultimately, you're kind of right - end-to-end security and HTML isn't quite consistent. But in the event of hey I want to post a message and provide an easy way to encrypt/decrypt it if I have the key actually seems reasonable to me. It prevents data from being stored in the clear in the wiki or in a file. In fact, it's out in the open - it's the encryption key that has the be known.
In this case, the context-dependent permissions system isn't what is desired. The client doesn't want the permission to be user-specific as once the user password is cracked, then it's all over. It's a 2nd level of security that can be applied to a given wiki page. At first I thought .htaccess or something like that would be enough, but he emphasized that he didn't want the data to be stored unencrypted either, hence the reference to the Rails app below/above. Make sense? Still haven't checked into PGP meets Javascript, but it seems like it would be trivial to do a: text=dom.text cryptkey = dom.cryptkey newtext = togglecrypt(text, cryptkey); So... while I was typing I did a bit of research and found the following page: http://www.fourmilab.ch/javascrypt/jscrypt.html This pretty much does what is needed, so I guess the next step would be to see what it would take to modify the Wiki edit form to include an encrypt using this key button. And the Wiki view page to include an decrypt using this key button (form) that called these functions, possibly adding some settings in trac.ini so that you could control which kind of encryption/decryption cipher you would be using (i.e. base64, hex, blah) Make sense? Is this something I should submit as a plugin or try to work it out as a feature that can be enabled/disabled in trunk? Would be curious if anyone else on the mailing list would find this useful, with the idea that you can now store your passwords on your wiki, presuming that your encryption key is secure w/o worrying about even those pesky boys who manage to get root access to your wiki and database... they still can't read the text without the key. Vincent On Jul 31, 3:01 pm, Noah Kantrowitz <[EMAIL PROTECTED]> wrote: > You should use the new context-dependent permissions system. Look at > the authz-policy sample plugin. If you want end-to-end security, > don't use HTML. > > --Noah > > On Jul 31, 2007, at 5:47 PM, Vincent wrote: > > > > > As an addendum, the client who requested this feature found this link > > to an equivalent feature written in Ruby. Seems to me this could be > > done client side (presuming there is some sort of cryptology library > > available for javascript) but it could also be done as a python > > process. Will do more research and get back to the group. > > > Vincent > > > On Jul 31, 2:01 pm, cobwebsmasher <[EMAIL PROTECTED]> wrote: > >> This is something I hadn't thought would be useful, as I think > >> there are plenty of workarounds to get a similar effect, but I > >> wanted to know what the group thought of this idea: > > >> Encryptable Wiki pages that can only be unlocked by either a > >> specific password and/or a specific username/password combination. > > >> Client wants a place to store usernames/passwords, but doesn't > >> want to store it on a wiki as you could work around the wiki to > >> get the information. I've suggested just placing a zip file with > >> a password as an attachment on the wiki, but he really wants this > >> notion of an encryptable wiki --- it's stored in the database > >> encrypted so that only users with a specific password can read > >> what it's saying. > > >> I guess you could rig up an AJAX DOM sweep that took a given > >> document through some form of reversible encryption, but I have no > >> idea how secure one can make any reversible encryption scheme if, > >> at the end of the day, a password is involved. > > >> Thoughts on the idea and possible implementation? > > >> Thanks, > > >> Vincent > > >> --------------------------------- > >> Got a little couch potato? > >> Check out fun summer activities for kids. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
