This is a different issue than obfuscating data. You are talking about making a webapp that doesn't trust the server. The Web (as defined as HTML+JS+CSS+HTTP+etc) is not designed to provide this kind of end-to-end security, and attempts to layer it on top are fraught with peril. Solutions to this problem are numerous and varied, but they will require a better underlying system.
--Noah On Jul 31, 2007, at 7:30 PM, Vincent wrote: > > Oh, and in this case, it's an internal wiki behind a VPN+firewall. > Access and making sure that the information isn't stored in a > compromised format is the issue as I understand it. > > On Jul 31, 3:52 pm, Noah Kantrowitz <[EMAIL PROTECTED]> wrote: >> 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 -~----------~----~----~----~------~----~------~--~---
