[mySql] How to keep passwords secure

[Skijor]

I just finished writing my first php script that manipulates a simple
shopping cart on a mySql database. I started with an example I found
on the web. The example hardcodes the database server, name, user, and
password in a php include file. This file is then included in every
php script that needs access to the database.

How do I make this scheme secure? I assume this is ok as long as this
file remains inaccessible on the webserver. How to guard against
access?

[David]

Skijor wrote:

I just finished writing my first php script that manipulates a simple
shopping cart on a mySql database. I started with an example I found
on the web. The example hardcodes the database server, name, user, and
password in a php include file. This file is then included in every
php script that needs access to the database.

How do I make this scheme secure? I assume this is ok as long as this
file remains inaccessible on the webserver. How to guard against
access?

you could place it outside the Document Root or within a protected
directory.

[Skijor]

you could place it outside the Document Root or within a protected
directory.

I did just that and I created an .htaccess file in the directory to
allow apache to protect it. I'm still a little insecure tho'. I can't
seem to get to the directory using browser so why the need to protect
it with .htaccess? My guess is that there will always be the potential
to get into this directory via url hacks. Also I was able to dowload
the file via ftp from the command line. How to stop that?

[Skijor]

Skijor wrote:

you could place it outside the Document Root or within a protected
directory.

sorry. I mean I did both. Moved it outside the Document Root AND
inside a directory protected with .htaccess. Is this overkill?

[Gordon Burditt]

>you could place it outside the Document Root or within a protected

>directory.

I did just that and I created an .htaccess file in the directory to
allow apache to protect it. I'm still a little insecure tho'. I can't
seem to get to the directory using browser so why the need to protect
it with .htaccess?

PHP will occasionally break (when you're in the middle of upgrading it)
and the web server may at that time serve up .php files without running
them. By putting the file outside the document root, you're protected
two ways:

- If PHP isn't working, you can't serve the file containing the
file because it's outside the document tree.
- If PHP *IS* working, you won't serve the file, it will just
be run as PHP.

Also, the file should be readable by the user running PHP but not by
all users.

>My guess is that there will always be the potential
to get into this directory via url hacks.

That would be a pretty serious bug in Apache.

>Also I was able to dowload
the file via ftp from the command line. How to stop that?

Were you able to download the file via *Anonymous* ftp?
If so, you've got a big problem. If it's via non-anonymous FTP,
keep your password secure.

[mmckeon]

In addition to keeping your password secure, it's important only to
give the database user that you are using access the database from the
web the minimal amount of privileges it needs to work. This for the
most part your web database user should only have SELECT, UPDATE,
INSERT and DELETE. For things like a shopping cart you should even go
as far as locking things down on a per table basis.

For example, let's say you have a table with all your products in it,
the web user shouldn't have the ability to delete, update or insert
into this table. The web user is only going to list and view you
products so he only needs access to SELECT from this table. (This also
can HELP protect against SQL injection attacks)

On more thing to do is make sure that the web user you are giving
access to has a host name that it should be connecting to. For example,
webuser@localhost (and not webuser@%). This again would restrict people
from access your database from a server other than the one your
database is on. If your webserver and database are different machines,
do the same thing. For example: your web server's IP is
192.191.190.189, your database accounts that are coming from the web
server should be "we*****@192.191.190.189".

This can help minimize any damage that could be done should your
database user/password be compromised. This however is very unlikely if
you take the measure described above. (But if you are offsite and
uploading files via standard FTP, it is being sent in plain text). It
never hurts to be have redundant security measures.

Gordon Burditt wrote:

you could place it outside the Document Root or within a protected
directory.

I did just that and I created an .htaccess file in the directory to
allow apache to protect it. I'm still a little insecure tho'. I can't
seem to get to the directory using browser so why the need to protect
it with .htaccess?

PHP will occasionally break (when you're in the middle of upgrading it)
and the web server may at that time serve up .php files without running
them. By putting the file outside the document root, you're protected
two ways:

- If PHP isn't working, you can't serve the file containing the
file because it's outside the document tree.
- If PHP *IS* working, you won't serve the file, it will just
be run as PHP.

Also, the file should be readable by the user running PHP but not by
all users.

My guess is that there will always be the potential
to get into this directory via url hacks.

That would be a pretty serious bug in Apache.

Also I was able to dowload
the file via ftp from the command line. How to stop that?

Were you able to download the file via *Anonymous* ftp?
If so, you've got a big problem. If it's via non-anonymous FTP,
keep your password secure.

[Skijor]

very helpful. Didn't think to restrict write privilages to the cart
only. Such an obvious fact to overlook. As far as checking webser
IP's my database and webserver are hosted commercially and I don't
think database users will be arriving from the same webser all the
time.
mm*****@gmail.com wrote:

In addition to keeping your password secure, it's important only to
give the database user that you are using access the database from the
web the minimal amount of privileges it needs to work. This for the
most part your web database user should only have SELECT, UPDATE,
INSERT and DELETE. For things like a shopping cart you should even go
as far as locking things down on a per table basis.

For example, let's say you have a table with all your products in it,
the web user shouldn't have the ability to delete, update or insert
into this table. The web user is only going to list and view you
products so he only needs access to SELECT from this table. (This also
can HELP protect against SQL injection attacks)

On more thing to do is make sure that the web user you are giving
access to has a host name that it should be connecting to. For example,
webuser@localhost (and not webuser@%). This again would restrict people
from access your database from a server other than the one your
database is on. If your webserver and database are different machines,
do the same thing. For example: your web server's IP is
192.191.190.189, your database accounts that are coming from the web
server should be "we*****@192.191.190.189".

This can help minimize any damage that could be done should your
database user/password be compromised. This however is very unlikely if
you take the measure described above. (But if you are offsite and
uploading files via standard FTP, it is being sent in plain text). It
never hurts to be have redundant security measures.

Gordon Burditt wrote:

>you could place it outside the Document Root or within a protected
>directory.
>
>I did just that and I created an .htaccess file in the directory to
>allow apache to protect it. I'm still a little insecure tho'. I can't
>seem to get to the directory using browser so why the need to protect
>it with .htaccess?

PHP will occasionally break (when you're in the middle of upgrading it)
and the web server may at that time serve up .php files without running
them. By putting the file outside the document root, you're protected
two ways:

- If PHP isn't working, you can't serve the file containing the
file because it's outside the document tree.
- If PHP *IS* working, you won't serve the file, it will just
be run as PHP.

Also, the file should be readable by the user running PHP but not by
all users.

>My guess is that there will always be the potential
>to get into this directory via url hacks.

That would be a pretty serious bug in Apache.

>Also I was able to dowload
>the file via ftp from the command line. How to stop that?

Were you able to download the file via *Anonymous* ftp?
If so, you've got a big problem. If it's via non-anonymous FTP,
keep your password secure.

[Gordon Burditt]

>very helpful. Didn't think to restrict write privilages to the cart

>only. Such an obvious fact to overlook. As far as checking webser
IP's my database and webserver are hosted commercially and I don't
think database users will be arriving from the same webser all the
time.

If you have a public IP address, you can pretty much figure that
there will be attempts to log in to MySQL on that server at least
once a day - whether you've actually got a MySQL server or not. If
they find one that will let them try to log in, they'll try harder.