Механизм аутентификации «соленый запрос-ответ»

В криптографии механизм аутентификации «запрос-ответ» ( SCRAM ) представляет собой семейство современных механизмов аутентификации «запрос-ответ» на основе пароля , обеспечивающих аутентификацию пользователя на сервере. Как указано для уровня простой аутентификации и безопасности (SASL), его можно использовать для входа на основе пароля в такие службы, как LDAP , HTTP , SMTP , POP3 , IMAP и JMAP ( электронная почта ), XMPP (чат) или MongoDB. и PostgreSQL (базы данных). Для XMPP его поддержка обязательна. ^[1]

Мотивация

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

Теперь Алиса могла отправить свой пароль Бобу по незашифрованному соединению в виде открытого текста, чтобы он мог его проверить. Однако это сделает пароль доступным для Мэллори, которая прослушивает линию. Алиса и Боб могли бы попытаться обойти это, зашифровав соединение. Однако Алиса не знает, было ли шифрование установлено Бобом, а не Мэллори, выполнив атаку «человек посередине» . Поэтому вместо этого Алиса отправляет хешированную версию своего пароля, как в CRAM-MD5 или DIGEST-MD5 . Поскольку это хеш, Мэллори не получает сам пароль. А поскольку хэш дополнен проблемой, Мэллори мог использовать его только для одного процесса входа в систему. Однако Алиса хочет передать Бобу некоторую конфиденциальную информацию и хочет быть уверена, что это Боб, а не Мэллори.

Для решения этой проблемы Боб зарегистрировался в центре сертификации (CA), который подписал его сертификат. Алиса могла бы полагаться исключительно на эту систему подписи, но она знает, что у нее есть недостатки . Чтобы дать ей дополнительную уверенность в отсутствии атаки «человек посередине», Боб создает доказательство того, что он знает пароль (или его «соленый» хеш), и включает в это доказательство свой сертификат. Это включение называется привязкой канала, поскольку нижний канал шифрования «привязан» к более высокому каналу приложения.

Затем у Алисы есть аутентификация Боба, а у Боба есть аутентификация Алисы. В совокупности они имеют взаимную аутентификацию . В DIGEST-MD5 уже включена взаимная аутентификация, но она часто реализовывалась неправильно. ^[2]^[3]

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

Боб слышал об утечках данных в серверных базах данных и решил, что не хочет хранить пароли своих пользователей в открытом виде. Он слышал о схемах входа CRAM-MD5 и DIGEST-MD5, но знает, что для предложения этих схем входа своим пользователям ему придется хранить слабо хешированные, несоленые пароли. Ему не нравится эта идея, и поэтому он предпочитает требовать пароли в виде обычного текста. Затем он может хэшировать их с помощью безопасных схем хеширования, таких как bcrypt , scrypt или PBKDF2 , и солить их по своему усмотрению. Однако тогда Боб и Алиса всё равно столкнутся с описанными выше проблемами. Чтобы решить эту проблему, они используют SCRAM, где Боб может хранить свой пароль в «соленом» формате, используя PBKDF2. Во время входа в систему Боб отправляет Алисе свою соль и количество итераций алгоритма PBKDF2, а затем Алиса использует их для расчета хешированного пароля, который есть у Боба в его базе данных. Все дальнейшие вычисления в SCRAM основаны на этом значении, которое известно обоим.

Обзор протокола

Хотя все клиенты и серверы должны поддерживать алгоритм хеширования SHA-1 , SCRAM, в отличие от CRAM-MD5 или DIGEST-MD5 , не зависит от базовой хеш-функции. ^[4] Вместо этого можно использовать все хэш-функции, определенные IANA. ^[5] Как упоминалось в разделе «Мотивация», SCRAM использует механизм PBKDF2 , повышающий устойчивость к атакам методом перебора , когда на сервере произошла утечка данных. Позволять H быть выбранной хэш-функцией, заданной именем алгоритма, объявленного сервером и выбранного клиентом. Например, «SCRAM-SHA-1» использует SHA-1 в качестве хеш-функции.

