Я застрял с PHP 5.4 и единым ИД пользователя базы данных из-за дефектов в реализации бизнес-хостинга Comcast.Проблема с идентификатором пользователя означает, что те же учетные данные, которые я использую для управления базой данных MySQL, также должны использоваться при обработке запросов от обычных пользователей.У меня есть контроль над тем, кто может войти в систему как обычный пользователь, делегировав создание идентификаторов группе доверенных пользователей, которые сообщат конечным пользователям URL-адрес, который им потребуется для входа в приложение.И хотя на сервере работает Apache, он игнорирует заголовок авторизации.
Предполагая, что какой-то хакер может победить защиту файловой системы сервера HostWays Unix и прочитать весь мой исходный код PHP, мне нужно избегать базы данныхучетные данные появляются в вызовах подключения MySQL в моем источнике PHP.Я придумал следующую схему для шифрования учетных данных базы данных и хочу быть уверен, что эта схема действительно будет эффективной.
Я определю глобальную переменную с именем $ credentials в файле конфигурации.Я сгенерирую значение в своей среде разработки с помощью этого кода:
$cipher = "AES-128-CBC";
$secretkey = …; // it's a secret!
$secret = openssl_encrypt("$dbuser:$dbpass", $cipher, $secretkey);
Помните, что я застрял с PHP 5.4 и не смог получить загадочные ошибки в openssl_decrypt, когда использовалначальное значение в вызовах шифрования / дешифрования.В любом случае, большая часть кода по крайней мере работает.
Доступ к моему PHP-приложению можно получить двумя способами: один из них - через полезную нагрузку XML в транзакции POST, поступающей из настольного приложения C ++;другой - через обычный URL в GET.Оба метода будут использовать HTTPS.Схема XML требует параметр аутентификации, который предоставляет $ secretkey.
URL для транзакции GET будет использоваться обычными пользователями из браузера.Он будет содержать параметр secret =, который кодирует как идентификатор входа пользователя, так и $ secretkey.Я сгенерирую параметр secret = во время транзакции, который добавляет пользователя в список авторизованных пользователей:
$cipher = "AES-128-CBC";
$key = "Fortune42Cookies!";
$secret = openssl_encrypt("$username:$secretkey", $cipher, $key);
В этом коде ключ $ secretkey остается с момента, когда доверенный пользователь добавляет этот конецпользователь вошел в список. Соответствующий код дешифрования, используемый при входе в систему конечного пользователя, выглядит следующим образом:
$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>);
}
}
Для подведения итогов вызов __construct использует $ credentials, которые хранятся в зашифрованном виде в файле конфигурации.что мой предполагаемый хакер может читать.Мы расшифровываем их, используя $ secretkey, который приходит к нам либо в защищенном XML-пакете, либо в URL-адресе для безопасной транзакции GET.
Единственный недостаток, который я вижу в этой схеме, заключается в том, что хакер узнает идентификатор входа в системузарегистрированного пользователя и который читает исходный код PHP, чтобы изучить глупые файлы Fortune42Cookies!key может создать уникальный $ secret этого пользователя и тем самым выдать себя за пользователя.Поскольку для базы данных существует только один набор учетных данных, у хакера будут ключи от города.
Тем не менее, дополнительный уровень защиты (хакер должен победить защиту файловой системы UNIX и узнать имя реального конечного пользователя) кажется стоящим.
Пятьдесят лет опыта разработки программного обеспечения говорятЯ пропустил что-то важное.Что это?