Thursday, August 25, 2011

Re: How come this isn't a safe way to store username and passwords

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

No comments: