Security of MySQL Userid/Password in Apache CGI-BIN

I'm writing some 'C' compiled Apache CGI-BINs which interact with MySQL via
the 'C' API (platform: Linux).

Where should I put the MySQL userid/password so that it is the most secure?

Possibilities:

a)Compile them in to the CGI-BIN (and I'm assuming that there is no way for
a web user to actually get the data in the executable--they can only run it,
right?).

b)Keep them in a separate file which is read by the CGI-BIN.

Any thoughts about what is the best way and any security concerns?

Thanks.
------------------------------------------------------------
David T. Ashley (dta@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

David T. Ashley wrote:
> I'm writing some 'C' compiled Apache CGI-BINs which interact with MySQL via
> the 'C' API (platform: Linux).
>
> Where should I put the MySQL userid/password so that it is the most secure?
>
> Possibilities:
>
> a)Compile them in to the CGI-BIN (and I'm assuming that there is no way for
> a web user to actually get the data in the executable--they can only run it,
> right?).
>
> b)Keep them in a separate file which is read by the CGI-BIN.
>
> Any thoughts about what is the best way and any security concerns?
>
> Thanks.
> ------------------------------------------------------------
> David T. Ashley (dta@e3ft.com)
> http://www.e3ft.com (Consulting Home Page)
> http://www.dtashley.com (Personal Home Page)
> http://gpl.e3ft.com (GPL Publications and Projects)
>
>

Compiling them into the executable would definately keep it away from prying
eyes - but you would want to make it extra-strong (lots of
case/numbers/meta-characters) to minimize hackers attempts to crack the password.

I tend to stay away from CGI due to some other inherent risks involved with some
of the "provided" scripts like upload.cgi and Count.cgi. Therefore I almost
always disable cgi and use other methods. But, YMMV.

you could use an encode/decode mechanism such that you can change the password
on a somewhat regular basis - but I would store it in a file outside the web
server directory tree (but give it the proper ownership etc...) This would
minimize the exposure.

One thing to mitigate risks is to have the database server on another server
where the ports used are not internet-facing - so there can be no direct
connection from the internet to your MySQL server ports.

The other thing I do on MY web server is that it runs OpenVMS w/Apache. The
only system at Defcon 9 not hacked. - then they changed the rules such that the
ONLY OS you could run was some flavor of the Linux kernel.

--
Michael Austin
Database Consultant
Domain Registration and Linux/Windows Web Hosting Reseller
http://www.spacelots.com

"David T. Ashley" <dta@e3ft.com> wrote in
news:w6GdndSuesoIzzTYnZ2dnUVZ_qunnZ2d@giganews.com :

> Where should I put the MySQL userid/password so that it is the most
> secure?
>

OUTSIDE of the web space.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Mark wrote:
> "David T. Ashley" <dta@e3ft.com> wrote in
> news:w6GdndSuesoIzzTYnZ2dnUVZ_qunnZ2d@giganews.com :
>
> > Where should I put the MySQL userid/password so that it is the most
> > secure?
> >
>
> OUTSIDE of the web space.
>
> ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
> http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
> ----= East and West-Coast Server Farms - Total Privacy via Encryption =----


I don't think putting the password inside the executable makes it more
secure than putting it in another file.
If an attacker gets filesystem access they could download the
executable and decompile it, upload and use a tcp proxy and watch for
mysql traffic or redirect the IP, alter the DNS to point to attacker's
listening server, replace the mysql executable, there are a million
ways to get passed bad security once you have fs access....
So it's game over once the attacker has file system access to things
which are not normally in the web document tree. If you therefore
compile in your password, remember not to have your CGI executable
inside the web doc root.
You could encrypt a string containing your password and store that but
for the same reasons above, it won't take long to get the password.
If you stick to the tried and tested method of a file outside the web
doc root, use proper fs permissions and if you make your mysql server
connection to a non internet connected machine with proper ACLs over
SSL you will probably be alright.
Add to this the fact that we all make mistkes and that application
vulnerabilities lead to privaledges being gained which are equal to
having the password anyway, the situation of "stealing password->data
loss leakage corruption" will be much less likely on a system with
proper permissions that "code flaw->xss etc...->data loss or leakage
corruption"
That's my 0.02, in general what you are talking about is "security by
obscurity" which in fact is just a "non standard security method" no
more secure in the long run but leads to a lowered perception of the
actual risk which does exist and which we all have to take.