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 like 
http://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
cake-php+unsubscr...@googlegroups.com For more options, visit this group at 
http://groups.google.com/group/cake-php

Reply via email to