Как обезопасить пароли базы данных в PHP?

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

Несколько человек неправильно восприняли это как вопрос о том, как хранить пароли в базе данных. Это не правильно. Речь идет о том , как сохранить пароль , который позволяет получить в базе данных.

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

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

<files mypasswdfile>
order allow,deny
deny from all
</files>

Самый безопасный способ - вообще не указывать информацию в вашем PHP-коде.

Если вы используете Apache, это означает, что вы должны указать детали подключения в файле httpd.conf или в файле виртуальных хостов. Если вы сделаете это, вы можете вызвать mysql_connect () без параметров, что означает, что PHP никогда не будет выводить вашу информацию.

Вот как вы указываете эти значения в этих файлах:

php_value mysql.default.user      myusername
php_value mysql.default.password  mypassword
php_value mysql.default.host      server

Затем вы открываете свое соединение MySQL следующим образом:

<?php
$db = mysqli_connect();

Или вот так:

<?php
$db = mysqli_connect(ini_get("mysql.default.user"),
                     ini_get("mysql.default.password"),
                     ini_get("mysql.default.host"));

Храните их в файле вне веб-корня.

Для чрезвычайно безопасных систем мы зашифровываем пароль базы данных в файле конфигурации (который сам защищен системным администратором). При запуске приложения / сервера приложение затем запрашивает у системного администратора ключ дешифрования. Пароль базы данных затем читается из файла конфигурации, расшифровывается и сохраняется в памяти для дальнейшего использования. Все еще не на 100% безопасен, так как он хранится в расшифрованной памяти, но в какой-то момент вы должны назвать его «достаточно безопасным»!

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

1. Создайте пользователя ОС для своего приложения. Смотрите http://en.wikipedia.org/wiki/Principle_of_least_privilege
2. Создайте (не сеансовую) переменную среды ОС для этого пользователя с паролем
3. Запустите приложение от имени этого пользователя

Преимущества:

1. Вы не будете проверять ваши пароли в системе контроля версий случайно, потому что вы не можете
2. Вы случайно не испортите права доступа к файлам. Ну, вы можете, но это не повлияет на это.
3. Может быть прочитано только пользователем root или тем пользователем. Root может прочитать все ваши файлы и ключи шифрования в любом случае.
4. Если вы используете шифрование, как вы храните ключ безопасно?
5. Работает х-платформа
6. Обязательно не передавайте envvar недоверенным дочерним процессам

Этот метод предложен Heroku, которые очень успешны.

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

mysql_connect("localhost", "me", "mypass");

В противном случае лучше сбросить учетные данные после оператора connect, поскольку учетные данные, которые не находятся в памяти, не могут быть прочитаны из памяти ;)

include("/outside-webroot/db_settings.php");  
mysql_connect("localhost", $db_user, $db_pass);  
unset ($db_user, $db_pass);  

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

Кроме этого вы находитесь на правильных линиях с минимальным доступом к используемой учетной записи. Добавьте к этому

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

Питер

Если вы используете PostgreSQL, он ~/.pgpassавтоматически ищет пароли. Смотрите руководство для получения дополнительной информации.

Ранее мы сохраняли БД user / pass в файле конфигурации, но с тех пор достигли параноидального режима - приняв политику Defence in Depth .

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

Мы перешли на хранение пользовательских / передаваемых переменных среды, установленных в Apache VirtualHost. Эта конфигурация доступна для чтения только пользователю root - надеюсь, ваш пользователь Apache не работает от имени пользователя root.

С этим связано то, что теперь пароль находится в глобальной переменной PHP.

Чтобы снизить этот риск, у нас есть следующие меры предосторожности:

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

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

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

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

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

Просто положить его в конфигурационный файл куда-то, как обычно. Просто убедитесь, что вы:

1. запретить доступ к базе данных с любых серверов за пределами вашей сети,
2. позаботьтесь о том, чтобы случайно не показывать пароль пользователям (в сообщении об ошибке или через файлы PHP, случайно используемые как HTML и т. д.)

Мы решили это следующим образом:

1. Используйте memcache на сервере, с открытым соединением с другого сервера паролей.
2. Сохраните в memcache пароль (или даже весь зашифрованный файл password.php) плюс ключ дешифрования.
3. Веб-сайт вызывает ключ memcache, содержащий парольную фразу файла паролей, и расшифровывает в памяти все пароли.
4. Сервер паролей отправляет новый зашифрованный файл паролей каждые 5 минут.
5. Если вы используете зашифрованный password.php в своем проекте, вы помещаете аудит, который проверяет, был ли этот файл затронут внешне - или просмотрен. Когда это происходит, вы автоматически можете очистить память, а также закрыть сервер для доступа.

Дополнительный прием заключается в использовании отдельного файла конфигурации PHP, который выглядит следующим образом:

<?php exit() ?>

[...]

Plain text data including password

Это не мешает вам правильно устанавливать правила доступа. Но в случае, если ваш веб-сайт взломан, «require» или «include» просто выйдут из скрипта в первой строке, поэтому получить данные еще сложнее.

Тем не менее, никогда не допускайте конфигурационные файлы в каталог, к которому можно получить доступ через Интернет. У вас должна быть папка «Web», содержащая ваш код контроллера, css, картинки и js. Это все. Все остальное идет в автономные папки.

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

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