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

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

17 ответов


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

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


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

<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. работает x-platform
  6. не забудьте передать envvar ненадежным дочерним процессам

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


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

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-файлы просто отображаются в виде текста, а не выполняются, вы не выставили пароль.

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

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

Петр


Я думаю, что OP означает пароль базы данных.

Если кто-то не получит доступ к вашему серверу через FTP или SSH (в этом случае вы уже испорчены), я бы не беспокоился о хранении паролей в открытом тексте в PHP-файлах. Большинство PHP-приложений, которые я видел, делают это таким образом, например phpbb.


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

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


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


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

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


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

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

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

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

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

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

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

<?php exit() ?>

[...]

Plain text data including password

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

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


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

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


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

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

мы решили это таким образом:

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