Производный ключ на основе пароля или соленый пароль

Клиент получает ключ или «сольный» пароль из пароля, «соли» и ряда вычислительных итераций следующим образом:

SaltedPassword = H(password, salt, iteration-count) = PBKDF2(HMAC, password, salt, iteration-count, output length of H).

Сообщения

RFC 5802 называет четыре последовательных сообщения между сервером и клиентом:

клиент-первый: Сообщение , ориентированное на клиента, состоит из заголовка GS2 (содержащего флаг привязки канала и необязательное имя для авторизационной информации), желаемого usernameи случайно сгенерированный клиентский nonce c-nonce.
сначала на сервере: Сервер добавляет к этому клиенту nonce свой собственный nonce. s-nonceи добавляет его в сообщение , ориентированное на сервер , которое также содержит salt используется сервером для добавления хэша пароля пользователя и счетчика итераций iteration-count.
клиент-финал: После этого клиент отправляет окончательное сообщение клиента, содержащее привязку канала , заголовок GS2 и данные привязки канала, закодированные в base64, объединение клиентского и серверного nonce, а также подтверждение клиента. proof.
сервер-финал: Связь завершается финальным сообщением сервера , которое содержит подпись сервера: verifier.

Доказательства

Клиент и сервер доказывают друг другу, что у них одно и то же. Auth переменная, состоящая из:

Auth = client-first-without-header + , + server-first + , + client-final-without-proof (соединены запятыми)

Более конкретно это имеет вид:

= n=username,r=c‑nonce,[extensions,]r=c‑nonce‖s‑nonce,s=salt,i=iteration‑count,[extensions,]c=base64(channel‑flag,[a=authzid],channel‑binding),r=c‑nonce‖s‑nonce[,extensions]

Доказательства рассчитываются следующим образом:

ClientKey = HMAC(SaltedPassword, 'Client Key')

ServerKey = HMAC(SaltedPassword, 'Server Key')

ClientProof = p = ClientKey XOR HMAC(H(ClientKey), Auth)

ServerSignature = v = HMAC(ServerKey, Auth)

где операция XOR применяется к байтовым строкам одинаковой длины, H(ClientKey) это обычный хэш ClientKey. 'Client Key' и 'Server Key' являются дословными строками.

Сервер может авторизовать клиента, вычислив ClientKey от ClientProof а затем сравнивая H(ClientKey) с сохраненным значением.

Клиент может авторизовать сервер, вычислив и сравнив ServerSignature напрямую.

Сохраненный пароль

Сервер хранит только имя пользователя, salt, iteration-count, H(ClientKey), ServerKey. Сервер имеет временный доступ к ClientKey как оно получено из доказательства клиента, будучи зашифрованным с помощью H(ClientKey).

Клиенту нужно только password.

Привязка канала

Термин «привязка канала» описывает стратегию предотвращения атак типа «человек посередине» , которая «привязывает» уровень приложения , который обеспечивает взаимную аутентификацию, к нижнему уровню (в основном шифрования), гарантируя, что конечные точки соединения одинаковы на обоих уровнях. слои. Существует два основных направления привязки канала: уникальное привязывание канала и привязка канала конечной точки . Первый гарантирует, что используется конкретное соединение, второй — что конечные точки совпадают.

Существует несколько типов привязки каналов, каждый из которых имеет уникальный префикс привязки канала . ^[6] Каждый тип привязки канала определяет содержимое данных привязки канала , которые предоставляют уникальную информацию по каналу и конечным точкам. Например, для привязки канала tls-server-end-point это сертификат TLS сервера. ^[7] Примером использования привязки канала со SCRAM в качестве уровня приложения может быть использование безопасности транспортного уровня (TLS) в качестве нижнего уровня. TLS защищает от пассивного подслушивания, поскольку связь зашифрована. Однако если клиент не аутентифицирует сервер (например, проверяя сертификат сервера), это не предотвращает атаки «человек посередине». Для этого конечные точки должны подтвердить свою идентичность друг другу, что может быть предоставлено SCRAM.

