database programming security

Hello,

This question has come up numerous times in my career, and I was
hoping some of you out there might have some additional insight.
Essentially, where should the username and password for a database be
kept for an external program that accesses it?

For example, let's say I have a compiled C or C++ program. Is it okay
to put the username and password in a #define? What's a common
solution for web apps that need to access a database?

I have no good solution for the compile program. As for the web app,
I've been using a password file kept out of the web server's root. I
have no idea whether or not that is even remotely secure.

I appreciate your input on this topic,
Mick Charles Beaver

>This question has come up numerous times in my career, and I was
>hoping some of you out there might have some additional insight.
>Essentially, where should the username and password for a database be
>kept for an external program that accesses it?

It often turns out that there is no good answer, especially for
a shared web server leased from a host.

>For example, let's say I have a compiled C or C++ program. Is it okay
>to put the username and password in a #define?

I got energetic and put an ENCRYPTED password in the program. But,
the program has to be able to decrypt it. This protects against
running strings(1) on the executable, but not much else. A breakpoint
set on the call to mysql_connect(), or a tricked-up libmysqlclient,
would reveal it.

>What's a common
>solution for web apps that need to access a database?

>I have no good solution for the compile program. As for the web app,
>I've been using a password file kept out of the web server's root. I
>have no idea whether or not that is even remotely secure.

A password file kept out of the web server's document root is pretty
good on a non-shared web server against web threats. Now, can
people actually log in (not via web server) to that host? That's
another threat. How about FTP?

If it's a shared web server, you have the problem that other people's
PHP (or Perl or Ruby or whatever) scripts can read the password
just like your PHP scripts.

On May 15, 7:26 pm, gordonb.9t...@burditt.org (Gordon Burditt) wrote:
> >This question has come up numerous times in my career, and I was
> >hoping some of you out there might have some additional insight.
> >Essentially, where should the username and password for a database be
> >kept for an external program that accesses it?
>
> It often turns out that there is no good answer, especially for
> a shared web server leased from a host.
>
> >For example, let's say I have a compiled C or C++ program. Is it okay
> >to put the username and password in a #define?
>
> I got energetic and put an ENCRYPTED password in the program. But,
> the program has to be able to decrypt it. This protects against
> running strings(1) on the executable, but not much else. A breakpoint
> set on the call to mysql_connect(), or a tricked-up libmysqlclient,
> would reveal it.
>
> >What's a common
> >solution for web apps that need to access a database?
> >I have no good solution for the compile program. As for the web app,
> >I've been using a password file kept out of the web server's root. I
> >have no idea whether or not that is even remotely secure.
>
> A password file kept out of the web server's document root is pretty
> good on a non-shared web server against web threats. Now, can
> people actually log in (not via web server) to that host? That's
> another threat. How about FTP?
>
> If it's a shared web server, you have the problem that other people's
> PHP (or Perl or Ruby or whatever) scripts can read the password
> just like your PHP scripts.

Put your password in secure place and do use encryption, disable all
the services that seem to be no used. call your file from other
directory that has your password and user in.