How to hide MySQL user and password in php code?

[samansk]

When I write php code to connect to MySQL like this
<?
mysql_connect('localhost','useranme','password');

Have the best way to hide or encrype user name and password in this case.?

 

[Inssider]

What do you mean by hide? If you're concerned about the end user being able to view your username/password through their browser, then don't worry, it won't show up at all. Everything's processed server-side.

 

[jamiebecker]

I think this is a good question and a good idea and hadn't occurred to me until you brought it up. A possible vulnerability is that if you host your site on an ISP's server, they're probably running mod_php and not the CGI version because it's faster. (That's the short version.) However, your web directory is probably readable by the web server (of course) and hence someone else's php script could read all the web directories (the php source files, not the html code) on the server and then grep them for passwords.

Do I have your attention yet?!?!?!

The bad news is there's no way around it. Since your database password has to be in the open, everything's wide open. There's no way to seal it that I know of. I was thinking you could do something like mysql_connect(&quot;localhsot&quot;,&quot;username&quot;, my_decrypt_function(&quot;askd2u30u12&quot) but obviously someone else would just have to do the same thing to get the password -- or maybe not even bother, just use your own program to extract the data they need.

My recommendation is that if you're storing credit card numbers or something sensitive like that, you need to either outsource it to a provider you trust or get your own server and learn a lot about security.

Perhaps a possibility is self modifying code, but I think the bottom line is that it would be very, very difficult if not impossible to seal that data off from other users on the same webserver process. The bottom line is that you really could never be sure it was secure -- so if you care that much, at least get a dedicated server some place. Or, better yet, just swallow the data after you've memorized it. ;-)

 

[Guest_imported]

Hey, I have the same problem, and very many do, though I guess not many enough is aware of the problem. I have been thinking of using Perl with setUID to extract the password from I file with only owner-read priviligies. Like rw-------. But I couldn't make this work. If anyone find a solution let us know.

Excuse my very bad English

 

[rycamor]

Don't forget that PHP has access to some other very useful variables, for example $PHP_SELF or better yet, $SCRIPT_FILENAME. (can some of you see where I'm going with this?) If you encrypt your password in such a way that you can ONLY decrypt it with a certain $SCRIPT_FILENAME value, then the only way to get to the database is to run that *particular* script and no others.

Now you remember from the above post, that yes, encrypting and hiding is one thing, but what about someone just running your script and extracting data with it?

First, you place this script in a directory that is readable (not writable) only by you and the 'nobody' PHP user just for basic protection.

Second, you imagine just how another user would go about abusing this script. Set your script up so that you will be warned by email (or some other method) if anyone is doing anything different from a standard operation.

Third, you make it so that script will only run to save data, and to display data only in carefully limited ways. Any script that you as an administrator want to use to actually view all your data, should be running in secure server mode (

https://)

and require browser-based password entry, so the password does not even reside on the server.

Of course this will take some work, and nothing residing on a server where there are other users is going to be completely bulletproof, but these methods should take some work to crack.

 

[Hokey]

If you use the Zend Encoder on your PHP files, then there is no way for unauthorized users to look at any of your code including you MySQL names and passwords. The encoder itself can be a little pricy ($2400), but if you code and/or passwords are important it is more than worth it.

Personally I use the Zend Developer Suite because its cost is so darn cheap. You get the Encoder, IDE, and Launchpad for $600 a year (I also think that there is some professional tech support included with the suite). It is a heck of a good deal for a securing your code and passwords(not to mention supporting the best server-side scripting language for further development)

 

[rycamor]

Yeah, the Zend encoder is definitely the way to go, if you can do it. In this specific situation, though, it would be no help unless the ISP agrees to install it on the server. You can't just use the encoder on your script without having the encoder system installed by 'root' on the server (AFAIK).

 

[jamiebecker]

I agree -- the encoder is the way to go.

One thing about your solution, rycamor, is that assuming someone had the ability to write a php script on the server (and I think that's what we're talking about -- other users on the same server) they could merely write a php script to read any file in any directory that's accessible by nobody since the web server/php_mod is running as nobody, thereby getting the password that way. It's relatively easy to prevent your password from being seen _through_ the web server (ie from an http client) but much, much harder to prevent it from being seen from a user on the system. I think the encoder is a good idea.

Your ideas about PHP_SELF are probably worth thinking about in more detail, but as you described it it looks easy to get around. If someone has access to your script directly, with a hashed value in it, they can just copy/modify/run the script and override the $PHP_SELF variable. The problem is really the hash -- if it's visible at all, it almost might as well not exist because I don't think there's any information that you have the the cracker wouldn't have. That's the answer, really; if you could figure out what you know that he doesn't know (and don't forget both of you can run as nobody) then it would work. But I don't think there's any info that you could have that he wouldn't.

Essentially the encoder moves the whole weak point into the apache server rather than in your code. It'd still be possible to crack if you had user-level access to the box, but a heck of a lot more difficult. They'd have to decode your code from within the apache server. Tough to do and I don't know enough to really say how tough.

Note that the situation can completely change with CGI and suexec but I'm not very familiar with it so I won't comment further.

 

[jamiebecker]

The way I see it, if you have big concerns about this,
you can do the following:
1) Get your own server and tightly control user-level access to it. Most of these cracks take advantage of user or nobody-level access.
2) Buy and use the encoder.
3) Build and run your own Apache daemon as a different user and chown the sensitive files/directories to that user and chmod 700 or 770 the sensitive files/directories. You could, for example, run it on port 8010 and just redirect users to your normal port 80 site to it.
4) Run CGI and use the suexec feature so that your cgi runs as you instead of nobody. Again, I'm really not that familiar with this method.

 

[Hokey]