Переменная SCRAM gs2 -cbind-flag указывает, поддерживает ли клиент привязку канала или нет, или считает, что сервер не поддерживает привязку канала, а c-bind-input содержит gs2-cbind-flag вместе с уникальным префиксом привязки канала и канала сами данные привязки .

Привязка каналов не является обязательной в SCRAM, а переменная gs2-cbind-flag предотвращает атаки на понижение версии .

Когда сервер поддерживает привязку канала, он добавляет последовательность символов «-PLUS» к объявленному имени алгоритма SCRAM.

Сильные стороны

Надежное хранилище паролей. При правильной реализации сервер может хранить пароли в с солью формате повторяющегося хэша , что затрудняет оффлайн-атаки и снижает влияние взломов базы данных. ^[8]
Простота: внедрение SCRAM проще. ^[9] чем ДАЙДЖЕСТ-MD5. ^[10]
Международная совместимость: RFC требует UTF-8 для имен пользователей и паролей, в отличие от CRAM-MD5. использования ^[9]^[11]
Поскольку во всем процессе входа в систему используется только солированная и хешированная версия пароля, а соль на сервере не меняется, клиент, хранящий пароли, может хранить хешированные версии и не раскрывать злоумышленникам открытый текстовый пароль. Такие хешированные версии привязаны к одному серверу, что делает это полезным при повторном использовании паролей. ^[12]

Ссылки

^ «Расширяемый протокол обмена сообщениями и присутствия: для конфиденциальности и аутентификации с помощью паролей» . IETF . Март 2011 года . Проверено 4 августа 2023 г.
^ Курт Зейленга (19 мая 2010 г.). «SCRAM в LDAP. Улучшенная аутентификация на основе пароля» (PDF) . Проверено 4 августа 2023 г.
^ Саймон Йозефссон (6 февраля 2011 г.). «Лабиринт сетевой безопасности GNU» (PDF) . Проверено 4 августа 2023 г.
^ «Механизм аутентификации соленого запроса-ответа (SCRAM) SASL и механизмы GSS-API: имена механизмов SCRAM» . IETF. Июль 2010 года . Проверено 4 августа 2023 г.
^ «Текстовые имена хеш-функций» . ИАНА . 16 декабря 2019 г. Проверено 4 августа 2023 г.
^ «Об использовании привязок каналов для защиты каналов: процедура регистрации» . IETF. Ноябрь 2007 года . Проверено 4 августа 2023 г.
^ «Привязки каналов для TLS: тип привязки канала tls-server-end-point» . IETF. Июль 2010 года . Проверено 4 августа 2023 г.
^ «SCRAM: новый протокол аутентификации паролей» . 19 мая 2010 года . Проверено 27 мая 2024 г.
^ Jump up to: ^а ^б Тобиас Маркманн (2 декабря 2009 г.). "Скрам-ДАЙДЖЕСТ-MD5!" . Архивировано из оригинала 17 апреля 2021 г. Проверено 4 августа 2023 г.
^ «RFC6331: перемещение DIGEST-MD5 в исторический формат» . IETF. Июль 2011 года . Проверено 4 августа 2023 г.
^ «CRAM-MD5 в исторический» . IETF. Ноябрь 2008 года . Проверено 4 августа 2023 г.
^ Тобиас Маркманн (04 августа 2023 г.). «Спи спокойно ночью, зная, что твои пароли в безопасности» . Архивировано из оригинала 17 апреля 2021 г.

Внешние ссылки

