On Thu, 2004-02-05 at 08:13, Harry Sufehmi wrote: > So there's a reasonably easy way to decrypt those encoded files then ? (despite > those vendors' claim...)
There isn't a program to revert encoded files to their original state, but there is a disassembler[1]. However, assuming your encryption key is a string all one would need is to do strings <filename> on the encoded php file to get your encryption key. The real problem you are facing here is security through obscurity is not security. First of all, your method of encrypting these files and decrypting them before serving up pages is just going to slow down your web server. The key is stored in a file somewhere and therefore easily accessible if someone gained access comparable to the web server. Since the key is readily available the data is not really encrypted, just obfuscated. I assume you are not transmitting these pages over the Internet and even within your intranet are using SSL? If not then that is a much bigger security hole. If you are really dedicated to encrypting these files I have a possible suggestion (see below for big caveats!). Continue with your encryption, however do not store the password anywhere on the server. You could either require the password be typed by users to view the pages (and *don't* cache it in any way anywhere!) or write an extension to apache (or whichever web server you use) to request the password when apache starts. It would then securely store it in ram and use it to decrypt pages, similar to how encrypted SSL certificates are handled. This would not be a php based solution, if php were to have access to the password then all that would be required to retrieve it would be the ability to execute custom php on the system by the hacker. You could try writing a php extension that would handle this however you may have a few problems: 1.) Depending on the web server used the php library's lifetime in memory may be shorter than the web server, or there may be multiple copies of the php library in ram. This would require typing the password more than once per web server restart. 2.) You need to make sure it is not possible to access arbitrary parts of php's memory using documented or undocumented php functions, etc. If so a cracker could write a php script to obtain the password. 3.) You would need to disable the dl() function so a custom extension could not be loaded to grab the password, though php.ini could be modified and the web server restarted. Then all the cracker would need to do would be to wait for you to re-type the password. Additionally make sure core dumps are disabled on the server, otherwise forcing the web server to crash could put the password in the core file. You know, after writing all that I realized something else: these are web pages being served. If the attacker has root access to the system what would prevent him from just using lynx to view the pages directly form the web server? SSL won't stop him/her and usernames and passwords will most likely be available if you use web based authentication. Your best method would be to require the password be typed every time a page is viewed, which has its own set of problems. Hopefully this gives you something to think about. Regards, Adam [1] http://www.derickrethans.nl/vld.php -- Adam Bregenzer [EMAIL PROTECTED] http://adam.bregenzer.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
