If you really insist on this otherwise silly feature, you should look at one of the Fx/GPG integration plugins. FireGPG is the first that comes to mind. Doing this is kind of multistep security is very broken and should be regarded as worthless when compared to a real security solution. I can illustrate exactly how it is broken, but I would really prefer you take my word on it. Security by obscurity is not a replacement for a well designed authn/z solution.
--Noah On Jul 31, 2007, at 7:29 PM, Vincent wrote: > > Well, let me try to explain the feature again. The intent is to store > passwords and to do so in a way that isn't just the information being > encrypted on transmission from serverside to browser, but to not have > the information available in plaintext to begin with. It would be > similar to sending email to someone with a PGP key, but having the > email stored in a public area. Still secure because noone has the > key. So in the event of storing information like this within the > wiki, even if I am able to get an account level password with > permissions to view a specific page, I still need to do something > else. > > My personal suggestion was to just upload a password protected zip > file to the wiki and be done with it, but the usability wasn't simple > enough. :) > > But regardless, doing this all server side or client side is > irrelevant if the encryption key and methodology are a shared secret. > YES, I agree that it's not the most sensible feature in the world, but > based on the Rails encrypt-a-wiki article I posted as well as the > Javascript example I posted, there's at least someone out there with a > similar idea, so I'm not so sure the feature doesn't make sense. > Whether this feature is used in conjunction with something server-side > or not is debatable, but the idea of a form-field and button that says > Encrypt me on the Wiki-Edit screen and a form-field and button that > says Decrypt me on the Wiki-View screen doesn't seem that intrusive > while still being useful, requiring less configuration and admin > overhead than dealing with page level security. > > All that said, I respect your viewpoint and actually agreed with it > until I thought about the use case some more and am now convinced it's > a feature worth having. > > If I were to go all out it would look like: > > WIKI_ENCRYPT is an optional permission that a user would need to have > to encrypt wikis or maybe it's just a trac.ini variable where wiki- > encryption = true|false > > On the Wiki_edit screen, if a user has WIKI_ENCRYPT on it, then a form > field appears where the user can input an encryption key, select an > encryption type and then hit the button. The button uses javascript > to transmogrify the data w/o saving the key or the key-type. There > would also be a Reset/remove encryption button. Then the user can hit > save and the data is now saved according to the scheme specified by > the user. > > On the Wiki_view screen, if a user has WIKI_ENCRYPT on it, then a form > field appears providing the user the ability to input an encryption > key, select an encryption type and then hit the button to take a shot > at decoding what is there --- again using Javascript, but in this case > modifying the actual HTML.innerText instead of the textfield.value on > the Edit screen. > > Admittedly, all this can be easily simulated by just copying and > pasting the text into the javascript web page shown above, but the > clients' deal is efficiency w/o sacrificing the security of the > situation. This method as I describe it seems to me to be a very > intuitive way of obfuscating your information w/o adding too much in > the way of overhead or mouseclicks and doesn't require that Trac be > sitting under SSL or some other secure transport layer to "hide" the > information. > > V > > > 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 -~----------~----~----~----~------~----~------~--~---
