[nycphp-talk] Where to store credentials and/or keys
Dan Cech
dcech at phpwerx.net
Mon Aug 14 14:21:14 EDT 2006
Aaron Fischer wrote:
> Greetings listers (or is it listies?),
>
> Following up on recent emails re. taking steps to secure code and data,
> I have a new question.
>
> One issue is regarding where to store MySQL database credentials
> (uname,pwd). The other is where to store an encryption/decryption key.
> My situation also deals with operating in a shared hosted environment
> of sorts.
>
> One solution recommended is to store code such as database credentials
> in a folder that is outside of the document root on the web server.
> Additionally, ask for the server admin to set permissions which will
> only allow access by my user account.
Unless your server is running suphp or some other method of executing
your scripts as 'your' user, all instances of php running under apache
will be run as the non-privileged apache user (www-data/nobody/???).
The idea of storing these types of things outside the web root is mostly
to defend against attacks that would result in this content being served
directly, which is a good thing to do, but not really what you're
talking about.
> However, I am not sure if that protects it from php executing on that
> directory. For example, if someone exploits another part of the server
> and gains the ability to access areas of the website by utilizing php
> code to traverse the file system and open documents, could they access
> that directory?
>
> It seems like the answer is yes and therefore this solution has holes in it.
>
> Comments appreciated on implementing this tactic and/or suggestion for
> alternative solutions.
Basically, if you are on a shared server there is very little you can
really do to secure your database connection.
One possible solution would be to use ioncube or zend to encode your php
files, including the database details. This will deter the casual
snooper, but with the right prodding your scripts will inevitably give
up access to either the login details or an active database connection.
Essentially this comes down to the fact that you cannot give any real
assurance of security unless you can trust the environment on the
machine, as any determined hacker with access to your scripts (encoded
or not) will be able to gain access to the data one way or the other,
whether it be by examining the source or executing the encoded script
and watching such things as defined functions, constants and variables,
and looking for any error output.
Dan
> I now have security books from Shiflett and Snyder/Southwell on my desk
> and have been going through them, but frankly I'm a bit jumbled with all
> the new topics so am hoping for some friendly pointers in the right
> direction. Looming deadlines are producing some anxiety as well. Sigh.
>
> Thanks.
>
> -Aaron
More information about the talk
mailing list