Making passwords in PHP libraries unreadable.

PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!

Moderator: General Moderators

Post Reply
Farrier
Forum Newbie
Posts: 12
Joined: Thu Mar 25, 2004 10:39 am

Making passwords in PHP libraries unreadable.

Post by Farrier »

We have a large number of fairly technical users, some of which might be troublemakers.

We wish to give secure(ish) database access to PHP scripts they write.

For this reason, we have them log into the database using our own set of includable PHP libraries: all they need to do is specify what database they need to access, and the library allows or denies it on a case by case basis.

But there's a problem. They can, using their scripts, display the library files through the webpage. Which will then allow them to see all the passwords.

To work around this, we've done the following:

1) Prevented certain commands (php_info, get_included_files, get_include_path, ini_get etc) that will give information about includes.

2) Given them a chroot shell when they log in through ssh, to which the libraries, and the /etc/php.ini are invisible. The scripts will only work when run by the apache process.

3) Put the libraries in a directory within a readonly directory, like /usr/lib/readonly/php_libs, so that the directory cannot be found by any script that works by traversing the tree from the root directory, and adding that directory to the include path.

4) Giving the users a list of library names they can include, without paths.

5) Limited the directories the script can read from to the library directory, and /home, so that they can't read php.ini directly

My question is: is there a better (gentler, less nazi-admin) way to prevent users seeing the passwords in the libraries they are using?
User avatar
Weirdan
Moderator
Posts: 5978
Joined: Mon Nov 03, 2003 6:13 pm
Location: Odessa, Ukraine

Post by Weirdan »

Do you think that internal access management provided by the DB engine (MySQl, Postgres, MSSQL etc) isn't sufficient in your case?
Farrier
Forum Newbie
Posts: 12
Joined: Thu Mar 25, 2004 10:39 am

Post by Farrier »

Obviously :) Or I wouldn't have asked the question, nor gone to such lengths.

Users are not to be allowed to connect to the database directly, nor know their database passwords, nor use database accessing functions. So those passwords need to be hidden.

The same applies to the remote-exec libs, which use SSH to remotely execute scripts in restricted shells on remote machines: these too have passwords, which are similarly in need of protection.

By necessity, the libraries also contain various other pieces of information that is also sensitive, proprietary, confidential, or restricted for some reason or another.

The question I should have asked is:

"Is there a less nazi-admin way to prevent users seeing the contents of the libraries they are using?"
TheBentinel.com
Forum Contributor
Posts: 282
Joined: Wed Mar 10, 2004 1:52 pm
Location: Columbus, Ohio

Post by TheBentinel.com »

So you ask a question, then somebody changes it and answers the new question. That's irritating and frustrating, I know.

That having been said...

Is it possible to let your rogue coders have free reign in a test environment, then have only a single or few trusted individuals (you, maybe) copy their code into your production environment?

Is it the proprietary code you're trying to protect, or just passwords, logins, and stuff like that? If it's just passwords, the two-environment approach would take care of you.

If you absolutely need to keep your library code away from the eyes of your developers, then maybe you need to look into a SOAP sort of deal, where they communicate with premade functions via XML. That will totally kill your performance in comparison to using includes, but it could be made secure.

I think any answer you come up with on the includes is going to be bypass-able by a determined coder.
Farrier
Forum Newbie
Posts: 12
Joined: Thu Mar 25, 2004 10:39 am

Post by Farrier »

No, I don't think Weirdan answered the wrong question: he gave the best and most effective answer to the question as I'd asked it :) I just asked the wrong question.

Still, it seems the answer is "there is no canonical way of protecting library contents".

In which case, our current system, being relatively foolproof and fast, seems to be the best option :)
TheBentinel.com
Forum Contributor
Posts: 282
Joined: Wed Mar 10, 2004 1:52 pm
Location: Columbus, Ohio

Post by TheBentinel.com »

Farrier wrote:No, I don't think Weirdan answered the wrong question
I didn't mean Weirdan was off, I meant *I* was. I have way too much trouble keeping up with my own incompetance to even try to guess at anyone else's!
User avatar
Weirdan
Moderator
Posts: 5978
Joined: Mon Nov 03, 2003 6:13 pm
Location: Odessa, Ukraine

Post by Weirdan »

AFAIK there are no encryption tools for PHP to encrypt the libraries. So the best you could do about it is to separate the sensitive data from (possibly) malicious code by, at least, process boundaries. That's why I asked you whether the DB engine access management is sufficient. And I agree with Bentinel, web services (or some kind of proxies) looks like the most obvious way to do it.
Post Reply