If people are this concerned about security then I suppose the next step would be to encrypt the PHP code with something like Zend Guard?
http://www.zend.com/en/products/guard/ HTH, Paul. On Aug 25, 6:21 pm, Ben McClure <[email protected]> wrote: > Jens, > > You are absolutely correct; I was only referring to the fact that via FTP, > one cannot directly run mysql commands like they could via shell, however > someone who breaks in via FTP *could* potentially create a script which > queries MySQL and outputs the data or something similar, and then call that > script from the website by URL. > > All the more reason that the data stored, even in the database, should be > secured somehow. What it all boils down to is that a website unfortunately > needs to know how to access certain sensitive information, which usually > means storing credentials in a location where the web server can read them. > > If you are concerned about the security of the data (probably a wise > concern, depending on the data), steps should be taken to make it as > difficult as possible for anyone but your website code to decrypt and read > the data. > > Someone else may have better ideas, but the most common factors I have found > recommended when securing API keys (or any other sensitive data, really) > are: > 1. Don't store the data on the web server. If you have the ability to use a > 3-tiered structure (web server, application server, database server) then > the problem becomes more simple because the database server does not have > direct access to the web server, and compromising the web server does not > compromise the security of the application server. For most webapps, onle > one or two servers are used, however, so this becomes more difficult. At a > minimum, store the key in the database. > > 2. Encrypt the data in the database. If someone breaks into your database, > don't give them the opportunity to simply view your API keys in plain text. > > 3. Protect the related application code which decrypts and uses your > unencrypted API key. Obfuscation using a (free) service > likehttp://www.codeeclipse.com/could make the code look more like gibberish > and > make it more difficult to reverse-engineer. > > 4. Don't create functions on your web server which simply return the > unencrypted API key. If someone got access to your web server, they could > simply use that PHP function to retrieve your key without having to figure > out your encryption mechanism at all. The application should unencrypt the > key, use it, and then discard it all within obfuscated code and without > having to return that sensitive information back to the caller of the > function. > > I know that is probably a bit obscure, and will require some work to > implement--and there very well might be better or more standardized ways to > secure the information. Without big budgets and large network > infrastructures, however, it's hard to keep data that your web server needs > to be able to access without user interaction completely secure. > > Sorry for the long-winded reply again :) > > Ben -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php
