Есть ли преимущества в плане безопасности при использовании идентификатора пользователя / пароля для mysqli_connect() на сервере MariaDB / PHP?

#php #mysql #mysqli #mariadb

#php #mysql #mysqli #мариадб

Вопрос:

Мне трудно придумать преимущество для требования пароля для веб-приложений MariaDB / PHP, поскольку пароль всегда будет где-то храниться в виде открытого текста.

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

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

Кто-нибудь придумал что-нибудь более безопасное?

Есть какие-нибудь мысли?

Комментарии:

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

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

3. отсутствие пароля может означать, что плагин аутентификации сокета unix требует, чтобы пользователь unix соответствовал mysql / mariadb, который заменяет аутентификацию на аутентификацию пользователя unix, а не на известную строку на известном IP. Так что не абстрактно, очень конкретно и изобретено, не обязательно лучше или хуже во всех сценариях, но по-разному. Действительно необходимо учитывать риск / выгоду сценариев, но никакие решения не являются исключительно надежными и отказоустойчивыми.

4. @lne: это выделенный хост без пользователей и приложений, не связанных с ним.

5. @Yourcommon Sense: единственная «лучшая» часть — это отсутствие необходимости хранить, вызывать или поддерживать пароль. «Отсутствие пароля» — это не «причудливая схема», на самом деле все наоборот. Данные, которые не существуют, не нуждаются в обслуживании.

Ответ №1:

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

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

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

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

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

Комментарии:

1. Поскольку у них есть доступ к серверу, у них также будет доступ к логину DB. / password, который использует веб-приложение. Это не кажется более безопасным, чем отсутствие пароля.