CRAM (Challenge-Response Authentication Mechanism)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 18:13, 28 февраля 2019.
CRAM
Communications protocol
Purpose Сhallenge–response authentication mechanisms
Developer(s) Krawczyk Hugo,Canetti Ran
Introduced 1997; 23 years ago (1997)
Based on HMAC
Influenced TLS,SSL
OSI layer Application layer
RFC(s) RFC 2104, RFC 822

CRAM (англ. Challenge-Response Authentication Mechanism) Проверка подлинности с ответом на вызов - это тип протокола проверки подлинности, в котором одна сущность представляет проблему или вопрос, а другая сущность предоставляет допустимый ответ для проверки подлинности. Проверка подлинности ответа на вызов - это тип метода проверки подлинности, используемый для подтверждения личности пользователя или другой сущности, запрашивающей доступ к компьютеру, сети или другому сетевому ресурсу, использующий криптографический протокол, который позволяет доказать, что пользователь знает пароль, не раскрывая сам пароль. С помощью этого метода, приложение сначала получает случайный запрос с сервера. Затем оно вычисляет ответ, применив криптографическую хеш-функцию к запросу сервера в сочетании с паролем пользователя. И, наконец, приложение посылает ответ вместе с оригинальным запросом обратно на сервер. Из-за "односторонних" свойств хэш-функции, невозможно восстановить пароль из ответа, посланного приложением.[Источник 1].


Описание

Рисунок 1 - The authentication type associated with CRAM is "CRAM-MD5".

При проверке подлинности "вызов-ответ" клиентское приложение изначально получает от сервера случайную задачу-обычно данные определенного типа. Для систем ответа на вызов на основе пароля клиентская система вычисляет ответ путем применения криптографической хэш-функции к вызову с сервера в сочетании с паролем пользователя. Затем приложение отправляет ответ, а также исходный вызов обратно на сервер. Когда сервер получает ответ, он применяет ту же функцию хэширования к данным вызова в сочетании с собственной копией пароля пользователя. Если результирующее значение и ответ, отправленный приложением, совпадают, существует очень высокая степень вероятности, что пользователь предоставил правильный пароль. Данные, закодированные в первом ответе содержат произвольную строку случайных цифр, отметку о времени, и полное основное имя хоста сервера. Синтаксис неперекодированной формы должен соответствовать тому из RFC 822 'MSG-ID' как описано в POP3 (Post Office Protocol v3). Клиент делает запись данных, а затем отвечает строкой состоящей из имени пользователя, пробел, и дайджеста. Последнее вычисляется путем применения алгоритма MD5 с ключом из Keyed-MD5, где ключ является общим секретом, а дайджестом - временная метка (включая угловые скобки). Этот общий секрет является строкой, известной только клиенту и серверу. Параметр дайджест сам по себе является значением длиной 16-октетов, которое отправляется в шестнадцатеричном формате, используя строчные символы ASCII. Когда сервер получает этот ответ клиента, он проверяет дайджест. Если дайджест правильный, сервер должен принять, что клиент аутентифицирован и реагировать дальше соответствующим образом. Keyed MD5 был выбран из-за большей безопасности для аутентификации коротких сообщений. К тому же, использование методов, описанных в работах KEYED-MD5 для предвычисления промежуточных результатов, позволяют избежать явного хранения общего секрета открытым текстом на стороне сервера, путем хранения промежуточные результаты, которые известны как "контекстами".[Источник 2].

CRAM не поддерживает механизм защиты.

Пример

Простейший способ такой аутентификации (при хранении паролей в открытом виде):

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

Использование механизма CRAM с командой IMAP4 AUTHENTICATE IMAP-AUTH:

Кодирование base64 запросов и ответов - часть команды IMAP4 AUTHENTICATE, а не спецификации CRAM.

 S: * OK IMAP4 Server
 C: A0001 AUTHENTICATE CRAM-MD5
 S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
 C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
 S: A0001 OK CRAM authentication successful

Пусть общий секрет - 'tanstaaftanstaaf'. Здесь Keyed-MD5 дайджест получается с помощью вычисления

 MD5((tanstaaftanstaaf XOR opad),
 MD5((tanstaaftanstaaf XOR ipad),
 <1896.697170952@postoffice.reston.mci.net>))

где ipad и opad определены в Keyed-MD5 Work in Progress KEYED-MD5, а строка, показанная в вызове является base64 от <1896.697170952@postoffice.reston.mci.net>. Общий секрет дополнен нулями до длины 64 байта. Если он превышает эту длину, MD5 дайджест секрета используется как 16 байтовый вход для keyed MD5.

Получаем значение дайджеста (в шестнадцатеричном формате):

   b913a602c7eda7a495b4e6e7334d3890

Имя пользователя затем добавляется к нему, образуя

   tim b913a602c7eda7a495b4e6e7334d3890

Которое потом кодируется base64 согласно требованиям команды IMAP4 AUTHENTICATE

   dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw

Вопросы безопасности

Высказано предположение, что использование механизма аутентификации CRAM обеспечивает идентификацию происхождения и защиту воспроизведения для сеанса. Соответственно, сервер, который реализует одновременно команду читаемых паролей и этот тип аутентификации, не должен допускать оба метода доступа для данного пользователя.[Источник 3]. Даже при использовании CRAM, пользователи по-прежнему уязвимы для активной атаки. Примером более распространенной активной атаки является 'TCP Session Hijacking', как описано в CERT Advisory CA-95: 01 CERT95.

Источники

  1. Challenge-Response Authentication // Zenfolio.[2016-2019] Дата обновления 22.02.17. URL: https://www.zenfolio.com/zf/help/api/guide/auth/auth-challenge/ (дата обращения: 25.01.2019)
  2. Challenge-response authentication // Searchsecurity.[2017-2019] Дата обновления 13.12.17. URL: https://searchsecurity.techtarget.com/definition/challenge-response-system (дата обращения: 25.01.2019)
  3. Challenge-Response Authentication // Wikipedia.[2018-2019] Дата обновления 22.09.18. URL: https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication (дата обращения: 25.01.2019)