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

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