SEO
vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
02-28-2008, 09:50 AM
| ||||
| ||||
 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      |
|
02-28-2008, 09:50 AM
| |||
| |||
| Re: database programming security >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. |
|
02-28-2008, 09:50 AM
| |||
| |||
| Re: database programming security 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. |
|
02-28-2008, 09:50 AM
| ||||
| ||||
| Re: database programming security On 15 May 2007 17:51:54 -0700, kwan wrote: > 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? [..] >> 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. Additionally, make a whole lot of user IDs and passwords. Sort out privileges of those IDs according to reasonable function, and be as paranoid about it as you can be. There's no reason, for example, that a web script needs to READ a credit card number from a table. That can happen from a different process running elsewhere away from the web space, under an ID that does have authority to select from the the table in question. -- 8. After I kidnap the beautiful princess, we will be married immediately in a quiet civil ceremony, not a lavish spectacle in three weeks' time during which the final phase of my plan will be carried out. --Peter Anspach's list of things to do as an Evil Overlord |
Linear Mode
