Suggestion: closed source enccoding/decoding

2004-02-15
2004-03-19
  • I suggest to separate encoding/decoding functions in separate module and change the license to allow compilation with closed source encoding module.
    This would improve security for encodded scripts.
    You would use your prefered crypto method
    without letting other people understand your scripts format.
    Just now I can decode every script.
    ----------------------
    Best Regards, Vladimir

    I'm ready to do this work my self.

    ----------------------

     

    • Anonymous
      2004-02-15

      Why not allow the user to influence the encoding process with some closed source module, that they themselves can compile, using a simple template that we make etc.

      A simple example: file X is encoded using method Y, mmcache looks for a module to process method Y. Of course module Y is a compiled module that is shipped with the specific php program. Module Y might apply RSA encryption/decryption to the encoded file, it might pass some unique parameters to mmcache, which would then slightly modify the encoding process, to complicate reverse engineering.

      Benifit is of course that the whole encoding part of mmcache doesn't have to be closed source, and that the users themselves can compile a seperate module to their specific needs of security, which only "influences" but "is not" the encoding process.

      Disadvantage is that it's complicated to safely implement such loadable modules, since the module that's loaded automaticly gets the privileges that apache is running under. So, an intermediate layer is probably required to protect the apache running context.

       

    • Anonymous
      2004-02-15

      Why not allow the user to influence the encoding process with some closed source module, that they themselves can compile, using a simple template that we make etc.

      A simple example: file X is encoded using method Y, mmcache looks for a module to process method Y. Of course module Y is a compiled module that is shipped with the specific php program. Module Y might apply RSA encryption/decryption to the encoded file, it might pass some unique parameters to mmcache, which would then slightly modify the encoding process, to complicate reverse engineering.

      Benifit is of course that the whole encoding part of mmcache doesn't have to be closed source, and that the users themselves can compile a seperate module to their specific needs of security, which only "influences" but "is not" the encoding process.

      Disadvantage is that it's complicated to safely implement such loadable modules, since the module that's loaded automaticly gets the privileges that apache is running under. So, an intermediate layer is probably required to protect the apache running context.

       
    • Hi again!
      I'd like to see any comment from project programmers.
      Is this project alive now?
      Or you are so busy creating a new name?
      --------------------
      Best Regards, Vladimir

       
    • Jason Sheets
      Jason Sheets
      2004-03-19

      Closing the source will not make the encoded scripts more secure, as proven time and time again by many professional closed source companies such as Microsoft.

      Consider OpenBSD, without a doubt the most secure out of box install of an OS, yet it is completely open source, when implemented correctly a program's security comes from planning and proper implementation, not being unable to view the source code.

      If you truly need utmost security I'd recommend implementing your solution in C or C++ rather than PHP or other similar languages or even Java.

      With that said, the performance and security benefits of MMCache are very good and will fit the needs of most users very nicely.

      Right now you can decode the bytecode of every PHP script but not directly obtain the PHP source code necessarily, this also applies to Zend's own products.

      The suggestion to allow modular encoders is something I have also been considering, it sounds nice but I am not sure it would actually increase the security of the scripts at all, remember you must supply a decryption key to your user in some way otherwise the scripts will not be able to execute at all, this method might be a custom compiled version of MMcache but that would hurt the mmcache community by introducing compatability problems.

      It also could be a file distributed and loaded by MMCache itself but then if they wanted to they could use that key to decrypt the bytecode and have the same result, bytecode.

      Public key encryption might also be an option but again, if they distribute the private key the protection has been compromised and is useless. 

      Allowing the scripts to cause mmcache to load a module sounds like a good idea until you consider the webhosts point of view, many of which disable dl() in php and control themselves what modules are running, they will not want unverified code running as part of their http process.

      This is something that needs to be thought of in much more detail and I'm very open to hearing responses and implementation ideas but again the values of doing this need to be sorely considered before adding overhead or complexity to mmcache.

      In the end we may find making the generic mmcache encoded files more secure is a more scalable and appropiate decision.