Почему плохо иметь слабый пароль пользователя mysql?

Мне представили аргумент на мелодию «вам не нужен надежный пароль пользователя mysql, потому что для его использования у них уже будет доступ к вашему серверу». Мы говорим о 4-значном пароле, который является стандартным английским словарным словом на веб-сайте реального бизнеса.

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

Кто бы ни делал этот аргумент, кажется, говорит: «Как только кто-то ступит в дверь, вы можете также дать ему полный доступ». По этой логике брандмауэр сводит на нет необходимость всех паролей во внутренней сети.

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

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

Это зависит от того, как настроен ваш сервер MySQL. Если он только принимает запросы вне дома (127.0.0.1) ip, это делает его в меру более безопасным.

Учитывая сценарий, когда вы разрешаете удаленные IP-адреса, это становится гораздо более серьезным делом.

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

Есть ли в бухгалтерии блокировка мелкой кассы? Если так, то почему? Разве в здании нет физической безопасности?

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

Это не так, потому что mysql также может использоваться в кросс-сетевой среде клиент-сервер, и по умолчанию единственное, что вам нужно, это user / pass, чтобы получить доступ к базе данных (конечно, с открытым портом 3306 и публично видимым сервером). ).

На самом деле это может быть иначе: если у них есть доступ к mysql, они смогут получить доступ к самой серверной ОС.

1. Запросы MySQL LOAD_FILE и SELECT ... INTO OUTFILE позволяют пользователям mysql читать и записывать файлы в базовой файловой системе. Любой файл, к которому у пользователя mysql есть доступ (работает ли MySQL от имени root?). Если в Linux / UNIX просто запросите SELECT LOAD_FILE ('/ etc / passwd') и посмотрите, как они ухмыляются. Если mysqld работает от имени пользователя root, вы можете попробовать SELECT LOAD_FILE ('/ etc / shadow') и посмотреть, как ваш системный администратор плачет.
2. Во многих случаях под linux пользователь «root» mysql имеет тот же пароль, что и пользователь «mysql» на сервере (тот, который запускает mysqld). Тогда, если этот пароль тривиален (или его можно найти с помощью автоматических инструментов, таких как medusa / hydra), тогда вы можете просто подключиться по SSH / telnet непосредственно к серверу базы данных и дурачиться.

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

Все это при условии, что ваш сервер MySQL не принимает подключения из любого места, кроме localhost. Если это так, то вам нужен сильный PW.

Что-то, что здесь упущено, это то, доверяете ли вы своим пользователям в доверенной сети?

Честно говоря, нет, потому что я знаю, на что я был похож, когда начинал в IT. Я бы ткнул и подтолкнул в областях, на которые я не имел права, и, откровенно говоря, слабый пароль MySQL был бы для меня удовольствием, так как я бы воспользовался шансом на удачу и вошел, и я мог бы нанести удар (случайно, конечно).

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

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

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

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

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

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

Потому что требования меняются ...

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

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

Но также прочитайте, что сказал @meagar.

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

Кроме того, если сервер является живым производственным сервером, тогда вы рекламируете себя в Интернете. это означает, что в какой-то момент кто-то БУДЕТ предпринять атаку грубой силой на этот сервер, включая mysql, порт и учетную запись пользователя.

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

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

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

Многие из причин реальных сценариев были рассмотрены в постах ранее, поэтому я добавлю «философскую». Использование надежных паролей и принятие мер предосторожности для повышения вашей безопасности - это философия работы. Способ мышления.

Использование слабого пароля сейчас, потому что mysql работает только на 127.0.0.1, и доступ к нему имеет только пользователь root, показывает, что вы не думаете заранее. Что произойдет, если однажды вам нужно будет предоставить доступ к MySQL через сеть. Будете ли вы помнить, чтобы покрыть все службы безопасности, которые вы оставили?

Хороший админ ставит наихудший сценарий на грани паранойи.

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

В MySQL очень легко выдать себя за кого-то другого. Учитывая идентификатор пользователя без пароля (самая слабая защита) просто используйте mysql -u userid. Если у него есть пароль, это немного сложнее, но слабый пароль облегчает его. Если root не имеет пароля, я могу получить доступ к root как mysql -u root. Затем я могу сделать что-нибудь внутри базы данных, что может root.

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

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

Что ж, если вы не размещаете MySQL db самостоятельно, но используете хостинг, и кто-то получает доступ к IP-адресу вашего сервера, то имя пользователя и пароль - ваша последняя линия защиты. Всегда хорошо иметь безопасное имя пользователя / пароль.