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 -~----------~----~----~----~------~----~------~--~---
