52.3. SASL аутентификация#

52.3. SASL аутентификация
52.3. SASL аутентификация
Назад НаверхГлава 52. Протокол клиент/серверНачало Далее

52.3. SASL аутентификация #

52.3.1. Аутентификация SCRAM-SHA-256

SASL - это фреймворк для аутентификации в протоколах, ориентированных на соединение. В настоящее время Tantor BE реализует два механизма аутентификации SASL: SCRAM-SHA-256 и SCRAM-SHA-256-PLUS. В будущем могут быть добавлены и другие. Ниже приведены шаги, иллюстрирующие общий процесс аутентификации SASL, а следующий подраздел содержит более подробную информацию о SCRAM-SHA-256 и SCRAM-SHA-256-PLUS.

Поток сообщений аутентификации SASL

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

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

  3. Следует ожидать одно или несколько сообщений server-challenge и client-response. Каждый server-challenge отправляется в сообщении AuthenticationSASLContinue, за которым следует ответ клиента в сообщении SASLResponse. Подробности сообщений зависят от конкретного механизма.

  4. Когда обмен аутентификацией успешно завершается, сервер отправляет сообщение AuthenticationSASLFinal, за которым немедленно следует сообщение AuthenticationOk. Сообщение AuthenticationSASLFinal содержит дополнительные данные от сервера к клиенту, содержание которых зависит от выбранного механизма аутентификации. Если механизм аутентификации не использует дополнительные данные, отправляемые при завершении, сообщение AuthenticationSASLFinal не отправляется.

При возникновении ошибки сервер может прервать аутентификацию на любом этапе и отправить сообщение об ошибке.

52.3.1. Аутентификация SCRAM-SHA-256 #

Реализованные механизмы SASL на данный момент это SCRAM-SHA-256 и его вариант с привязкой к каналу SCRAM-SHA-256-PLUS. Они подробно описаны в RFC 7677 и RFC 5802.

Когда в PostgreSQL используется SCRAM-SHA-256, сервер игнорирует имя пользователя, которое клиент отправляет в client-first-message. Вместо этого используется имя пользователя, которое уже было отправлено в сообщении о запуске. Tantor BE поддерживает несколько кодировок символов, в то время как SCRAM требует использования UTF-8 для имени пользователя, поэтому может быть невозможно представить имя пользователя PostgreSQL в UTF-8.

Спецификация SCRAM предписывает, что пароль также должен быть в кодировке UTF-8 и обрабатываться с помощью алгоритма SASLprep. Однако Tantor BE не требует использования UTF-8 для пароля. При установке пароля пользователя он обрабатывается с помощью SASLprep, как если бы он был в кодировке UTF-8, независимо от фактической кодировки. Однако, если это не является допустимой последовательностью байтов UTF-8 или содержит последовательности байтов UTF-8, запрещенные алгоритмом SASLprep, будет использоваться исходный пароль без обработки SASLprep, вместо генерации ошибки. Это позволяет нормализовать пароль, когда он находится в кодировке UTF-8, но все же позволяет использовать пароль, не находящийся в кодировке UTF-8, и не требует знания системой кодировки пароля.

Привязка канала поддерживается в сборках PostgreSQL с поддержкой SSL. Имя механизма SASL для SCRAM с привязкой канала - SCRAM-SHA-256-PLUS. Тип привязки канала, используемый PostgreSQL - tls-server-end-point.

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

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

Пример

  1. Сервер отправляет сообщение AuthenticationSASL. Оно включает список механизмов аутентификации SASL, которые сервер может принять. Это будет SCRAM-SHA-256-PLUS и SCRAM-SHA-256, если сервер собран с поддержкой SSL, иначе только последний.

  2. Клиент отвечает, отправляя сообщение SASLInitialResponse, которое указывает выбранный механизм, SCRAM-SHA-256 или SCRAM-SHA-256-PLUS. (Клиент может выбрать любой механизм, но для лучшей безопасности он должен выбрать вариант с привязкой канала, если он может его поддерживать). В поле Initial Client response сообщение содержит SCRAM client-first-message. client-first-message также содержит выбранный клиентом тип привязки канала.

  3. Сервер отправляет сообщение AuthenticationSASLContinue с содержимым SCRAM server-first-message.

  4. Клиент отправляет сообщение SASLResponse с содержимым SCRAM client-final-message.

  5. Сервер отправляет сообщение AuthenticationSASLFinal с server-final-message, сразу за которым следует сообщение AuthenticationOk.

Назад Наверх Далее
52.2. Поток сообщений Начало 52.4. Протокол потоковой репликации