SQL Server 2005: Насколько безопасна аутентификация SQL Server?

Question

Если вы используете проверку подлинности SQL Server (2005), передаются ли данные для входа в виде открытого текста по сети?

Answer 1

Столько, сколько вы хотите, чтобы сделать это ...

вы можете довольно легко настроить SSL, и если у вас нет доверенного сертификата, если вы используете шифрование, SQL Server может создать / выдать свой собственный самоподписанный сертификат для вашего использования ... из этой записи до

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

Answer 2

Будет ли зашифрованы учетные данные для входа в систему, зависит от возможностей / конфигурации шифрования клиента и сервера.

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

Подробнее

Клиенты взаимодействуют с Microsoft SQL Server, используя протокол Tabular Data Stream (TDS) .

Вскоре после того, как клиент открывает соединение TDS с сервером, он информирует сервер о своих возможностях шифрования. Сервер сравнивает это объявление со своей собственной конфигурацией / возможностью определения состояния шифрования для соединения.

В двух словах, состояние шифрования определяется следующим образом:

• Если клиент или сервер объявляют, что они не поддерживают шифрование, а другая сторона не требует шифрования, все соединение, включая логин, будет незашифровано .
• Если и клиент, и сервер сообщают, что они поддерживают шифрование, но не требуют его, будет зашифрован только первый пакет TDS запроса на вход в систему . Остальная часть соединения, включая любые дополнительные пакеты запроса входа, будет незашифрована. Правильно спроектированный драйвер базы данных гарантирует, что пароль аутентификации SQL будет помещен в первый пакет входа в систему, но это не требуется на уровне протокола.
• Если клиент или сервер объявляют, что им требуется шифрование, будет шифроваться все соединение (за исключением небольшого количества предварительных данных), если только другая сторона не поддерживает шифрование. В этом случае соединение будет разорвано.

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

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

Дополнительная литература:

• Технические подробности о состояниях шифрования соединения - MS-TDS 2.2.6.5 PRELOGIN (под заголовком Шифрование )
• Формула обфускации пароля - MS-TDS 2.2.6.4 LOGIN7 (см. Последний абзац)
• Чуть более подробное описание темы - Пароли SQL: зашифрованные между клиентом и сервером? (отказ от ответственности: это пост в моем блоге)

Answer 3

Вот ссылка на некоторые рекомендации по безопасности для SQL 2005. Этот документ частично заявляет:

В режиме аутентификации Windows конкретный пользователь и группа Windows учетные записи доверены для входа в SQL Сервер. Используются учетные данные Windows в процессе; то есть либо NTLM или учетные данные Kerberos. Windows учетные записи используют серию зашифрованных сообщения для аутентификации в SQL Сервер; пароли не передаются сеть во время аутентификации процесс. Когда используются имена входа SQL, пароли входа SQL передаются по сети для аутентификации. Это делает имена входа SQL менее безопасными, чем имена входа Windows.

Answer 4

Учетные данные отправляются в виде открытого текста.

Возможно, вы найдете несколько источников для этого, но вот один :

"Защитите канал между веб-сервером и сервером базы данных, поскольку учетные данные передаются в незашифрованном формате. Например, используйте SSL или IPSec."

Answer 5

Чтение этой темы сделало меня еще более запутанным, чем я был! Во всяком случае, я провел несколько тестов с Wireshark, с или без зашифрованного соединения Я так и не смог увидеть свой пароль (и мое имя пользователя, я думаю). Что было очень заметно без шифрования, так это реальные запросы.

Возможно, это нехватка знаний в Wireshark для получения учетных данных для входа в систему, но, поскольку я смог увидеть все остальное, я почти уверен, что смотрел в нужное место, а пароль ВСЕГДА скрывался.

Answer 6

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