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

Salted Challenge Response Authentication Mechanism

В криптографии Механизм аутентификации с ответом на соленый вызов (КАТИСЬ) - это семейство современных парольных проверка подлинности запрос – ответ механизмы, обеспечивающие аутентификацию пользователя на сервере. Как указано для Уровень простой аутентификации и безопасности (SASL), его можно использовать для входа на основе пароля в такие службы, как SMTP и IMAP (электронное письмо), или же XMPP (чат). Для XMPP поддержка обязательна.[1]

Мотивация

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

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

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

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

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

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

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

Хотя все клиенты и серверы должны поддерживать SHA-1 алгоритм хеширования, SCRAM, в отличие от CRAM-MD5 или же ДАЙДЖЕСТ-MD5, независимо от базовой хеш-функции.[3] Все хэш-функции, определенные IANA можно использовать вместо этого. Как упоминалось в разделе «Мотивация», SCRAM использует PBKDF2 механизм, повышающий стойкость к атаки методом перебора, когда на сервере произошла утечка данных. ЧАС быть выбранной хеш-функцией, заданной именем алгоритма, объявленного сервером и выбранного клиентом. Например, «SCRAM-SHA-1» использует SHA-1 в качестве хэш-функции.

Сообщения

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

клиент в первую очередь
В клиент в первую очередь сообщение состоит из gs2-заголовок, желаемый имя пользователя, и случайно сгенерированный клиентский одноразовый номер cnonce.
сервер-первый
Сервер добавляет к этому клиентскому nonce свой собственный nonce snonce, и добавляет его в сервер-первый сообщение, которое также содержит соль используется сервером для соления хэша пароля пользователя, и индикатор количества итераций Это.
клиент-финал
После этого клиент отправляет клиент-финал сообщение, которое содержит c-bind-input, объединение клиента и одноразового номера сервера, и доказательство.
сервер-финал
Общение закрывается сервер-финал сообщение, которое содержит доказательство сервера росток.

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

Соленый пароль spassword рассчитывается следующим образом:

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

куда Привет (p, s, i) определяется как PBKDF2 (HMAC, п, s, я, длина вывода ЧАС).

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

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

Auth = client-first-without-header + ',' + server-first + ',' + client-final-без доказательства (соединены запятыми)

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

ckey = HMAC (пароль; 'Клиентский ключ')
skey = HMAC (пароль, 'ключ сервера')
cproof = ckey XOR HMAC (H (ckey), Auth)
sproof = HMAC (skey, Auth)

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации

  1. ^ «RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core».
  2. ^ Курт Зейленга (19 мая 2010 г.). «SCRAM в LDAP, улучшенная аутентификация на основе пароля» (PDF). Получено 24 января 2014.
  3. ^ "RFC 5802, раздел 4".
  4. ^ "RFC 5056 раздел-7.1".
  5. ^ "RFC 5929 раздел 4".
  6. ^ «SCRAM: новый протокол для аутентификации пароля». 19 мая 2010 года. Получено 24 января 2014.
  7. ^ а б Тобиас Маркманн (2 декабря 2009 г.). "Взломай ДАЙДЖЕСТ-МД5!". Получено 23 января 2014.
  8. ^ «ДАЙДЖЕСТ-МД5 к историческому».
  9. ^ CRAM-MD5 в Исторический
  10. ^ Тобиас Маркманн (9 июня 2010 г.). «Спите спокойно по ночам, зная, что ваши пароли в безопасности».

внешняя ссылка