Re: The secrecy of PHP code

> Of course the absolute safest way besides encryting > your PHP is to just store your state secrets in files > outside the web server's document tree. > > i.e. > if your web server's document root is /var/www > > <?php > require("/var/super-secret/super-functions.php"); > if ($theanswer == 42) > { > echo (findthequestion($theanwer)); > } > ?> > > then even if you screw up the web server config > and .php files are sent back unrendered all you > expose is what's in the file above but not what was > included/required statements. > > This is an excellent way to protect sensitive info > like database passwords too. Actually... On a shared server, this *STILL* leaves all those files readable by "nobody", IE anybody else who can write PHP (or Perl, or JSP, or shell script) on the server. So while this is a good answer, and the "stock" answer, there *ARE* safer alternatives, depending on what you can afford in time/resources. #1. Compile PHP with the same settings *EXCEPT* not --with-apxs (nor --with-apache) and add another, different AddType with another, different mime-type and extension, along with an Alias and Action directive to httpd.conf, along with suExec for Apache (http://apache.org) to wrap around PHP. Whew. You can then create files ending in your new extension which will run AS YOU. Yes, *YOU*, the *REAL* user will be running PHP and have all the power and flexibility you have when you login. THIS HAS INHERENT SEVERE RISK IF YOU DO IT WRONG!!! You need to be damn sure that these directives *ONLY* apply in *YOUR* <Directory > directive in httpd.conf. Otherwise, *ANY* other user of Apache could make a new file with your nifty new extension and do *ANYTHING* to your account. You'll also want to test this setup under load as you need the PHP CGI to run "fast enough" #2. Buy the Zend encoder. http://www.zend.com This will make your PHP as readable as word.exe Of course, anybody with enough time and intelligence will be able to reverse-engineer *ANYTHING*... But they'd probably be able to reverse-engineer your web-site just by looking at its behaviour faster than dis-assembling Zend Encoded files. #3. Convert the *REALLY* sensitive bits of your PHP into C code to be compiled directly into PHP itself. Or maybe as PHP modules you can load in with that new-fangled stuff Rasmus has been presenting lately... http://conf.php.net #4. If it's just database username/password, you can set vars in httpd.conf or something... Never did it, never saw it done, it's just a rumor I heard. You're on your own for this one, kid :-) There are undoubtably *other* options beyond my ken, but there's a few. NOTE: Don't over-estimate the value of the intellectual property of your source code. There just isn't that much most of us are doing that is "all that". Your primary concern should probably be that somebody find your database passwords within your source, nor snag your whole site's PHP code and totally rip you off. -- WARNING richard@zend.com address is an endangered species -- Use ceo@l-i-e.com Wanna help me out? Like Music? Buy a CD: http://l-i-e.com/artists.htm Volunteer a little time: http://chatmusic.com/volunteer.htm