By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,616 Members | 1,184 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,616 IT Pros & Developers. It's quick & easy.

Connecting to MySQL without storing password in clear text

P: n/a
Bob
Hi,

I have a website in a Linux/Apache shared hosting environment and have
been given access to the MySQL server running on the same machine. To
access this database from PHP, I have to call mysql_connect(host,
user, password) where the password is hardcoded into my PHP source
file in clear text.

I see two security problems with this:

1) Since the PHP source is in my public webserver area, another user
of the same server could telnet into the server and look at the source
file and see the password file. I can't lock the file down using Unix
file system permissions or else the webserver won't be able to read
it.

2) If my ISP messes up their webserver config and accidentally stops
parsing PHP files and outputs the PHP file as plain text, the password
will be visible to all.

Is there any other way for PHP to authenticate itself to MySQL?

Thanks in advance!

Jul 16 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
On Fri, 12 Sep 2003 15:39:33 -0700 in
<message-id:0o********************************@4ax.com>
Bob <bo*@bob.com> wrote:
Hi,

I have a website in a Linux/Apache shared hosting environment and have
been given access to the MySQL server running on the same machine. To
access this database from PHP, I have to call mysql_connect(host,
user, password) where the password is hardcoded into my PHP source
file in clear text.

I see two security problems with this:

1) Since the PHP source is in my public webserver area, another user
of the same server could telnet into the server and look at the source
file and see the password file. I can't lock the file down using Unix
file system permissions or else the webserver won't be able to read
it.

You need to find somewhere that knows what they're doing to host your
site then (certainly no plug.. there's many available). If they can't
configure their servers correctly to prevent the above action, they
shouldn't be offering the service(s).


2) If my ISP messes up their webserver config and accidentally stops
parsing PHP files and outputs the PHP file as plain text, the password
will be visible to all.

This part is easy =)

Say for example, your web tree is similar to:
/bob
/bob/htdocs
/bob/htdocs/index.php
etc. Store something like 'db_config.php' as:
/bob/db_config.php
This way, it's not web accessible, so matters not if the PHP parsing
falls over. Simply use a require() call to "import" the info:
[ db_config.php ]
<?php
$sql = array();
$sql['host'] = 'localhost';
$sql['user'] = 'username';
$sql['pass'] = 'password';
?>
[ index.php ]
<?php
@require(dirname(__FILE__) . '/../db_config.php');

@mysql_connect($sql['host'], $sql['user'], $sql['pass'])
or die('Cannot connect to database!');

[ ... ]

?>


Is there any other way for PHP to authenticate itself to MySQL?

Not AFAIK.


Thanks in advance!

Hope the above helps (some?).

Regards,

Ian

--
Ian.H [Design & Development]
digiServ Network - Web solutions
www.digiserv.net | irc.digiserv.net | forum.digiserv.net
Programming, Web design, development & hosting.
Jul 16 '05 #2

P: n/a
In article <20*************************@WINDOZEdigiserv.net >, Ian.H
[dS]'s output was...
Say for example, your web tree is similar to:
/bob
/bob/htdocs
/bob/htdocs/index.php
etc. Store something like 'db_config.php' as:
/bob/db_config.php
This way, it's not web accessible, so matters not if the PHP parsing
falls over. Simply use a require() call to "import" the info:

Or, if you have a webhost who don't give you any space which can't be
seen by web users, create .htaccess and .htpasswd files to prevent people
from seeing the 'db_config.php' file.

See http://httpd.apache.org/docs/howto/auth.html for more info.

Jul 16 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.