В криптографии механизм аутентификации Salted Challenge Response ( SCRAM ) представляет собой семейство современных механизмов аутентификации Challenge-Response на основе пароля , обеспечивающих аутентификацию пользователя на сервере. Как указано для Simple Authentication and Security Layer (SASL), его можно использовать для входа на основе пароля в такие сервисы, как LDAP , HTTP , SMTP , POP3 , IMAP и JMAP ( электронная почта ), XMPP (чат) или MongoDB и PostgreSQL (базы данных). Для XMPP его поддержка обязательна. [1]
Алиса хочет войти на сервер Боба. Ей нужно доказать, что она та, за кого себя выдает. Для решения этой проблемы аутентификации Алиса и Боб договорились о пароле, который Алиса знает, а Боб знает, как проверить.
Теперь Алиса может отправить свой пароль по незашифрованному соединению Бобу в виде открытого текста, чтобы он мог его проверить. Однако это сделало бы пароль доступным для Мэллори, который прослушивает линию. Алиса и Боб могли бы попытаться обойти это, зашифровав соединение. Однако Алиса не знает, было ли шифрование установлено Бобом, а не Мэллори, выполнив атаку «человек посередине» . Поэтому Алиса вместо этого отправляет хэшированную версию своего пароля, как в CRAM-MD5 или DIGEST-MD5 . Поскольку это хэш, Мэллори не получает сам пароль. Поскольку хэш содержит вызов, Мэллори может использовать его только для одного процесса входа в систему. Однако Алиса хочет предоставить Бобу некоторую конфиденциальную информацию и хочет быть уверена, что это Боб, а не Мэллори.
Для решения этой проблемы Боб зарегистрировался в центре сертификации (CA), который подписал его сертификат. Алиса могла полагаться только на эту систему подписи, но она знает, что у нее есть слабые стороны . Чтобы дать ей дополнительную гарантию отсутствия атаки типа «человек посередине», Боб создает доказательство того, что он знает пароль (или его соленый хэш), и включает свой сертификат в это доказательство. Это включение называется привязкой канала, поскольку нижний канал шифрования «привязан» к верхнему каналу приложения.
Затем у Алисы есть аутентификация Боба, а у Боба есть аутентификация Алисы. Вместе они имеют взаимную аутентификацию . DIGEST-MD5 уже включал взаимную аутентификацию, но она часто была неправильно реализована. [2] [3]
Когда Мэллори запускает атаку «человек посередине» и подделывает подпись CA, она может получить хэш пароля. Но она не может выдать себя за Алису даже для одного сеанса входа, так как Алиса включила в свой хэш ключ шифрования Мэллори, что приводит к сбою входа Боба. Чтобы провести полностью прозрачную атаку, Мэллори нужно знать пароль, используемый Алисой, или секретный ключ шифрования Боба.
Боб слышал о взломе данных серверных баз данных, и он решил, что не хочет хранить пароли своих пользователей в открытом тексте. Он слышал о схемах входа 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 называет четыре последовательных сообщения между сервером и клиентом:
usernameи случайно сгенерированного клиентского одноразового номера c-nonce.s-nonceи добавляет его к первому серверному сообщению, которое также содержит saltиспользуемый сервером для добавления соли к хешу пароля пользователя и счетчик итераций iteration-count.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)ServerKeyClientKeyH(ClientKey)
Клиенту нужен только password.
Термин привязка канала описывает стратегию предотвращения атак типа «человек посередине» для «привязки» уровня приложения , который обеспечивает взаимную аутентификацию, к более низкому (в основном шифрованному) уровню, гарантируя, что конечные точки соединения одинаковы на обоих уровнях. Существует два общих направления привязки канала: уникальное и привязка канала конечной точки . Первое гарантирует, что используется определенное соединение, второе — что конечные точки одинаковы.
Существует несколько типов привязки каналов, где каждый тип имеет уникальный префикс привязки канала . [6] Каждый тип привязки канала определяет содержимое данных привязки канала , которые предоставляют уникальную информацию по каналу и конечным точкам. Например, для привязки канала tls-server-end-point это сертификат TLS сервера. [7] Примером использования привязки канала с SCRAM в качестве прикладного уровня может быть Transport Layer Security (TLS) в качестве нижнего уровня. TLS защищает от пассивного подслушивания, поскольку связь зашифрована. Однако, если клиент не аутентифицирует сервер (например, путем проверки сертификата сервера), это не предотвращает атаки типа «человек посередине». Для этого конечные точки должны подтвердить свою идентификацию друг другу, что может быть предоставлено SCRAM.
Переменная SCRAM gs2 -cbind-flag указывает, поддерживает ли клиент привязку каналов или нет, или считает, что сервер не поддерживает привязку каналов, а c-bind-input содержит gs2-cbind-flag вместе с уникальным префиксом привязки каналов и самими данными привязки каналов .
Привязка каналов необязательна в SCRAM, а переменная gs2-cbind-flag предотвращает атаки понижения версии .
Когда сервер поддерживает привязку каналов, он добавляет последовательность символов «-PLUS» к объявленному имени алгоритма SCRAM.