Is there a commonly accepted way for a web based program to manage a password that it needs to access a mySQL database on behalf of multiple users?
One could always keep it in a file but in a suexec world the program that uses the password will always run under the user's identity and so keeping the password in a file that is readable by everyone is not really a good idea. I could keep it in the source of the program but that is not very good either. Yes I could encrypt the password but then I have get into a whole area that has to be done very carefully if it is to be secure. Besides if anyone really wanted it bad enough they could hack the program and extract the keys. OK call me paranoid.
....Sam
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
suexec will not allow a program to run as root. There is a way to setup an alias ID to have suexec run as root (thanks to ahoffman for that) but I really don't want to have anything to do with root.
I know that a lot of programs have the same requirement as I and I know that they do not run as root. Everything from eCommerce apps to discussion group software access a mySQL database and supply and ID and password.
The usual method is to create one or more MySQL users that have the most limited access to the database possible consistant with the needs of the web application. Those user names/passwords will have to be in the Perl, Php, etc., code that comprises the application, so that code needs to be prected to the maximum extent possible.
In the ideal case only SysAdmins actually have login rights on the web server and protection of the web source files is correspondingly easy. If users must be able to manage web sites, meaning uploading page code to the server those users can be limited to FTP where the FTP server doesn't use Linux account information for access and chroot's the FTP user to their site directory. The page code associated with other sites are in site directorys and thus inaccessible.
as said, there is (currently) no programatik way to hide the password needed by a program.
This problem has been discussed several times, all with no (useful) avail.
Protect your file containing the password, that's it.
Best is 400 for root.
If you access MySQL via a webserver, then it's most likely possible to use the password while the webserver starts (and makes a permanent connection), at least apache with mod_perl, fastcgi, php, tt2, etc. can do it. This way you even hide the password from application programmers.
well, another way I sometimes use, is as follows:
1. setup MySQL to listen on localhost:port only
2. in mysql.db use a very restrictive entry with IP and username and db, but empty password
3. setup ~user/.ssh/authorized keys with a valid key
4. connect to the host (with mysql) with ssh and local port forwarding
ssh user@remote -i /path/ro/secret.key -L4711:localhost:4242 sleep 1000
5. connect to mysql without password:
mysql -P 4242 -h localhost -u user <your-query.sql
This is more of security-by-obscurity 'cause you still need a passwordless ssh-key, to circumvent this you
may use ssh-agent (once at startup)
At least you database is as secure as the system which it runs on *and* the ssh-key (if passwordless).
Even if the passwordless ssh-key gets stolen, someone needs to find out where it is used.
I should have been more clear in that the target environment is a bog standard web host.
For applications that run as root, protecting the password from all but root is pretty easy as ahoffmann points out. Changing the mysql server listen on the localhost port only is not always an option. Hiding the ID and password in your code is what I suspect most people do. The problem there is that once someone finds out the password your application is compromised. You really need to create a random password and put this in a file. You can then protect the file from being read by other users on the system. To me this is not great but it sounds like this question has come up before with no standard answer. I did search but could not find any threads on this.
I will give this one a few more days.
> .. listen on the localhost port only is not always an option
no warries.
Let it listen on more than one IP, but protect the localhost as I said.
If the webserver and database server share the same system, it's even worse.
In such cases I use the vserver patch for the kernel, and run vservers on the same hardware: one vserver for one application (web, database). Some people may arg that this is what M$ does (to make money:), but it's much better, each such vserver only runs init + sshd + application, nothing more. A dozent vservers on a standard hardware are no problem ;-)
This also protects you that one root-compromised system compromises another one.
Using random passwords programatically makes things complicated, and if something fails you also may be lost in nowhere. Just keep in mind ...
I don't see why people suggested so complex things. The server based program is something like a php script or a cgi ?
The usual method is just to put the password in a configuration file readable only by the process running it like the apache user, outside the web server document root, and make sure you can't do more than needed if you have this password.. This is what almost every script does, like phpmyadmin.
Don't run programs as root, don't mess with roost suid programs for that, if the user can execute a suid program to get the password there is no difference than reading the password file directly, except you may have a big securiity hole if you don't know what you're doing with the suid stuff.
Use suexec to run a program as root just to protect your mysql password is really stupid. At least, if you do this, read the password at startup and give up root privileges as soon as possible. But no serious program do this, some programs like apache and bind start as root to bind to ports<1024 because it's an OS limitation.
If you have a program running on client machines which connect directly to the database, either each user is a mysql user and he enters his password when connecting or it's stored somewhere locally.
But I think you have a database design problem in this case.
If there is a single mysql public user for all, there is no ultimate way to hide/encrypt it in the program anyway. You cannot trust machines you don't control. If someone has the program and wants to find the password, assume he'll find it.
> The usual method is just to put the password in a configuration file ..
> .. make sure you can't do more than needed if you have this password..
hmm, remember this is a Security TA, and the question was "how to do it better"
We all agree, somehow, that this is undoable.
I also prefer KISS - keep it stupid simple - but passwords used programaticaly seem to brake this paradigm ..
What does it break ?
Some examples for common softs as packaged in debian :
For PHPMyAdmin, I have the password in /etc/phpmyadmin
For roundup, it's in $TRACKER_HOME/config.py
For cacti, in /etc/cacti
For mnogosearch , in etc/indexer.conf
It's probably the same for any webmail with a sql backend, or j2ee programs, this is just the usual way to do it.
You have to think at how the password could be compromised: an intruder needs the apache (or anything else running the process) privileges, and at this point you have bigger problems anyway. And whatever the method to get the password is, since your process needs to get it, the intruder can get it too once he has apache privileges.
I thought that suexec was just a suggestion from you, if your process (which language ?) is running with each user identity, you can just put these users in a group who's allowed to read the password file.
This doesn't change the problem, if the program can read a file or whatever to get the password the user can do it too.
If you don't want users to have a direct connection to the database, you can use an intermediate layer. It's more or less easy depending of your language.
For example in python you have pyro which is an object broker really simple to use, you request a distant connection object (initialized by another single multithreaded background process) and use it as if it was created locally.
It looks like this, similar to rmi in java :
import Pyro.core
Pyro.core.initClient()
connection=Pyro.core.getPr
connection.execute("select
> .. this is just the usual way to do it.
that's the defect.
If the password can only be read by the server (nobody, wwwrun orwhatever running httpd), a broken application does not compromise the databse security.
Just think of XSS, path enumeration, etc. which might be possible in the application (and PHP applications are far, far, very far away from being secure, unfortunately).
We may discuss if the application or the OS is more likely infected by whatever.
We don't need to talk about getting root-access somehow, then anything is lost. But if the application is seperated from the web-server (httpd), then it's one more level to break.
Yes, my suggestions are something like a proxy.
It's like you go to the bank getting a withdrawal: you cannot go to the vault yourself, even the building is save and protected.
I love a good and lively discussion and there have been some interesting ideas that have come forth. Let me refer back to my requirements and then clarify them a bit more.
1) mySQL
2) A single database for multiple users
3) SUEXEC
As I have mentioned before I target a web-hosting environment where I cannot make too many demands on the host. Web hosts typically use SUEXEC to keep user's away from each other. As long as you have one database per virtual domain / unix user, a password in a file for each user with 600 is grand. I think this is the case with a lot of applications.
In my case I want to have one single database for all domains / users. This means SUEXEC will run the application under the user identity associated with each virtual domain. Therfore the password file would have to be readable by everyone. I need SUEXEC because I have to manipulate the user’s files. Even if I did not, once SUEXEC is enabled it forces all CGI to run under a user’s identity rather than that of the web server. I have no choice as to whether the web host runs SUEXEC.
I have solved this problem for the project at hand by piping my request to a daemon running as root. The daemon can suid to the user to manipulate files. I did this mainly for performance but it looks like I would have had to do it anyway for security reasons. While all of this is fresh in my mind I am fishing for a simpler solution that I might use in other similar projects.
> what's the web server doing if the final user uses this application ?
Sorry Alain, I am not understanding your question.
The application is a CGI script written in Perl. It authenticates the user (using FTP/POP), fools around with the mySQL database and reads / writes files into the user's public_html directory. It is a site builder tool.
if the application is the master (knowing all passwords), why having a password for each user?
One password for the application seems to be enough.
Your cgi, language doesn't matter, then can access the database, and calls a suexec'd script/pogram to store the files in the user's public_html directory.
The application does not know any user passwords. Each user of the application is a valid unix user. The user is prompted for a unix password. This ID/password collected from the user is authenticated via POP. Having authenticated the user, the application feels confident to access the user's files. After all it is running under the identity of the user. With suexec you have no choice in the matter. Your script will run under a real user's identity.
The problem is that there is no way to keep the database password secret since the script will be running a number of different identities.
> .. user is prompted for a unix password.
Is this done via POP?
Anyway, how about following idea:
1. cgi prompts for password ina HTML form (returned via SSL)
2. cgi authentificates against OS (/etc/passwd or whatever)
3. cgi SUEXECs with valid user
4. cgi (now with effective uid of user) authentificates with same password against mysql
password is now known by the (human) user only, but used in clear text in the cgi, so you need to prtect the cgi (500 etc.)
'caue MySQL has it's own authentification schema, you can connect the databse in step 2., then use this connection in step 4. (see mysql's --socket option)
> 2. cgi authentificates against OS (/etc/passwd or whatever)
Only root can authenticate against /etc/passwd since almost everyone runs with shadow passwords
> 3. cgi SUEXECs with valid user
You might want to take a look at the SUEXEC docs. It is not an API call and therefore a step that a CGI takes. When mod_suexec is running all CGIs run on behalf of a user
> 4. cgi (now with effective uid of user) authenticates with same password against mysql
As I said I need to have one database for multiple user's. If I gave everyone an ID and password against the database then anyone would be able to get at the database.
I think it is time to wrap this up. I am going to award the points to alain because he actually set things straight in the first post and pretty much said that there was no way to do what I wanted to do. I think the rest of the dialog simply confirmed that. Also the object broker technique while not as automated in Perl is essentially what I ended up doing (daemon)
Business Accounts
Answer for Membership
by: RedimidoPosted on 2004-03-08 at 15:16:40ID: 10545411
the file where you should store the password must be only readable by root, with 600 permissions. your suid program will run as root and then that program will access the file to read the password.
this way final user is not able to read the file, while the program once running can.