Механизм аутентификации с ответом на соленый вызов

редактировать

В криптографии Механизм аутентификации с ответом на соленый запрос (SCRAM ) - это семейство современных механизмов аутентификации запрос – ответ на основе паролей, обеспечивающих аутентификацию пользователя на сервере. Как указано для Simple Authentication and Security Layer (SASL), его можно использовать для входа на основе пароля в такие службы, как SMTP и IMAP (электронная почта ) или XMPP (чат). Для XMPP поддержка является обязательной.

Содержание
  • 1 Мотивация
  • 2 Обзор протокола
    • 2.1 Сообщения
    • 2.2 Соленый пароль
    • 2.3 Доказательства
    • 2.4 Сохраненный пароль
    • 2.5 Канал привязка
  • 3 Сильные стороны
  • 4 Ссылки
  • 5 Внешние ссылки
Мотивация

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

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

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

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

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

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

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

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

Сообщения

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

client-first
Сообщение client-first состоит из gs2-заголовка, желаемого имя пользователяи случайно сгенерированный одноразовый номер клиента cnonce.
server-first
Сервер добавляет к этому клиентскому nonce свой собственный одноразовый номер snonceи добавляет его в сообщение server-first, которое также содержит salt, используемый сервером для добавления хэша пароля пользователя, и индикатор количества итераций it.
client-final
После этого клиент отправляет сообщение client-final, которое содержит c-bind-input, объединение клиента и одноразового номера сервера и cproof.
server-final
Связь закрывается с сервером- заключительное сообщение, которое содержит доказательство сервера sproof.

Salted password

Salted password spasswordрассчитывается следующим образом:

spassword = Hi (пароль, соль, итерации)

где Hi (p, s, i)определяется как PBKDF2 (HMAC, p, s, i, длина вывода H).

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

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

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

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

ckey = HMAC (spassword, 'Client Key ')
skey = HMAC (spassword,' Server Key ')
cproof = ckey XOR HMAC (H (ckey), Auth)
sproof = HMAC (skey, Auth)

где Операция XOR применяется к байтовым строкам одинаковой длины, H (ckey)- это обычный хэш ckey. «Ключ клиента»и «Ключ сервера»- это дословные строки.

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

Сохраненный пароль равен H (ckey). В приведенном выше алгоритме клиент доказывает, что знает ckey, который затем хешируется и сравнивается с тем, что хранится на сервере.

Для каждого пользователя сервер должен хранить только имя пользователя, H (ckey), skey, saltи . это, но не сам текстовый пароль.

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

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

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

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

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

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

Сильные стороны
  • Надежное хранилище паролей: при правильной реализации сервер может хранить пароли в соленом, повторяющемся хеш-формате, делая автономные атаки сложнее и снижает влияние взломов базы данных.
  • Простота: реализация SCRAM проще, чем DIGEST-MD5.
  • Международная совместимость: RFC требует, чтобы UTF-8 был используется для имен пользователей и паролей, в отличие от CRAM-MD5.
  • Поскольку во всем процессе входа используется только соленая и хешированная версия пароля, а соль на сервере не изменяется, клиент сохраняет пароли может хранить хешированные версии и не раскрывать злоумышленникам пароль в открытом виде. Такие хешированные версии привязаны к одному серверу, что делает это полезным при повторном использовании паролей.
Ссылки
Внешние ссылки
Последняя правка сделана 2021-06-06 08:42:16
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте