Как я могу защитить строку подключения mySQL в PHP?

Question

Я знаю правило: никогда не задавайте свой пароль жестко, и я видел этот вопрос здесь , который объясняет, что делать с Java и mySQL, но я не знаю, что делать с PHP и mySQL.

Текущая строка подключения сделана так

<?PHP

$DBName = "dbName";
$Host = "localhost";
$User = "dbUser";
$Password = "Yikes_hardcoded_PW";

$Link = mysql_connect( $Host , $User , $Password , $DBName);

if (!$Link) {
    die('Could not connect: ' . mysql_error());
}

?>

• но мне нужно, чтобы пароль был защищен, т.е. не был жестко задан в этом файле. Как мне это сделать?

РЕДАКТИРОВАТЬ: Несмотря на все отрицательные отзывы, которые я получил по этому поводу, я до сих пор не получил ответа на вопрос, касающийся подлинной проблемы безопасности - жестко закодированных паролей. Бесполезно опускать голосование по подлинному вопросу, не публикуя ни комментарий, ни ответ, который отвечает на вопрос.

Answer 1

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

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

Answer 2

Я тоже занимаюсь исследованиями по этой теме. Разрешение на файл является одной из стратегий, но существует очень много векторов.

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

Возможно, тогда вы сможете создать папку .private на один уровень выше домашней директории этого пользователя. Затем в php-файлы для этого пользователя, у которого есть свои сценарии в public_html, включите файл подключения, который существует в папке .private (например, ../../.private/connect.php).

Я не знаю, сработает ли это, если пользователя посадят в тюрьму, но этот вид кажется безопасностью из-за неясности.

Answer 3

Вам придется где-то жестко кодировать пароль.Даже если вы хотите использовать DSN, вам придется жестко закодировать пароль в строке DSN.Насколько я понимаю, от жесткого кодирования пароля не уйти.

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

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

Answer 4

Сохраните ваши конфигурации в другом файле.

$DBName = "dbName";
$Host = "localhost";
$User = "dbUser";
$Password = "Yikes_hardcoded_PW";

Установки git ignore для этого файла конфигурации.

Answer 5

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

Недостатком является то, что теперь в БД есть несколько учетных записей доступа, но в качестве плюса это также значительно упрощает аудит пользователей, если в вашей БД включены журналы аудита.,

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

Answer 6

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

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

В любом развертывании вы должны отредактировать эти заполнители так, чтобы они были проверкой реальных учетных данных.Это также поможет любому, кто использует ваш проект, если вы собираетесь открыть исходный код.

Обновлено (чтобы ответить на вопрос)

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

1. Проверьте вашу конфигурацию Apache, open_basedir ограничивает другие экземпляры vhost от доступа к файлам вне их веб-корня
2. Проверьте разрешение файловой системы, чтобы убедиться, что только apache и ваш пользователь могут получить доступ к файлу
3. Убедитесь, что ваш пользователь mysql настроен на допустимость только из контекста localhost, то есть grant all privileges on mydatabase.* to myuser@localhost etc
4. Используйте брандмауэр для блокировки внешних подключений к mysql

Answer 7

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

Чтобы ответить на ваш вопрос напрямую, нет способа запутать пароль.