RFC 5802 , Механизм аутентификации ответа на запрос (SCRAM) SASL и механизмы GSS-API
RFC 5803 , Схема облегченного протокола доступа к каталогу (LDAP) для хранения секретов механизма аутентификации ответа на вызов (SCRAM)
RFC 6120 , Расширяемый протокол обмена сообщениями и присутствия (XMPP): ядро
RFC 6331 , перемещение DIGEST-MD5 в исторический формат
RFC 7677 , SCRAM-SHA-256 и SCRAM-SHA-256-PLUS: механизмы простого уровня аутентификации и безопасности (SASL).
RFC 7804 , Механизм аутентификации HTTP с ответом на вызов
RFC 8600 , Использование расширяемого протокола обмена сообщениями и присутствия (XMPP) для обмена информацией о безопасности.
RFC 8621 , Протокол метаприложений JSON (JMAP) для почты.
RFC 9051 , Протокол доступа к сообщениям в Интернете (IMAP) — версия 4rev2
RFC 9266 , Привязки каналов для TLS 1.3
черновик-ietf-sasl-crammd5-to-исторический-00 и черновик-zeilenga-luis140219-crammd5-to-исторический-00 , CRAM-MD5 в исторический
Draft-melnikov-scram-sha-512 , SCRAM-SHA-512 и SCRAM-SHA-512-PLUS Простые механизмы аутентификации и безопасности (SASL)
Draft-melnikov-scram-sha3-512 , SCRAM-SHA3-512 и SCRAM-SHA3-512-PLUS Простые механизмы аутентификации и уровня безопасности (SASL)
Draft-melnikov-scram-bis , Механизм аутентификации ответа на вызов Salted (SCRAM) SASL и механизмы GSS-API
Draft-ietf-kitten-scram-2fa , Расширения для Salted Challenge Response (SCRAM) для двухфакторной аутентификации
Draft-melnikov-sasl2 , Расширяемый простой уровень аутентификации и безопасности (SASL)
Состояние игры , более подробная информация о поддержке SCRAM SASL

[1] «Расширяемый протокол обмена сообщениями и присутствия: для конфиденциальности и аутентификации с помощью паролей» . IETF . Март 2011 года . Проверено 4 августа 2023 г.

[2] Курт Зейленга (19 мая 2010 г.). «SCRAM в LDAP. Улучшенная аутентификация на основе пароля» (PDF) . Проверено 4 августа 2023 г.

[3] Саймон Йозефссон (6 февраля 2011 г.). «Лабиринт сетевой безопасности GNU» (PDF) . Проверено 4 августа 2023 г.

[4] «Механизм аутентификации соленого запроса-ответа (SCRAM) SASL и механизмы GSS-API: имена механизмов SCRAM» . IETF. Июль 2010 года . Проверено 4 августа 2023 г.

[5] «Текстовые имена хеш-функций» . ИАНА . 16 декабря 2019 г. Проверено 4 августа 2023 г.

[6] «Об использовании привязок каналов для защиты каналов: процедура регистрации» . IETF. Ноябрь 2007 года . Проверено 4 августа 2023 г.

[7] «Привязки каналов для TLS: тип привязки канала tls-server-end-point» . IETF. Июль 2010 года . Проверено 4 августа 2023 г.

[8] «SCRAM: новый протокол аутентификации паролей» . 19 мая 2010 года . Проверено 27 мая 2024 г.

[ayena-digest-9] Jump up to: ^а ^б Тобиас Маркманн (2 декабря 2009 г.). "Скрам-ДАЙДЖЕСТ-MD5!" . Архивировано из оригинала 17 апреля 2021 г. Проверено 4 августа 2023 г.

[10] «RFC6331: перемещение DIGEST-MD5 в исторический формат» . IETF. Июль 2011 года . Проверено 4 августа 2023 г.

[11] «CRAM-MD5 в исторический» . IETF. Ноябрь 2008 года . Проверено 4 августа 2023 г.

[12] Тобиас Маркманн (04 августа 2023 г.). «Спи спокойно ночью, зная, что твои пароли в безопасности» . Архивировано из оригинала 17 апреля 2021 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]