SCRAM (Salted Challenge Response Authentication Mechanism)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 20:31, 21 декабря 2017.

SCRAM (англ. Salted Challenge Response Authentication Mechanism, RFC 5802.) — механизм хранения данных и протокол аутентификации посредством пароля. SCRAM относится к механизмам SASL уровня, что делает возможным его использование вместе с некоторыми стандартными протоколами, использующими SASL: SMTP, LDAP, IMAP и POP. Также Scram является GSS-API механизмом. Поддерживает привязку канала и двухстороннюю аутентификацию. На момент написания статьи является наиболее совершенным и многофункциональным.

Предпосылки

Необходимость в механизме, который бы поддерживал все новые возможности описанные в SASL: поддержка интернационализованных логинов и паролей, поддержка осуществления единственности аутентификации, поддержка привязки канала. Потребность в протоколе двухсторонней аутентификации. Желание чтобы хранимая в идентификационной базе данных информация была недостаточной для того, чтобы злоумышленник мог выдать себя за клиента. Необходимость в том, чтобы у сервера не было возможности выдать себя за клиента перед другим сервером(исключая прокси-сервер авторизации). Существенная необходимость в механизме, который проще в реализации, чем уже имеющийся(DIGEST-MD5). В целом, все предпосылки отражают недостатки других механизмов аутентификации. Поэтому в июне 2010 был создан SCRAM, лишенный проблем других механизмов, и отвечающий запросам своего времени. [Источник 1].

Общая схема

Scram2.png

