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

Wow. That was the most comprehensive answer I have ever had to any
question ever! Thanks for all that.

I think I'm going to have to go off and do some learning to achieve
all that but clearly the first step is get the sensitive stuff into
the database. Thanks for explaining everything so clearly.

:)

On Aug 24, 4:12 pm, Ben McClure <ben.mccl...@gmail.com> wrote:
> Sarah,
>
> Regarding point 1, if they got into your web server via FTP, they would have
> no way of initiating a database connection to get at the data. If they
> actually broke into your web server directly, then it is true that they
> could look up your database connection details and run MySQL queries against
> it.
>
> However, if they broke into your web server as such, They would have access
> to a lot more information than that.
>
> Regarding point 2, you're absolutely right--if the file is outside of the
> webroot, then only point 1 applies to it. If the file were in the webroot
> and the web server were misconfigured, then all PHP code in the files in the
> webroot would be displayed exactly as it was typed by the
> developer--obviously not a good situation when sensitive information is at
> stake :)
>
> I think the database is the way to go. You have the option of getting a bit
> clever with how you store the information... you could use a two-way
> encryption method to encrypt the key for storage in the database, and
> encrypt/decrypt it using a random hash value that you set in your config
> file. The obvious hole in this setup is that the web server HAS to know how
> to decrypt and view the API key, so someone who has access to your web
> server has the ability to perform those same actions if they know how.
>
> One possible way around this is creating a complex algorithm for modifying
> the hash based on some other value(s) and encrypting and decrypting the
> information, and then obfuscating the PHP code so that it's not obvious what
> it is doing. You could use a freely available PHP obfuscator for this.
>
> In this scenario, to get access to your API key, someone would have to:
>
>    1. Break into your web server (FTP wouldn't work)
>    2. Get your database connection details and encryption/decryption hash
>    3. Find the obfuscated code which performs the decryption
>    4. De-obfuscate the code so they can figure out the procedure
>    5. Query the database for the encrypted key
>    6. Decrypt the key
>
> So while not 100% secure, everything you do to secure the key adds another
> layer of protection that makes it more likely to be safe.
>
> Unfortunately, there is no way to 100% securely store secure information
> that your web server knows how to read automatically. You can keep making it
> more and more secure, but someone will always be able to trace those steps
> back to your secure information if they know how.
>
> Either way, the key is to add some additional layers between the API key and
> your application--the database is one layer that goes a long way toward that
> goal.
>
> I hope that was of some assistance, and let me know if I can try to help any
> further. Thanks,
>
> 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