Protecting Database Details

[scross]

I've found that a huge amount of php apps use databases such as MySQL, and that just about all of these applications store the database information in a config file (eg. config.php, settings.php etc) . It's what I've been doing for quite a while and so I didn't really think much of it. It was only when my colleague, who is a web designer, told me that the file could be downloaded and the details taken.

Of course, what he was thinking is incorrect, because if the file is accessed directly the php code is simply parsed and the result (ie. nothing) is output. However, it got me thinking... if someone had access to the config.php file from within the server they could easily take the credentials and use them to log in to mysql and go nuts 🙂 .

I imagine this problem would come up more than expected, because on shared hosting, flaws in the set up can allow users to access each other's files (probably through a php script). You also sometimes get situations where you give a user temporary access to FTP so that they can upload some stuff. They could easily download any config.php files and then use them to connect to the database.

I admit that such situations are security holes in themselves and should be prevented, however I imagine there could be a way to secure database credentials. I did perform a few searches on Google but nothing useful came up. It turns out that the best advise is to store the config.php file outside of the web directory, but obviously this isn't always possible. So, I started working on my own way to protect the database info (most importantly the password).

I found there were a few possible ways to protect it, but they were all fairly insecure. The best way seems to be tying it in with an existing authorisation system.

For simplicity, let's imagine we have a php application that allows a single user to log in. The user details are stored in the config file (the password is obviously hashed). When the user logs in the system checks to see that the entered password is correct (by hashing it and then checking for equality), like always. The system then uses the password to decrypt the database password, which is stored in an encrypted form in the config file. The database password is then used to connect to the database. The encryption method could use an extension, or you could use your own implementation in PHP code.

Ok, now let's consider it as a full blown web app with many users. Here come all the problems. Firstly, we have to store all the usernames and hashed passwords outside of the database in a file. Obviously, a search in a file isn't the fastest thing ever so we need to figure out some way to speed it up. We also need to get round all those annoying file restrictions (safe_mode, open_basedir etc.). We also have the problem that all the users have different passwords. So, for each user we need their own encrypted code. Once the code has been decrypted it can be used to decrypt the database password.

The next problem is that any user's password can be used to obtain the database password. This is a big problem because a user could create their own account on the system (assuming such a thing is allowed) if they don't have one already, and then use their password to decrypt the generated code and hence obtain the database password. Unfortunately, I haven't been able to come up with a reasonable workaround for this problem as of yet.

Anyway, I was wondering (hoping) if any of you had suggestions, opinions or constructive critism.

[Weedpacket]

IM IN UR SERVER READING UR CONFIG.

No, seriously; if an attacker has got that far then the game is pretty much over. They can read the source code for the rest of your site as well, and probably modify it to suit themselves.

scross wrote:

Firstly, we have to store all the usernames and hashed passwords outside of the database in a file. Obviously, a search in a file isn't the fastest thing ever so we need to figure out some way to speed it up.

You could speed it up by putting the username and password information in a database 🙂

[scross]

if an attacker has got that far then the game is pretty much over. They can read the source code for the rest of your site as well, and probably modify it to suit themselves.

Ok, well let's assume they have read-only access to the files. Let's also say that this is not for a website but rather for an open source software package (eg. CMS). With open source software the source code is already known, and thus the vulnerability due to inside knowledge is already open. This means that the read-only access doesn't bring them that advantage. However, our database credentials are left in plain text in the config file and so they can use that to log in to the database. What I'm trying to do is come up with a way of protecting these database credentials (at least the password, anyway).

You could speed it up by putting the username and password information in a database

So you think the user check should occur after the database password is decrypted? The problem with that is that we need the user info prior to the decryption so we can obtain the code to decrypt, which we can then use to decrypt the database password.

I guess I might be a bit over the top with all this, but it always seemed illogical to have the database credentials in plain text in the config file.

[nebcode]

It's really not constructive to overthink security or to take more measures than is appropriate for the resources you have to protect. A PHP file, perhaps that requires a special constant to be declared before any values are instantiated is really the best you can do. It doesn't matter if it's off the web root or not.

