secute database login with php

[chandrika]

When connecting to an SQL DB in a php script, is it secure enough just to put the DB username/password etc in a separate config.php file in the same folder and then put a php require for that in your script.

Or what are the usual ways to make sure that the info in a config.php file, with UN/PW etc, are secure?

[kgun]

Security by obscurity is not secure at all. The best is to make

1. A database connection class.
2. An authentication class.
3. A session class.

Introduction and litterature:

1. Introduction Object Oriented Programming in PHP
2. Book The PHP Anthology: 101 Essential Tips, Tricks & Hacks, 2nd Edition - SitePoint Books

[chandrika]

That book looks good, I have been looking for a useful php ref book, thanks.

I will check out the first link tomorrow, see if I can hide the UN/PW that way.

[vwickam]

Additionally, I would suggest if you have any username/pw in a config file, you should secure the file using unix file permissions.

[edhan]

Normally config.php requires 666 permission to make changes. Thereafter, you can set it to 644. At the same time, you may want to rename the config.php to something else like 871asfeljs.php so that it will not be easily guess.

Hope this helps.

[vwickam]

A file setting of 600 would give you read and write access to the file, and giving group and world no permissions at all. This is how I always set config files.

You set the file permissions using chmod if you have shell (telnet or ssh) access to the server. The syntax would be:

chmod 600 config.php

If you don't have shell access to your server, the is a good chance that you can change file permissions using the control panel on your webhost.

If your program can't read the file with that setting, than you may have a file ownership issue. There is a unix command to change ownership of files as well (chown), but you might be best to just place a trouble ticket with your webhost detailing the situation.

Thanks,
Vi

[speed]

Creating classes won't help at all in protecting the username/password as it still has to be placed in the PHP somewhere.

If you are worried about your settings being access from the web if PHP fails then just put config.php outside the web root.

Or try putting your database info in .htaccess e.g.

SetEnv mydbuser theuser
SetEnv mydbpass thepass

Then in the PHP access it with $_ENV['mydbuser'] and so on.

If you are worried about others on the server accessing your information then the above won't help, you'll need to do one of the following.

If your host runs PHP via suPHP or the like then as already said setting permissions to 600 works, but if using use mod_php you'll probably be blocking access as PHP normally runs as nobody or the apache user.

Or you can pass all the PHP through ionCube which gives you encrypted PHP files. Good luck trying to decipher that if you encode with everything on. Just make sure you keep an unencoded copy for future work. Note: You have to encode more than just the config file for this to work.

[chandrika]

I am not worried of anyone else on the server accessing DB info, just public and I wasnt sure how secure such referenced files in scripts were. As although when php is executed such things do not show in the source, I thought maybe someone could download the actual php file somehow and simply read it.

As you say, setting permissions to 600 on my server does indeed block access for my script that includes the file as well.

I have settled for putting it outside the web root.

The ioncube info is interesting, I have ioncube that came packaged with a script I bought once, never looked much into it.

[speed]

Originally Posted by chandrika

I am not worried of anyone else on the server accessing DB info, just public and I wasnt sure how secure such referenced files in scripts were. As although when php is executed such things do not show in the source, I thought maybe someone could download the actual php file somehow and simply read it.

Only if something goes wrong with Apache or PHP is the source possibly available in the visitors browser.

As you say, setting permissions to 600 on my server does indeed block access for my script that includes the file as well.

You're probably using mod_php so all your scripts run as the Apache user.

The ioncube info is interesting, I have ioncube that came packaged with a script I bought once, never looked much into it.

There's two parts to ioncube, the encoder which encrypts the script and can optionally lock the script to a single server, and the runtime which is the bit you would have had delivered with the script.

[wige]

Putting the file outside the web root is generally the best method, as it prevents the file from being downloaded by a user. If you don't have a folder outside the web root (you can only FTP to the web root) you can create an "offlimits" folder very easily. Simply create the folder in your root, named "lib" for example. Then, add the following lines to your .htaccess file:

RedirectMatch 404 /lib/.*

Any request for a file in the lib folder will get a 404 not found response, preventing download of the file. This also hides the folder very effectively by giving the user a correct Not Found message. If you use a Deny All method, the user will get an error 403 Forbidden message, which lets the user know the folder actually exists.

Changing of permissions is not actually intended to prevent someone on your server from reading the files. The purpose is to prevent what is known as a directory transversal attack. Imagine you have created a script that displays an image to the user, depending on some user selected variable. An attacker might be able to cause that script to serve the contents (unexecuted) to the browser. The workaround, if I recall correctly, is to turn off the write bit, but leave the file executable. Most shared servers execute scripts as either 'apache' or 'php' (depending on how Apache sends the file to the PHP interpreter), but the owner of the file is usually 'ftp' or your username, depending on how the FTP software is configured. This means that the file needs to be owner read and writeable, other executable and world executable. That way, you can upload new copies of the file, and Apache can execute the file but not read it. (I think this is correct. It has been a long time since I have dealt with this.)