Thread: Securing PHP scripts
In an attempt to secure the PHP/PostgreSQL server Im working on, I've setup Postgres so that any connection made to the databaserequires a valid password. Now to connect to the DB via PHP, I have the password hard coded (which is in clear text). Here is my question: Is there a way around storing the password in clear text? ---------- Regards Cody Phanekham Email: cody.phanekham@salmat.com.au Ext: 2183 Phone: 02 9353 2183 ************************************************************************************* This e-mail, including any attachments to it, may contain confidential and/or personal information. If you have received this e-mail in error, you must not copy, distribute, or disclose it, use or take any action based on the information contained within it. Please notify the sender immediately by return e-mail of the error and then delete the original e-mail. The information contained within this e-mail may be solely the opinion of the sender and may not necessarily reflect the position, beliefs or opinions of Salmat on any issue. This email has been swept for the presence of computer viruses known to Salmat's anti-virus systems. For more information, visit our website at www.salmat.com.au. *************************************************************************************
Cody..... > Now to connect to the DB via PHP, I have the password hard coded (which is in clear text). > > Here is my question: Is there a way around storing the password in clear text? But no user can ever read that clear text, right? They should only get the PHP script output which normally wouldn't contain the user name and password..... There can be a danger of other users on the machine being able see the clear text password if it's a shared machine and if they are able to read the script, though! Of course that didn't answer your question...... maybe somebody else knows a way around storing it in clear text. BTW, for the best security you should be sure and run PHP with register_globals off in the php.ini config file, read about it at http://us4.php.net/register_globals Sorry if I'm telling you a bunch of stuff you already know anyway....... brew
I don't know of any.. Luke Woollard HPAD.com -----Original Message----- From: pgsql-php-owner@postgresql.org [mailto:pgsql-php-owner@postgresql.org]On Behalf Of brew@themode.com Sent: Tuesday, August 19, 2003 12:55 PM To: pgsql-php@postgresql.org Subject: Re: [PHP] Securing PHP scripts Cody..... > Now to connect to the DB via PHP, I have the password hard coded (which is in clear text). > > Here is my question: Is there a way around storing the password in clear text? But no user can ever read that clear text, right? They should only get the PHP script output which normally wouldn't contain the user name and password..... There can be a danger of other users on the machine being able see the clear text password if it's a shared machine and if they are able to read the script, though! Of course that didn't answer your question...... maybe somebody else knows a way around storing it in clear text. BTW, for the best security you should be sure and run PHP with register_globals off in the php.ini config file, read about it at http://us4.php.net/register_globals Sorry if I'm telling you a bunch of stuff you already know anyway....... brew ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
I should of mentioned that the server is a dedicated PHP / PostgreSQL server, therefore no other user would have access toit. My only concern is *if* the server gets compromised, then the attacker would have access to the DB without too much effort. > -----Original Message----- > From: brew@theMode.com [mailto:brew@theMode.com] > Sent: Tuesday, 19 August 2003 12:55 > To: pgsql-php@postgresql.org > Subject: Re: [PHP] Securing PHP scripts > > > > Cody..... > > > Now to connect to the DB via PHP, I have the password hard > coded (which is in clear text). > > > > Here is my question: Is there a way around storing the > password in clear text? > > But no user can ever read that clear text, right? They > should only get > the PHP script output which normally wouldn't contain the > user name and > password..... > > There can be a danger of other users on the machine being able see the > clear text password if it's a shared machine and if they are > able to read > the script, though! > > Of course that didn't answer your question...... maybe > somebody else knows > a way around storing it in clear text. > > BTW, for the best security you should be sure and run PHP with > register_globals off in the php.ini config file, read about it at > > http://us4.php.net/register_globals > > Sorry if I'm telling you a bunch of stuff you already know > anyway....... > > brew > > > > > > > ---------------------------(end of > broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to > majordomo@postgresql.org) > ************************************************************************************* This e-mail, including any attachments to it, may contain confidential and/or personal information. If you have received this e-mail in error, you must not copy, distribute, or disclose it, use or take any action based on the information contained within it. Please notify the sender immediately by return e-mail of the error and then delete the original e-mail. The information contained within this e-mail may be solely the opinion of the sender and may not necessarily reflect the position, beliefs or opinions of Salmat on any issue. This email has been swept for the presence of computer viruses known to Salmat's anti-virus systems. For more information, visit our website at www.salmat.com.au. *************************************************************************************
El Mar 19 Ago 2003 00:08, escribió:
> I should of mentioned that the server is a dedicated PHP / PostgreSQL
> server, therefore no other user would have access to it.
>
> My only concern is *if* the server gets compromised, then the attacker
> would have access to the DB without too much effort.
IF the attacker compromises your server access, I think there will be other
things to be MORE concern about.
--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-----------------------------------------------------------------
Martín Marqués | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------
On Tue, Aug 19, 2003 at 13:08:46 +1000, Cody Phanekham <Cody.Phanekham@salmat.com.au> wrote: > I should of mentioned that the server is a dedicated PHP / PostgreSQL server, therefore no other user would have accessto it. If they are on the same machine, then ident authentication might be appropiate to use.
On Tue, 19 Aug 2003, Cody Phanekham wrote: > I should of mentioned that the server is a dedicated PHP / PostgreSQL > server, therefore no other user would have access to it. > > My only concern is *if* the server gets compromised, then the attacker > would have access to the DB without too much effort. If the server gets compromised, you've lost. If they just get to execute arbitrary code as the httpd user, you've lost, if they can execute arbitrary code as root you've doubly lost. Unless youre system is designed for anonymous database access to be secure, you can't really protect it from a rogue web server.
On Monday 18 August 2003 21:08, Cody Phanekham wrote: > I should of mentioned that the server is a dedicated PHP / PostgreSQL > server, therefore no other user would have access to it. > > My only concern is *if* the server gets compromised, then the attacker > would have access to the DB without too much effort. > If by "comprimised" you mean rooted, then the attacker can do whatever they like on the system anyways. If someone has root on a box ... they have access to the DB ... with or without a password to begin with. Andy