Защита паролей БД


18

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


1
Чтобы уточнить - вы спрашиваете о сохранении учетных данных для входа в базу данных с веб-сайта, а не о том, как правильно хранить пароли для пользователей веб-сайта в базе данных, верно?
Джо

Верный; вот к чему я клоню.
Кадзи

Ответы:


10

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

В некоторых случаях, когда я устанавливаю чей-либо пакет, я устанавливаю два экземпляра: общедоступный экземпляр, у которого есть только доступ к базе данных для выполнения общих действий пользовательского типа, и второй экземпляр, который ограничен IP-адресами. моя локальная подсеть (возможно, даже на другом компьютере), которая должна использоваться для любых действий типа «администратор». Ни один из них не имеет доступа к изменению таблиц и т. Д., Хотя ... Я бы лучше пошел через нативные инструменты базы данных, чем позволял бы веб-приложению запускать свои собственные задачи обновления, которые не были проверены.

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

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


1
Мы делаем что-то подобное. Однако мы обычно создаем новую учетную запись для каждого пользователя / приложения базы данных вместо того, чтобы делать это по функциональности. Это решает для нас две проблемы: 1) мы можем дифференцировать использование базы данных в таких инструментах, как OEM (то есть мы можем видеть, кто использует базу данных с гранулярностью), и 2) мы можем индивидуально адаптировать то, что каждый пользователь видит и имеет доступ к нему. база данных.
ScottCher

7

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


4

Я большой поклонник использования аутентификации PostgreSQL 'Ident' через локальные сокеты всякий раз, когда могу. Таким образом, локальные пользователи отображаются напрямую на пользователей Unix / Windows на локальном компьютере, и мне не нужно беспокоиться о сохранении паролей вообще. Я не думаю, что это вариант в MySQL, хотя.

Там, где база данных и веб-сервер находятся на двух разных компьютерах, я использую пароли MD5 через SSL: если у злоумышленника есть доступ к моему внешнему серверу, он только выяснит, как он взаимодействует с базой данных.


3

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

Помимо использования зашифрованных строк подключения, использование LDAP / Kerberos / Active Directory будет самым безопасным вариантом.


3

Если ваши пароли хранятся в виде простого текста, используйте хэши (MD5, SHA), Люк!


ОП не спрашивает о сохранении пользовательских паролей. Но да, конечно, хэшируйте ваши пароли пользователей, но никогда не используйте MD5 или семейство SHA, чтобы сделать это! Используйте bcrypt или PBKDF2. В противном случае вы скоро окажетесь в новостях, подобных этим компаниям, которые использовали MD5 и SHA1 и таким образом подвергли своих пользователей простым атакам методом грубой силы.
Ник Чаммас

Конечно, соление и другие методы требуются помимо простого перемешивания. И никогда не следует реализовывать криптопримитивы сам, а лучше использовать некоторые широко проверенные криптобиблиотеки.
Ясир Арсанукаев

2

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

Если вы работаете с C ++ или чем-то подобным, то я бы порекомендовал вам создать / найти соленую функцию шифрования / дешифрования, запустить через нее учетные данные и сохранить полученный хэш в виде файла в системе.

Если вы используете PHP или что-то подобное, я бы порекомендовал вам написать обертку для mcrypt_encrypt()и засолить учетные данные, а затем запустить некоторую запутывание кода, чтобы замедлить работу хакеров, если они получат доступ к системе.


Если вы шифруете учетные данные, вам понадобится какой-то другой секрет, чтобы расшифровать их снова. Или, альтернативно, зашифрованная форма становится секретной, поэтому злоумышленник может ее использовать. Некоторые детали отсутствуют.
Питер Айзентро
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.