if it's readable by the user that PHP runs under, then it's available to any PHP script that runs on the server. UNLESS, you run your PHP install in suexec, in which case PHP is usually running as the FTP account for that site.

You can't very well store database access details in the database if you need those access details to access the database in the first place.

If you have an upload script or some other script that allows an attacker to deposit a PHP script onto your server, as was mentioned, the game is pretty much over. I've seen machines totally taken over that way.

[scross]

Thanks for your comments.

It's really not constructive to overthink security or to take more measures than is appropriate for the resources you have to protect. A PHP file, perhaps that requires a special constant to be declared before any values are instantiated is really the best you can do. It doesn't matter if it's off the web root or not.

That's very true. However, security is also best in multiple layers, so if you could encrypt the database credentials, a resource of great importance, then it would be a step towards a more secure application. Maybe PHP could one day add functions to help with this kind of security.

if it's readable by the user that PHP runs under, then it's available to any PHP script that runs on the server. UNLESS, you run your PHP install in suexec, in which case PHP is usually running as the FTP account for that site.

Not much to say apart from that's correct 🙂

You can't very well store database access details in the database if you need those access details to access the database in the first place.

Yes, that would be just a tad difficult 😃 This is why I suggested storing the information in a file.

If you have an upload script or some other script that allows an attacker to deposit a PHP script onto your server, as was mentioned, the game is pretty much over. I've seen machines totally taken over that way.

Yep, I have to agree with you there. If they can write their own PHP scripts on your server then that's pretty much game over. However, the machine should still be under control if PHP is set up with the correct limitations.

[nebcode]

scross wrote:

Thanks for your comments.

That's very true. However, security is also best in multiple layers, so if you could encrypt the database credentials, a resource of great importance, then it would be a step towards a more secure application. Maybe PHP could one day add functions to help with this kind of security.

But where do you store the encryption key that only your application can reach? There isn't much point in encryption unless you are trying to protect it from someone who has already broken into your machine or somehow gotton an FTP or SSH login. Otherwise Apache alone can be used to assure that the file isn't accessible.

Yes, that would be just a tad difficult 😃 This is why I suggested storing the information in a file.

But what kind of file? Your application still has to be able to read it.

Yep, I have to agree with you there. If they can write their own PHP scripts on your server then that's pretty much game over. However, the machine should still be under control if PHP is set up with the correct limitations.

In suexec yes and perhaps safe mode, but some open source packages won't run under either. I have also seen suexec systems crack under heavy load.

[scross]

Thanks for the quick response and the good comments 🙂

But where do you store the encryption key that only your application can reach? There isn't much point in encryption unless you are trying to protect it from someone who has already broken into your machine or somehow gotton an FTP or SSH login. Otherwise Apache alone can be used to assure that the file isn't accessible.

The idea is that the password the user uses to log in is the encryption key. Of course, as I said in the first post, things get a bit more complicated when you have multiple users.

But what kind of file? Your application still has to be able to read it.

This is irrelevant. The file could be in XML format, CSV format or simply a use of the implode/explode functions or serialize/unserialize.

In suexec yes and perhaps safe mode, but some open source packages won't run under either. I have also seen suexec systems crack under heavy load.

That's true.

[nebcode]

scross wrote:

This is irrelevant. The file could be in XML format, CSV format or simply a use of the implode/explode functions or serialize/unserialize.

If it's off the web root, otherwise, you would have to set up Apache to not allow web visitors to access that type of file (hence the folly of .inc files), or the directory it's in. If it's common type then you are restricting other operations you might do with those files (like data dumps). Again if an executable gets uploaded your screwed.

[scross]

If it's off the web root, otherwise, you would have to set up Apache to not allow web visitors to access that type of file (hence the folly of .inc files), or the directory it's in. If it's common type then you are restricting other operations you might do with those files (like data dumps). Again if an executable gets uploaded your screwed.

No, all I would do is store the data in a .php file with <?php exit; ?> at the start of it. In all honestly this is what you should do with every data file you create to add an extra level of security.

[bpat1434]

You know, there's an easier way. You set up two database users. One which has only read-only access to all the tables in the database. Now, you can safely store your plain-text password in your config file and put that anywhere you like.

