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