To get encoded PHP files to run on a server the only thing needed is the Zend Optimizer, which is free and 'should' be part of any PHP installation.

 

[darko]

If your php files are in the &quot;work&quot; directory, do this:

chmod 711 work

this will prevent sneaking in your &quot;work&quot; directory both from browser (client side) and &quot;telnet client&quot; !
What I mean is that whoever has telnet access to your provider server, and those are people who are using same services as you with your provider, they can do this:

cd / (now they are on the root)
find * -name &quot;*.php&quot; | grep mysql_connect (or something else)
when they find where is the file that contains usr/passwd combination, they will do this:

cp /home/users/...../..../..../..../work/conect.php .

that is if your directory &quot;mode&quot; was 755.

when mode is 711, find -name ...... will return &quot;permission denied&quot; for dirs with 711

So:

1. from the browser side, user cannot see what is usr/passwd combination when it is hardcoded

2. but from telnet side, it is possible using way I described.

 

[rycamor]

jamiebecker - yes, you do have a point. I think with a bit more craftiness, it might be possible to elude someone from getting the information with that method, but it would be a lot of work to set up.

I was thinking, though, the real answer is lower in my previous post. You should have *two* users in your database. The username/password that can input credit card data and purchase information *only* has INSERT access to the corresponding tables in the database, nothing else. That's the only information your any of PHP scripts have about the database. Any script that allows the site owner/administrator to SELECT, ALTER, UPDATE or CREATE would not have the username/password, or table information in it at all, but would simply receive those variables as user input (in SSL mode) to view and edit data.

If you use that scheme, then the worst a cracker could do would be to put junk data in your database. Still not great, but a completely different kind of problem.

 

[jamiebecker]

Rycamor, I think that's the best idea we've heard; the only possible difficulty is that it would require the cooperation of the mysql admin, which in a shared-co-hosted situtation (that is what we're talking about, right?) might be tough.

Another possibility is to just not ever store the credit card numbers at all but to use them and delete them. In most cases, it's only really necessary for automatic recurring purchases. Many of the online stores I'm aware of request you to reinput the credit card info every time. As a matter of fact, you could retain all info -except- the card number and it'd be pretty secure. Even if someone cracked you (and hey this can happen to the most paranoid, especially on non-UNIX/Linux boxen, and in most cases the public never hears about it if possible) they would get a useful but lower-impact set of info. This might not be applicable to your situation, but it's the way to go if at all possible. I personally feel a lot better when I know a store doesn't retain my credit card info.

 

[Hokey]

Not storing the CC# would sound the best to me (especially from a customer standpoint).
I am drawing up a project outline for an online store for the bookstore at the college I work at and we have been mulling the CC# problem over and over. Being in a college enviroment, many students in the dorms try to hack our systems on a weekly basis, so we have been a little hesitent about the idea of storing CC# for the online bookstore purchases.
Dosent PHP have support for several CC processing (Payflow and CyberCash I think). I am not sure how these processes work, but I would think that you could accept the creditcard, process it, and then just store the CC acceptance # in the database. Would this work or does Payflow/CyberCash do something completely different?

 

[notyou]

Phorum, a PHP-based message board recommends wrapping your scripts:

What &quot;wrapping&quot; means is to have the .php scripts executed under your userid instead of the web server's default &quot;nobody&quot;. This is because, no matter how well you hide the script (e.g. in a directory that's chmod 711), any user on your server could create a script that is run as &quot;nobody&quot; by the web server which could alter or remove your config files. This is especially bad on a shared server because the config file could also give the user access to your database passwords which, in many cases, will let them mess with more than just your Phorum tables.

Further, they give some details on how to wrap php scripts, etc. Grab the source at

http://www.phorum.org

and read the details in docs/security.txt

--Darryl

 

[notyou]

Oh wait, here's a good tutorial on php-cgiwrap from my ISP, pair.com:

http://www.pair.com/pair/support/library/systemcgi/php-cgiwrap.html

 

[Guest_imported]

Hi,

what if you store the passwords and usernames in an &quot;include&quot;-file which is located in a .htaccess-controlled, or otherwise protected directory? Then you'd use the &quot;include()&quot;-function (maybe &quot;include_once()&quot in the main file.

The question is whether the include()-function gets executed or not when someone uses a script to read the source code of the main file. I guess I won't, so it will work.

The main file must have access the &quot;include&quot;-file, of course.

 

[jamiebecker]

Hi Asdigwe,

That will only protect against remote Web users, not other users on the system. The .htaccess files only protect against remote Web users, so a user on the system could still easily access the include files.

-Jamie

 

[rycamor]

Maybe someone can clear this up for me:

As I understand it, even if PHP is an Apache module running as a trusted user, such as &quot;nobody&quot;, it is possible to keep users from executing PHP code that will read files in other users' directories. This is supposed to be accomplished by setting the php.ini file to include some variation of

safe_mode = On
doc_root = /usr/local/apache/htdocs
user_dir = /home/*/public_html

Theoretically, this should make a lot of the other discussion here moot. If Safe Mode is turned on at your hosting service (an easy enough thing to verify), then no user should be able to read any scripts by other users, even though they all run as user &quot;nobody&quot;. In fact, they cannot use PHP to access any filesystem info outside their present DocumentRoot directory.

Actually, according to the article I post below, setting up PHP as a CGI-mode application can introduce more security problems, rather than fixes. The PHP Apache module runs under the Apache security model, so you are taking advantage of all the thought put into designing a secure webserver.

The following link deals with exactly what we have been discussing here:

http://onlamp.com/pub/a/php/2001/03/29/php_admin.html

Can anyone poke a hole in this one?

 

[andreas57]

i hope i'm not imbarissing my self to much but how do you want to edit or read a php-script on a web-server without haven write-access to it? andreas owen
aowen@arcade.ch