Now, in your example of a CMS we'd have to have a second database username with write/update/delete/read access. This login information would be stored somewhere in the database in an encrypted format. A specific key would be needed to decrypt it which would be kept either (a) outside the document root or (b) inside a file that is only readable by the php user.

Now, it's not the best security measure, but if someone does get their hands on your config.php, you can at least be "safer" in the fact that they'll only get read-only permissions 😉

Now, you know that most servers allow you to modify how things are interpreted. You can deny access to files named "config.php" from outside sources, or better yet, just add this at the very bottom (or top) of your config.php:

if(strpos($_SERVER['REQUEST_URI'], 'config.php') > 0)
    header('Location: ../index.php');

If you try to directly get to config.php via sitename.com/includes/config.php it will go to the index instead 😉 Keeps people's eyes out. And if someone reads that file from somewhere else on the system (i.e. a poorly setup server) then you need to have a chat with your host and find a new one (or get a dedicated server). Things like that shouldn't be allowed.

[scross]

You know, there's an easier way. You set up two database users. One which has only read-only access to all the tables in the database. Now, you can safely store your plain-text password in your config file and put that anywhere you like.

Now, in your example of a CMS we'd have to have a second database username with write/update/delete/read access. This login information would be stored somewhere in the database in an encrypted format. A specific key would be needed to decrypt it which would be kept either (a) outside the document root or (b) inside a file that is only readable by the php user.

Now, it's not the best security measure, but if someone does get their hands on your config.php, you can at least be "safer" in the fact that they'll only get read-only permissions

Thanks for your well thought out suggestion. The idea in itself is absolutely solid, however it does have the unfortunate downside of requiring a great deal of set up, and most users don't have access to anything outside their document root. If we used your idea of having a read-only database account, then you could quite easily implement my idea of having an encrypted key for each user, although as I think about it more, the security of this method is questionable at best.

Just to point it out, if we did do it your way, there would be no need to store the encrypted database username and password in the database anyway. You could just have it in a .php file protected by placing <?php exit; ?> at the start and then use the key to decrypt it and connect to the database.

Now, you know that most servers allow you to modify how things are interpreted. You can deny access to files named "config.php" from outside sources, or better yet, just add this at the very bottom (or top) of your config.php:
PHP Code:

if(strpos($_SERVER['REQUEST_URI'], 'config.php') > 0)
    header('Location: ../index.php'); 

If you try to directly get to config.php via sitename.com/includes/config.php it will go to the index instead Keeps people's eyes out. And if someone reads that file from somewhere else on the system (i.e. a poorly setup server) then you need to have a chat with your host and find a new one (or get a dedicated server). Things like that shouldn't be allowed.

Yeah I know about this. However, to make it truly secure, you need to place it at the start and add an exit; command immediately after it (within the if statement, obviously).

[bpat1434]

I still don't understand why you think you need security through obscurity. Just because you "make it harder" for someone to hack doesn't mean that it will never happen. So they can't directly get to your config file because you placed an exit() call (although I prefer the header()) so what? The point here is that the server needs to be set up correctly. If another domain can read stuff from your site simply by using [man]file_get_contents/man then there's a huge security hole that needs to be plugged in PHP and NOTHING you can do will stop that.

Encrypting a database password is probably not the best thing I've heard in terms of security. If you want security, encrypt the database itself. Not to mention, if they can get into your database, perhaps you should be less worried about the database, and more worried about your entire security schema from an FTP level on up.

If you use a good server like Apache, you can limit what files are viewed by the users. You could use a simple mod_rewrite like:

RewriteEngine On
RewriteRule .* index.php

And then just put in your index.php some simple redirect code for your main site file. There are much simpler ways to secure your items than just encrypting passwords.

For example, SMF uses a Settings.php file to store all the settings about the current forum setup. Yet if you go to their Community and remove index.php and replace it with "Settings.php" you will see a blank page. Nothing wrong with that. You can't get information from it if you don't echo anything out. Now, if you yourself code a parse-error into your config file, that's your fault and nothing you do (except deny it with .htaccess or rewrite the url with .htaccess) will stop it from being viewed (or the error); especially if you have a poorly set up server.

Just my $0.02.

EDIT: Oh, and it seems that you're just shooting down all the ideas that are generated here. Just because you place an exit at the top of the script won't stop someone with FTP or read access from wreaking havoc on your site. This is where server setup comes into play. You can store whatever you want wherever you want with whatever "security" steps you want. But if I can simply brute-force your FTP password (or that of the root server user) or simply use a file_get_contents() of a local path, security means nothing.

If you're not going to listen to anyone else here, I'll just shut the thread down. All the points given within this thread have been alternative ways to secure what you ask for. If you want real security, you need to get a dedicated server, and encode all your files with some program like Zend Guard, ionCube or NuSphere's program. Otherwise, use the Apache permissions or rewrite rules in .htaccess or put the document outside the web-root. Plenty of good web applications store their database username, password, host, and database name in plain-text inside their config or settings files and yet they don't get hacked. Just because it's plain-text doesn't mean it's insecure.

[scross]

I still don't understand why you think you need security through obscurity. Just because you "make it harder" for someone to hack doesn't mean that it will never happen. So they can't directly get to your config file because you placed an exit() call (although I prefer the header()) so what? The point here is that the server needs to be set up correctly. If another domain can read stuff from your site simply by using file_get_contents('../../../../../../someotherdomain.com/www/includes/config.php') then there's a huge security hole that needs to be plugged in PHP and NOTHING you can do will stop that.

I'm not sure you entirely understood what I was getting, probably because my explanation wasn't particularly wonderful 🙂 Firstly, I was saying that you should use exit; in addition to header() (just afterwards), just in case the browser ignores the header and the server sends all the data. Secondly, I was referring to a situation where another user on the same server has obtained read-only access to the files, which is surprising common with shared server solutions, especially free ones (which are not set up correctly, as you say). You are absolutely right when you say that the problem needs to be solved in the PHP setup, but I like to do as much as I can in my application to keep the data safe, even if that means trying to sort out a problem that is better fixed elsewhere.

Encrypting a database password is probably not the best thing I've heard in terms of security. If you want security, encrypt the database itself. Not to mention, if they can get into your database, perhaps you should be less worried about the database, and more worried about your entire security schema from an FTP level on up.

No, I never believed encrypting the database password was the best way to do it. In fact that's the exact reason I made this topic, for some extra ideas and a wider perspective. I am not concerned about a user reading the data, but rather having access rights that allow them to change the data. And yes, security should be considered on a grander scale then just protecting the database password.

If you use a good server like Apache, you can limit what files are viewed by the users. You could use a simple mod_rewrite like:
Code:

RewriteEngine On
RewriteRule .* index.php

And then just put in your index.php some simple redirect code for your main site file. There are much simpler ways to secure your items than just encrypting passwords.

As I said previously, security is best in layers. How about instead of using security method A OR security method B, we use both. Such thinking can help to make an application more secure.

For example, SMF uses a Settings.php file to store all the settings about the current forum setup. Yet if you go to their Community and remove index.php and replace it with "Settings.php" you will see a blank page. Nothing wrong with that. You can't get information from it if you don't echo anything out. Now, if you yourself code a parse-error into your config file, that's your fault and nothing you do (except deny it with .htaccess or rewrite the url with .htaccess) will stop it from being viewed (or the error); especially if you have a poorly set up server.

To prevent errors from showing the code, you could store the configuration details in your own data format and then open it and check for errors when the application starts. But as you say, the best way is to rewrite the url with .htaccess.

Oh, and it seems that you're just shooting down all the ideas that are generated here.

Relax, please 🙂 I created this topic in the hope of getting the ideas and opinions of all the php pros in the community, and your replies have all been great. I'm sorry if it seems like I'm shooting down the ideas you're giving me, and I must tell you that I absolutely did not mean to do that.

Just because you place an exit at the top of the script won't stop someone with FTP or read access from wreaking havoc on your site. This is where server setup comes into play. You can store whatever you want wherever you want with whatever "security" steps you want. But if I can simply brute-force your FTP password (or that of the root server user) or simply use a file_get_contents() of a local path, security means nothing.

