This feature really makes little sense. The correct way to do this is server-side authorization controls. SSL provides transport security already. The "once the users password is cracked" issue is orthogonal, and means you need a better authentication system than simple passwords. I would recommend a two-factor system, and I know RSA's SecurID can be integrated with Apache.
--Noah On Jul 31, 2007, at 6:40 PM, Vincent wrote: > > 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
