database user/pass protection

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

User avatar
Burrito
Spockulator
Posts: 4715
Joined: Wed Feb 04, 2004 8:15 pm
Location: Eden, Utah

Post by Burrito »

Ambush Commander wrote:::Puts on Tin Foil Hat::
lol :lol:

too late, they've already got you...and me :?
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

The point of the solution offered in the article is the following: If you want to know the db credentials you have to be root... And trust me, someone who can gain root... Doesn't even need your db credentials :p

So, not even you or the www daemon need access to the file. All you have to take care of is avoiding print_r'ing $_ENV :)
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

Pyrite wrote:I did read it, and it seems it is focused on remote exploits. I am concerned about a cracker having access to my server, through whatever means and viewing my config.php to find the db credentials and viewing my database. Has nothing to do with remote exploits.
It depends on what you mean by a cracker "having access to your server". If you mean he can read some files, but not all, then you'll need to specify which.

If however, he can read *all* files on the server, then you are totally screwed no matter what, because he can just read the db files directly, or the password file, or.. Any number of other things.

Thats why the #1 recommendation in security when your box is "rooted" is rebuild. Because you can't be certain of anything being secure after that.

Security is about balance: Balancing the risk with the cost of protection.
Pyrite wrote: The fact of the matter is, my db credentials are sitting there on my server in a plain text file. That is not good! Even Windows doesn't do that. :wink:
Yes, windows does, sortof. (Long story to that - it involves the /etc/hosts file, and the windows update mechanism).

Remember, that plain text file *IS* protected. First, its got ownership permissions - its not world readable. Second, you can put it outside of your webtree.

Thats a pretty reasonable amount of security. Just what are you trying to protect, a banking site??!
User avatar
Pyrite
Forum Regular
Posts: 769
Joined: Tue Sep 23, 2003 11:07 pm
Location: The Republic of Texas
Contact:

Post by Pyrite »

:cry:

Ok, I have a Windows Server 2003 Web Server (Apache/PHP) and a "seperate box" for my database (MySQL). I guess either nobody knows what I'm asking or nobody knows the answer. But my config.php looks like this:

Code: Select all

// The Database Parameters
$dbhost     	= "192.168.23.56";
$dbuser     	= "lox1";
$dbpass     	= "a$42ksL2Mj;#2Hi";
$dbname     	= "loxley";
$dbtype         = "mysql";

// Dont edit past here (ADOdb)
$db = NewADOConnection($dbtype);
$db->debug = false;
$db->Connect($dbhost, $dbuser, $dbpass, $dbname);
So, my point is if somebody can view this file, through whatever means, either by sitting down at the machine physically, or hacking in, they can see what is needed to connect to my database and do a SELECT * on all my sensitive data. That is the problem. Simply put, I don't like that fact that my database credentials (what I mean by that is user/pass/host) are in a plain text file (not encrypted or hashed), therefore human readable.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

External database! Ah... that could be a problem. Have you limited queries to the IP your PHP server is on (that way, they'd have to execute scripts off your server to mess things up)?

Furthermore, you really shouldn't have too much sensitive data on your databases. Passwords can be hashed, SS numbers, well, I don't know why you'd have those, IP addresses aren't too bad (I guess...)

Let's look at it this way. At some point, we have to talk to the database. The database goes, "You need a password." Now, obviously, you're not opening the connection, so the program that does the connections has to know the password.

Now, during the communication, we could use some secure connection to make sure that user/pass doesn't get intercepted, because we have to send it to the db server. But let's say they've compromised the database server. They have no clue what the user/pass is, but they've "rooted" the system, and they have the ability to manipulate the secure connection.

As soon as your application comes along and sends the user/pass, they've got it, encrypted on your server or not.
User avatar
Pyrite
Forum Regular
Posts: 769
Joined: Tue Sep 23, 2003 11:07 pm
Location: The Republic of Texas
Contact:

Post by Pyrite »

sorry to say this, but just forget it!

(throws his hands up in the air) :evil:
User avatar
thomas777neo
Forum Contributor
Posts: 214
Joined: Mon Mar 10, 2003 6:12 am
Location: Johannesburg,South Africa

Post by thomas777neo »

You could probably encode the config.php file with something like ioncube.
Which is inexpensive. So if I hacked into your server and looked at your php files. They wouldn't be human readable. Then I would have to decrypt the code, which would take some skill. Nothing is 100% secure, but you can make it a pain in the ass for someone who is trying to do something malicious.

Hope this helps.

You could record the values encrypted in the config.php. But, if your username or password changes. You would have to encrypt the values then copy it back. Whereas you could only keep the encoded source on the server, then change the values in your non-encoded source. Encode the file, and upload it.
Syranide
Forum Contributor
Posts: 281
Joined: Fri May 20, 2005 3:16 pm
Location: Sweden

Post by Syranide »

timvw wrote:So, not even you or the www daemon need access to the file. All you have to take care of is avoiding print_r'ing $_ENV :)
But that is pretty much the same, anyone with access to that user can print $_ENV ... or am I missing something? (With other words, it can be just as easily done without root, just that now you have to make a script in 1 sec)

EDIT: and if you could commonly see the credentials you can just as well create that script, unless you really made something dumb with the credentials-file.
User avatar
thomas777neo
Forum Contributor
Posts: 214
Joined: Mon Mar 10, 2003 6:12 am
Location: Johannesburg,South Africa

Post by thomas777neo »

What does $_ENV have to do with the config.php that he was originally talking about?
Syranide
Forum Contributor
Posts: 281
Joined: Fri May 20, 2005 3:16 pm
Location: Sweden

Post by Syranide »

timvw wrote:The point of the solution offered in the article is the following: If you want to know the db credentials you have to be root... And trust me, someone who can gain root... Doesn't even need your db credentials :p

So, not even you or the www daemon need access to the file. All you have to take care of is avoiding print_r'ing $_ENV :)
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

I've never talked about a config.php

I asked to read http://shiflett.org/articles/security-corner-mar2004... Perhaps it's a bit hard to grasp at first... But after a while you will see that it's really different than a config.php..

With config.php the www-daemon needs access to the file. With the file, when apache is started (at this moment apache is run by root, and thus has access to _all_ files) and afterwards www-daemon doesn't need (and shouldn't have) access to the file...
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

timvw wrote: With config.php the www-daemon needs access to the file. With the file, when apache is started (at this moment apache is run by root, and thus has access to _all_ files) and afterwards www-daemon doesn't need (and shouldn't have) access to the file...
That makes several assumptions, to wit:

- httpd.conf can be edited to include that specific file (something very few virthosting customers can get)
- Apache isnt chroot'd (OpenBSD, some FreeBSD, and some linux distros do so)
- The file permissions (which arent listed in the article) have to be 400
- The apache server configuration has to be set to allow user includes (rare) AND allow setenv settings - which is even more rare, and more insecure.

All told, its pushing the problem from the very reasonable filesystem security level to the apache server config security level, which is not at all reasonable.

Stick with the common solution - set your filesystem permissions right, and get your virt host to seperate users with chroot/safemode/openbasedir. (which is actually fairly common now)
Post Reply