Yeah I know, hence encrypting the database password so they can't get into the database. I think that if the unauthorised user has read-only access, then there are some quite substantial steps we can take to prevent that read-only access from giving them read-write access to the database. Ok, the methods won't be flawless and perfect, but in the world of security nothing really ever is.

If you're not going to listen to anyone else here, I'll just shut the thread down. All the points given within this thread have been alternative ways to secure what you ask for.

Once again, relax, and be safe in the knowledge that I am listening and have already made some major shifts in the way I am thinking about this problem, thanks to all the points supplied in this thread. I am only stating the disadvantages to generate debate and not to try to put others down and I'm happy to admit that my idea is no doubt covered in flaws. I hope you can see the difference and won't be nuking the thread 🙂

If you want real security, you need to get a dedicated server, and encode all your files with some program like Zend Guard, ionCube or NuSphere's program.

Ok, true. But:

A) Why encode an open source application? (that's the kind of app I was thinking of)
😎 If the application is going to allow the user to set the database password on install, then we're back to step 1.
C) These aren't supported everywhere.

Otherwise, use the Apache permissions or rewrite rules in .htaccess or put the document outside the web-root. Plenty of good web applications store their database username, password, host, and database name in plain-text inside their config or settings files and yet they don't get hacked. Just because it's plain-text doesn't mean it's insecure.

Yes I know that this is not one of the most common security holes, and it is in fact caused by having PHP poorly set up. This is why I was nowhere near 100% sure that the extra layer of security was truly logical, and hence brought my idea to your attention. It just seems that placing the database credentials in plain text in a config file makes the mysql authorisation system rather pointless.

By the way, thanks for your comments 🙂

[bpat1434]

Firstly, I was saying that you should use exit; in addition to header() (just afterwards), just in case the browser ignores the header and the server sends all the data. Secondly, I was referring to a situation where another user on the same server has obtained read-only access to the files, which is surprising common with shared server solutions, especially free ones (which are not set up correctly, as you say).

Well, let's define a "config" file for our purposes. For our purposes let's make it so that there is no data being echoed out. Only local variables are being set up for use elsewhere in the script. There are no echo, print*, var_dump, etc. calls anywhere in the script. So in this right, we can safely say that even if a browser ignores a header() call (highly unlikely) you can be sure that just a blank page is set. Also, note that you could send raw-http headers like 403, 401, or 500 which would give a specific response from the browser. I don't know of any browser that will actually ignore a 403, 401 or 500 call. Most major browsers (IE, FF, Safari, Opera) all support those headers as well as the header('location') directive.

As I said previously, security is best in layers. How about instead of using security method A OR security method B, we use both. Such thinking can help to make an application more secure.

Until those layers overlap so much that you can't remember why you're doing it in the first place 😉

Ok, true. But:

A) Why encode an open source application? (that's the kind of app I was thinking of)
😎 If the application is going to allow the user to set the database password on install, then we're back to step 1.
C) These aren't supported everywhere.

A.) Because certain things you may not want people to easily modify. Something like an API that you developed or whatever. It's a security measure....
B.) True..... so please read on 😉
C.) Typically they are and you just don't know it. Most likely Zend or IonCube is installed. I find it difficult that a server would go without the Zend Loader since it's free 😉

---

I guess another method would be to create a sort of "configuration" class which would hold "static" or "protected" variables. Now, you could implement several layers of security with this: (1) read-only database access for general use, (2) write/update/delete database access for select users, (3) no general "config" file with variables and definitions in it.

Something like:

class MyCMSConfig
{
    private static $db_read_user = 'db_username';
    private static $db_read_pass = 'db_read_password';
    private static $db_write_user = 'db_username2';
    private static $db_write_pass = 'db_write_password';
    private static $db_database = 'db_database_name';
    private static $db_host = 'localhost';
    private static $db_port = 3306;
    private $config = array();
    private static $instance;

public function __construct()
{
    $this->config['db']['read'] = array('user'=>$db_read_user, 'pass'=>$db_read_pass);
    $this->config['db']['write'] = array('user'=>$db_write_user, 'pass'=>$db_write_pass);
    $this->config['db']['host'] = $db_host;
    $this->config['db']['port'] = $db_port;
    $this->config['db']['name'] = $db_database;
}

static function getInstance()
{
    if(empty(self::$instance))
        self::$instance = new MyCMSConfig();
    return self::$instance;
}

public function addConfig($name, $value)
{
    $this->config[$name] = $value;
}

public function remConfig($name)
{
    unset($this->config[$name]);
}
}

Something as simple as that. Then all your configuration stuff is still plain-text so no need for encryption, you add the ability to have a read-only access so less chance of rogue MySQL attacks from "guests" (note you'll have to safeguard against attacks from authenticated users), An easily configurable configuration which is stateless (could be a good or bad thing), and this can be blown up to even read from a plain-text configuration file like an INI or an XML file with your site name and stuff in it.

Then with Apache (or IIS, LightTPD, etc.) you just need to deny access from all visitors to MyCMSConfig.php and MyCMSConfig.ini (or .xml) if you decide to use another config file. Heck, you could even just create a new method which the __construct() calls which helps populate the $config variable during instantiation.

[scross]

Well, let's define a "config" file for our purposes. For our purposes let's make it so that there is no data being echoed out. Only local variables are being set up for use elsewhere in the script. There are no echo, print*, var_dump, etc. calls anywhere in the script. So in this right, we can safely say that even if a browser ignores a header() call (highly unlikely) you can be sure that just a blank page is set. Also, note that you could send raw-http headers like 403, 401, or 500 which would give a specific response from the browser. I don't know of any browser that will actually ignore a 403, 401 or 500 call. Most major browsers (IE, FF, Safari, Opera) all support those headers as well as the header('location') directive.

Ok, good idea, now we know we're talking about the same thing 🙂
By browser I didn't necessarily mean one of the well known common browsers, the browser might be set up deliberately to ignore the location header.

Until those layers overlap so much that you can't remember why you're doing it in the first place

Occassionally that does prove true 🙂

A.) Because certain things you may not want people to easily modify. Something like an API that you developed or whatever. It's a security measure....
B.) True..... so please read on
C.) Typically they are and you just don't know it. Most likely Zend or IonCube is installed. I find it difficult that a server would go without the Zend Loader since it's free

A) Ok, yep. I'm with you on that.
😎 Will do
C) It is true that many set ups do support Zend ionCube, however many don't and users often don't have access to the php.ini file to change this.

I guess another method would be to create a sort of "configuration" class which would hold "static" or "protected" variables. Now, you could implement several layers of security with this: (1) read-only database access for general use, (2) write/update/delete database access for select users, (3) no general "config" file with variables and definitions in it.

Ok. As you say, the username and password for the read/write access is in plain text, so the original problem is not solved. However, I guess that you and previous posters are on the mark when you say that if FTP has been comprimised or they can read all your files then you're done for anyway. Nevertheless I like your idea and code, it would be a good extra layer of security. Of course it would require extra set up so you might provide as an optional extra feature.

[Horizon88]

You keep saying "it would require extra setup" to every idea they're posting here, when they're simple concepts that wouldn't take any more extra setup than creating a user and dropping in a single mod_rewrite line into an .htaccess file, even though your ideas all involve convoluted schemes to create custom formats fifteen directories out of your web root with triple encryption in a tar archive you decrypt on the fly. K.I.S.S, and less things will break.

[scross]

Horizon88 wrote:

You keep saying "it would require extra setup" to every idea they're posting here, when they're simple concepts that wouldn't take any more extra setup than creating a user and dropping in a single mod_rewrite line into an .htaccess file, even though your ideas all involve convoluted schemes to create custom formats fifteen directories out of your web root with triple encryption in a tar archive you decrypt on the fly. K.I.S.S, and less things will break.

Haha, yes you're right. They are simpler and don't take much to do. I guess I was looking for a script that would take 2 secs to install, but, as you say, my ideas completely break the K.I.S.S. concept.