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

Меня всегда беспокоило то, что многим программам PHP требуется, чтобы пользователь хранил пароль mysql в виде обычного текста (в строке или константе) в файле конфигурации в корне приложения.

Есть ли лучший подход к этому после всех этих лет?

До сих пор я придумал два минимальных повышения безопасности:

сделать файл нечитаемым через Интернет, используя правила в .htaccess(в случае сбоя php или наличия уязвимости безопасности для чтения источника php)
уничтожить пароль в памяти после создания соединения db (unset) (чтобы предотвратить сброс строк из-за нарушения безопасности, инъекции и т.д.)

но, конечно, ни один из них не решает исходную проблему.

Спасибо за любые другие идеи!

Ответ 1

Поскольку вашему коду будет нужен пароль, нет идеальной защиты. Но вы можете усложнить восстановление.

Я помещаю некоторый хэш в свой веб-конфигуратор, как переменную среды, скажем MYSQL_PASS_HASH

Затем я делаю что-то вроде md5(getenv('MYSQL_PASS_HASH').'gibberish$qwefsdf'), которое является потом паролем. Конечно, вы должны unsetenv после этого, если вы параноик.

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

Это происходит в файле вне webroot (не доверяйте .htaccess).

Ответ 2

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

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

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

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

Caveat, добавлено 14 февраля 2017: теперь я буду хранить параметры конфигурации, подобные этому, в качестве переменных среды. Ive не использовал файловый подход .ini в течение некоторого времени.

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

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

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

Действительно, решения проблемы нет.

С.

Ответ 6

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

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

Ответ 7

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

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