Рассмотрим ниже описание полного, не использующего сжатие SASL SCRAM обмена аутентификационными данными. Для нижеследующего описания псевдокода алгоритма будут использованы следующие обозначения:

  • =[/code>: Переменная слева обозначает последовательность восьмибитных байтов, полученных в результате вычисления выражения справа.
  • <code>+ Объединение байтовых строк.
  • [ ]: Часть выражения заключенного в [ и ] не может быть включена в результат при некоторых обстоятельствах. Такие обстоятельства будут описаны отдельно.
  • Normalize(str): реализация функции описанной в SASLprep стандарте выполняющей «stringprep» алгоритм как алгоритм нормализации для строки «str», кодированной UTF-8. Результатом работы функции также является строка кодированная в UTF-8.
  • HMAC(key, str): Некоторая реализация HMAC-функции, которая на вход получает key и str выдает последовательность байт, по которой можно проверить целостность информации.
  • H(str): реализация некоторой Hash-функции, которая принимает на вход строку, а в результате работы выдает последовательность байтов, длина которой зависит от самой функции.
  • XOR: Побитовый комплемент.
  • Функция
 Hi(str, salt, i):
  U1 := HMAC(str, salt + INT(1))
  U2 := HMAC(str, U1)
  …
  Ui-1 := HMAC(str, Ui-2)
  Ui := HMAC(str, Ui-1)
  Hi := U1 XOR U2 XOR … XOR Ui 

где «i» — номер итерации, +— оператор суммирования строк, а INT(g) — это четырёх-байтовое представление целочисленного g (первый октет является старшим), salt - это криптографическая соль. В действительности Hi() по сути является генератором псевдослучайных чисел.

Перед началом процесса SCRAM-клиент имеет в своём распоряжении имя пользователя и пароль. Клиент посылает имя пользователя на сервер, который достаёт из базы данных сведения (salt, StoredKey, ServerKey, i), соответствующие полученным данным. Сервер посылает salt и итерационный счётчик клиенту, который вычисляет значения следующих величин и посылает серверу ClientProof.

      SaltedPassword  := Hi(Normalize(password), salt, i)
      ClientKey       := HMAC(SaltedPassword, "Client Key")
      StoredKey       := H(ClientKey)
      AuthMessage     := client-first-message-bare + "," + server-first-message + "," + client-final-message-without-proof
      ClientSignature := HMAC(StoredKey, AuthMessage)
      ClientProof     := ClientKey XOR ClientSignature
      ServerKey       := HMAC(SaltedPassword, "Server Key")
      ServerSignature := HMAC(ServerKey, AuthMessage)

Сервер проверяет подлинность клиента путём вычисления ClientSignature и последующего применения операции исключающего-ИЛИ с ClientProof, для восстановления ClientKey и проверки правильности ClientKey путём применения hash-функции и сравнения результата со StoredKey. Если ClientKey правильный, то это доказывает наличие у клиента доступа к паролю пользователя. Аналогично, клиент выполняет аутентификацию сервера путём вычисления ServerSignature и сравнением его со значением, которое отправил сервер. Если они равны, то это доказывает, что у сервера был доступ к ServerKey пользователя.
AuthMessage вычисляется путём объединения сообщений участвовавших в аутентификационном обмене.
Таким образом SCRAM позволяет аутентифицировать пользователя на сервере по его имени и паролю, и позволяет аутентифицировать сервер для клиента, но при этом сервер оказывается неназванным.
Такая схема говорит о том, что секретом в данном случае являются:

  • Захешированные значения StoredKey и ServerKey
  • Значение соли
  • Итерационный параметр

Пример диалога между сервером «S» и клиент «C» в процессе аутентификации

   C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
   S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,
      i=4096
   C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
      p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
   S: v=rmF9pqV8S7suAoZWja4dJRkFsKQ=  

Надёжность механизма

Scram3.jpg
В случаях когда SCRAM используют без дополнительного уровня безопасности, TLS например, то пассивный перехватчик может получить достаточное количество информации для организации полного перебора его пароля в офлайн режиме. Количество времени, необходимое для подбора пароля, зависит от используемой криптографической хэш-функции, сложности пароля. Внешний слой сетевой безопасности предотвращает эту атаку.
В сетях с TLS механизм привязки порта может быть использован для обнаружения атаки типа человек посередине. Тем не менее, у атакующего появится возможность для офлайн атаки.
В случае кражи аутентификационной информации из аутентификационной базы данных, с помощью брутфорс-атаки можно будет получить пароль пользователя. Используемая соль смягчает влияние этой атаки, вынуждая подбирать каждый пароль по отдельности.
Важным является тот факт, что эффективность любого механизма аутентификации на основе пароля будет сильно зависеть от соблюдения пользователем политики паролей.
На практике SCRAM является одним из наиболее безопасных механизмов аутентификации на основе пароля.

Другие механизмы аутентификации

  • DIGEST-MD5 механизм очень сложен в реализации и тестировании, что делает его слабо совместимым. Уровень безопасности в нём часто не реализуется. Вместо этого повсеместно используется TLS.
  • CRAM-MD5 SASL механизм, несмотря на свою широкую распространённость, тоже имеет свои проблемы. В частности, в нём отсутствуют некоторые новые SASL возможности, такие как возможность использования международных логинов и паролей. Также отсутствуют возможности аутентификации сервера и привязки канала.
  • PLAIN SASL механизм позволяет осуществить атаку перехвата аутентификации и переноса её на другой сервер, где пользователь имеет такой же пароль. Пересылает пароль в открытом виде в случае, если сеть не использует TLS.

Применение на примере

Scram1.png

Маша хочет зайти на сервер Васи. Ей нужно доказать, что она такая, кем она себя утверждает. Для решения этой проблемы аутентификации Маша и Вася согласились на пароль, который Маша знает, и какой Вася знает, как проверить.
Теперь Маша может отправить свой пароль по незашифрованному соединению с Васей в ясной текстовой форме, чтобы проверить его. Это, тем не менее, сделает пароль доступным для стороннего человека, который прослушивает линию. Маша и Вася могли попытаться обойти это, зашифровав соединение. Тем не менее, Маша не знает, было ли шифрование настроено Васей, а не сторонним человеком, который соверщил атаку. Поэтому Маша отправляет хешированную версию своего пароля, например, в CRAM-MD5 или DIGEST-MD5. Поскольку это хэш, сторонний человек не может получить пароль сам.
И поскольку хеш солидарен с вызовом, сторонний человека мог использовать его только для одного процесса входа в систему. Однако Маша хочет дать Васе некоторую конфиденциальную информацию, и она хочет быть уверенной, что это Вася, а не сторонний человек.
Для решения этого, Вася зарегистрировался в центре сертификации (CA), который подписал его сертификат. Маша могла опираться только на эту систему подписи, но она знает, что она имеет слабые стороны. Чтобы дать ей дополнительную уверенность в том, что нет атаки, Вася создает доказательство того, что он знает пароль (или соленый хэш) и включает в себя его сертификат в это доказательство. Это включение называется связыванием каналов, поскольку нижний канал шифрования «привязан» к более высокому каналу приложения.
У Маши есть аутентификация Васи, а у Васи есть аутентификация Маши. В совокупности они имеют взаимную аутентификацию. DIGEST-MD5 уже включил взаимную аутентификацию, но часто неправильно реализовывался.
Когда сторонний человек создает атаку и подделывает подпись ЦС, она может получить хэш пароля. Но она не смогла выдать Машу даже за один сеанс входа в систему, поскольку Маша включила в свой хэш ключ шифрования стороннего человека , в результате чего у Васи произошел сбой входа в систему. Чтобы сделать полностью прозрачную атаку, сторонний человек должен был знать пароль, используемый Машей, или секретный ключ шифрования Васи.
Вася слышал о нарушениях данных серверных баз данных, и он решил, что не хочет хранить пароли своих пользователей в открытом тексте. Он слышал о схемах входа в систему CRAM-MD5 и DIGEST-MD5, но он знает, что, предлагая эти схемы входа своим пользователям, он должен будет хранить слабо хешированные, "несоленые пароли". Ему не нравится идея, и поэтому он решает потребовать пароли в текстовом виде. Затем он может использовать их с безопасными схемами хэширования, такими как bcrypt, scrypt или PBKDF2, и "солить"(шифровать) их по своему усмотрению. Однако тогда Вася и Маша все еще столкнулись с проблемами, описанными выше. Чтобы решить эту проблему, они используют SCRAM, где Вася может хранить свой пароль в "соленном" формате, используя PBKDF2. Во время входа в систему Вася посылает Маше свою соль и счетчик итераций алгоритма PBKDF2, а затем Маша использует их для вычисления хешированного пароля, который Вася имеет в своей базе данных. Все дальнейшие вычисления в SCRAM основываются на этом значении, которое оба знают.

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

Хотя все клиенты и серверы должны поддерживать алгоритм хэширования SHA-1, SCRAM, в отличие от CRAM-MD5 или DIGEST-MD5, не зависит от базовой хэш-функции. Вместо этого можно использовать все функции хеширования, определенные IANA. Как говорилось, SCRAM использует механизм PBKDF2, который увеличивает силу против атак на грубую силу, когда утечка данных произошла на сервере. Пусть H {\ displaystyle H} H - выбранная хеш-функция, заданная именем алгоритма, рекламируемого сервером и выбранного клиентом. Например, SCRAM-SHA1 использует SHA1 как хеш-функцию.
[Источник 2].

Сообщения

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

  • Первый клиент

    Первое сообщение клиента состоит из флага gs2-cbind, желаемого имени пользователя и случайно сгенерированного клиента {nonce c}.

  • Первый сервер

    Сервер присоединяет к этому клиенту свой собственный {nonce c} и добавляет его к первому сообщению сервера, которое также содержит {salt}, используемый сервером для засорения хэша паролей пользователя и индикатор количества итераций {it '}

  • Финальный клиент

    После этого клиент отправляет клиенту-окончательное сообщение, содержащее c-bind-input, конкатенацию клиента и сервера nonce и доказательство {proofc} всех отправленных сообщений и содержимое клиентского финалиста до доказательства.

  • Конечный сервер

    Связь завершается сообщением «сервер-окончание», которое содержит подтверждение сервера {'proofs}

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

Соленый пароль p вычисляется следующим образом:      password{s} = H {i} (пароль, соль, итерации) где H i (p, s, i) определяется как PBKDF2 (HMAC, p, s, i, длина вывода H).

"Proofs"

Клиент и сервер доказывают друг другу, что они имеют одну и ту же переменную {Auth}, состоящую из: Auth=client-first,server-first, client-final-without-proof {proofs} высчитываются как: Scram.png [Источник 3].

Связывание каналов

Стратегия предотвращения атак типа «сверху вниз» для «привязки» к прикладному уровню, который обеспечивает взаимную аутентификацию, к более низкому (в основном шифрованию) уровню, гарантируя, что конечные точки соединения одинаковы для обоих слои. Существует два основных направления связывания каналов: уникальное и привязка канала конечной точки. Первое гарантирует, что конечные точки одинаковы.
Существует несколько типов привязки каналов, каждый из которых имеет уникальный префикс привязки канала . Каждый тип привязки каналов указывает содержимое данных привязки канала, которое предоставляет уникальную информацию о канале и конечных точках. Например, для привязки канала tls-server-end-point это сертификат TLS сервера. Пример использования связывания канала с SCRAM в качестве прикладного уровня может быть с защитой транспортного уровня (TLS) в качестве нижнего уровня. В то время как TLS защищает от пассивного подслушивания, он сам по себе не предотвращает атаки «человек в середине». Для этого конечные точки должны обеспечивать соответствие идентификаторов друг другу, которые предоставляются SCRAM.
Переменная SCRAM gs2-cbind-flag указывает, поддерживает ли клиент связывание канала или считает, что сервер не поддерживает привязку канала, а вход c-bind содержит флаг gs2-cbind вместе с уникальным префиксом привязки канала и данные привязки канала сами.
Связывание каналов необязательно в SCRAM, а переменная gs2-cbind-flag предотвращает атаки с понижением.
Когда сервер поддерживает привязку канала, он добавляет последовательность символов «-PLUS» к объявленному имени алгоритма SCRAM.

Преимущества SCRAM

  • Информация для аутентификации хранится в специальной базе данных. Этой информации недостаточно, чтобы представиться клиентом перед другим сервером.
  • Ко всей информации в базе применяется соль, что предотвращает перебор по словарю.
  • Механизм позволяет использовать сервера прокси авторизации, не требуя при этом наличия у прокси-сервера прав суперпользователя на сервере.
  • Двухсторонняя аутентификация поддерживается, но в то же время имя есть только у клиента.(Сервер именем не идентифицируется.)
  • При использовании в качестве SASL механизма, SCRAM способен передавать и идентификационные данные от клиента к серверу.
  • Для простоты SCRAM не включает в себя согласование на уровне безопасности. Предполагается использование с внешним слоем безопасности, предоставляемым TLS или SSH.
  • Создавался для использования с любым хэш-алгоритмом, поэтому имеет большой потенциал для улучшения криптостойкости схемы. Во время разработки предполагалось использование SHA-1.

Поскольку SCRAM создавался для того, чтобы исправить недостатки предшествующих ему механизмов, то описанные выше проблемы ему не присущи (его основным преимуществом является отсутствие недостатков).
Стоит отметить, что SCRAM хоть и является в чистом виде SASL-механизмом, но в то же время он полностью соответствует требованиям к GSS-API механизму.

Аутентификация, не использующая пароль

Основанная на паролях схема безопасности опирается на общий секрет, который известен двум сторонам. Это влечёт за собой трудности в управлении настройками безопасности между многими частями системы. Это также создаёт проблему доставки секретной информации в разные точки. Для PKI один закрытый ключ можно защитить очень надёжно, например, сохраняя его на смарт-карте, что даст дополнительный фактор аутентификации, а также обеспечения защиты.
Строгая аутентификация на основе PKI является лучшим выбором для:

  • аутентификации сервер-сервер
  • аутентификации пользователь-пользователь
  • аутентификации с высоким уровнем безопасности

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

Ссылки

Видео:

Источники

  1. Scram. Дата обновления: 05.02.2017. URL: https://www.isode.com/whitepapers/scram.html (дата обращения: 29.11.2017.)
  2. Scram. Дата обновления: 08.07.2017. URL: https://wikivisually.com/wiki/Challenge_response(дата обращения: 29.11.2017.)
  3. Scram. Дата обновления: 02.07.2017. URL: https://www.isode.com/whitepapers/scram.html (дата обращения: 29.11.2017.)