лучший подход, чем хранение mysql пароль в простом тексте в файле конфигурации?

Хранение файлов конфигурации вне корня документа - популярный способ повышения безопасности файлов конфигурации.

Конечно, вы никогда не должны хранить пароль в текстовом файле в корне документа. Какие дальнейшие шаги вы предпримете для его защиты, будет зависеть от уровня доступа, который у вас есть для настройки вашего веб-сервера.

Вы можете определить пароль в php.ini (или через настройку ini в конфигурации Apache или .htaccess). Или установите его в среде, когда вы запускаете свой веб-сервер.

Нет смысла просто шифровать пароль - это означает, что вам нужно хранить ключ дешифрования - если вы не используете пароль, предоставленный пользователем с аутентификацией кворума, для расшифровки пароля (но это предотвращает доступ к базе данных неаутентифицированным сеансам и становится беспорядочно, когда вам нужно добавить новых пользователей в кворум).

Если это дешевый пакет хостинга и у вас нет доступного хранилища за пределами корня документа, то сохранение пароля во включаемом файле php внутри должно предотвратить его раскрытие (файл будет проанализирован php вместо загрузки). В качестве альтернативы, простое присвоение файлу имени с расширением «.ht» в начале может предотвратить удаленный доступ.

Обратите внимание, что ваш второй вариант несколько избыточен - если кто-то может нанести такой большой ущерб вашему коду, ему не нужно извлекать пароль из работающего кода.

На самом деле решения проблемы нет.

С.

Лично я храню конфиденциальную информацию, такую ​​как сведения о подключении к базе данных, в файле config.ini вне корня моей веб-папки. Затем в моем index.php я могу сделать:

$config = parse_ini_file('../config.ini');

Это означает, что переменные не будут отображаться, если ваш сервер случайно начнет выводить сценарии PHP в виде простого текста (что уже случалось раньше, печально известная для Facebook); и только скрипты PHP имеют доступ к переменным.

Он также не зависит от .htaccess , в котором нет никаких непредвиденных обстоятельств, если ваш файл .htaccess будет перемещен или уничтожен.

Предупреждение, добавлено 14 февраля 2017 г .: теперь я буду хранить такие параметры конфигурации как переменные среды. Я уже некоторое время не использую файл .ini .

Если вы готовы пожертвовать доступностью для безопасности файла, вы можете вынуть пароль из файла конфигурации и потребовать от администратора ввести его при загрузке и сохранить в глобальная переменная.

Вы все равно должны быть уверены, что вы защищены от атак с использованием инъекций, которые могут выгрузить эту переменную, и, конечно же, у вас есть ручной шаг в процессе (повторной) загрузки.

Он не обязательно должен быть в корневом веб-каталоге. Вы можете переместить файл за пределы корневого каталога и называть его так. Это просто означает, что файл нельзя вызвать напрямую из Интернета.

Если в вашем коде есть недостатки безопасности, такие как включение каких-либо данных без фильтрации из данных GET, то этот файл все еще находится под угрозой. Настоящий ключ - убедиться, что ваше приложение также безопасно.

Помимо правильного хранения этих конфиденциальных данных, вы также должны создать отдельного пользователя MySQL , который имеет только необходимые привилегии и ограничить доступ к базе данных / tables / views, к которым у него должен быть доступ. А поскольку сервер базы данных часто запускается на том же компьютере, что и веб-сервер, необходимо также ограничить доступ для локального доступа. Так что не используйте пользователя с привилегиями root, если ему просто нужно читать данные из одной базы данных / таблицы.