I need to overcome limits on my ISP's PHP environment - php

Question

I'm stuck with PHP 5.4 and a single database userid because of defects in Comcast's business hosting implementation. The userid problem means that the same credentials I use to manage a MySQL database must also be used while handling requests from ordinary users. I have control over who can login as an ordinary user by delegating the creation of ids to a group of trusted users who will communicate to the ultimate end users the URL they will need to login to the app. And, although the server is running Apache, it ignores an Authorization header.
Positing that some hacker might defeat the HostWays Unix server's file system protection and read all of my PHP source code, I need to avoid having the database credentials appear in the MySQL connect calls in my PHP source. I've come up with the following scheme for encrypting the database credentials, and I want to be sure that the scheme will actually be effective.
I will define a global variable named $credentials in a configuration file. I'll generate the value in my development environment with this code:
$cipher = "AES-128-CBC";
$secretkey = …; // it's a secret!
$secret = openssl_encrypt("$dbuser:$dbpass", $cipher, $secretkey);
Remember, I'm stuck with PHP 5.4, and I wasn't able to get past mysterious errors in openssl_decrypt when I used an initial-value in the encrypt/decrypt calls. Anyhow, this much of the code at least works.
My PHP app can be accessed two ways: one is via an XML payload in a POST transaction coming from a C++ desktop app; the other is via an ordinary URL in a GET. Both methods will use HTTPS. The XML schema calls for an authentication parameter that supplies the $secretkey.
The URL for the GET transaction will be used by general users from a browser. It will include a secret= parameter that encodes both the user's login id and the $secretkey. I will generate the secret= parameter during the transaction that adds the user to the list of authorized users:
$cipher = "AES-128-CBC";
$key = "Fortune42Cookies!";
$secret = openssl_encrypt("$username:$secretkey", $cipher, $key);
In this code, the $secretkey is left over from when the trusted user who is adding this end user to the list logged in. The corresponding decryption code used when the end user logs in is as follows:
$cipher = "AES-128-CBC";
$key = "Fortune42Cookies!";
$clearsecret = explode(":", openssl_decrypt($secret, $cipher, $key));
$username = $clearsecret[0];
$secretkey = $clearsecret[1];
$this->db = new mydatabase($secretkey);
. . .
class mydatabase extends mysqli {
public function __construct($secretkey) {
public $credentials; // set by the configuration script
$cipher = "AES-128-CBC";
$cred = explode(":", openssl_decrypt($credentials, $cipher, $secretkey);
parent::__construct(<database path>, $cred[0], $cred[1], <dbname>);
}
}
To summarize, the __construct call uses $credentials that are stored in encrypted form in a configuration file that my putative hacker can read. We decrypt them using the $secretkey that comes to us either in a secure XML packet or in the URL for a secure GET transaction.
The one flaw I see in this scheme is that a hacker who learns the login id of a registered user and who reads the PHP source code to learn the silly Fortune42Cookies! key could construct that user's unique $secret and thereby impersonate the user. Because there's only one set of credentials for the database, the hacker would then have the keys to the city.
Still, the extra layer of protection (hacker needs to defeat the UNIX file system protection AND learn the name of a real end user) seems worth it.
Fifty years of software development experience tells me I've missed something major. What is it?