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