SCRAM

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

ПредпосылкиПравить

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

В целом, все предпосылки отражают недостатки других механизмов аутентификации. Поэтому в июне 2010 был создан SCRAM, лишенный проблем других механизмов, и отвечающий запросам своего времени^[3].

Общая схемаПравить

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

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

«:=»: Переменная слева обозначает последовательность восьмибитных байтов, полученных в результате вычисления выражения справа.
«+»: Объединение байтовых строк.
«[ ]»: Часть выражения заключенного в «[» и «]» не может быть включена в результат при некоторых обстоятельствах. Такие обстоятельства будут описаны отдельно.
Normalize(str): реализация функции описанной в SASLprep^[4] стандарте выполняющей «stringprep» алгоритм как алгоритм нормализации для строки «str», кодированной UTF-8^[5]. Результатом работы функции также является строка кодированная в 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() по сути является генератором псевдослучайных чисел и практически равна одному выходному блоку PBKDF2.

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

      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 правильный, то это доказывает наличие у клиента доступа к паролю пользователя^[3].

Аналогично, клиент выполняет аутентификацию сервера путём вычисления ServerSignature и сравнением его со значением, которое отправил сервер. Если они равны, то это доказывает, что у сервера был доступ к ServerKey пользователя.

AuthMessage вычисляется путём объединения сообщений участвовавших в аутентификационном обмене.

Таким образом SCRAM позволяет аутентифицировать пользователя на сервере по его имени и паролю, и позволяет аутентифицировать сервер для клиента, но при этом сервер оказывается неназванным^[3].

Такая схема говорит о том, что секретом в данном случае являются:

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

Пример диалога между сервером «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=

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

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

В сетях с TLS механизм привязки порта может быть использован для обнаружения атаки типа человек посередине. Тем не менее, у атакующего появится возможность для офлайн брутфорс атаки.

В случае кражи аутентификационной информации из аутентификационной базы данных, с помощью брутфорс-атаки можно будет получить пароль пользователя. Используемая соль смягчает влияние этой атаки, вынуждая подбирать каждый пароль по отдельности^[3].

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

На практике SCRAM является одним из наиболее безопасных механизмов аутентификации на основе пароля^[2].

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

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

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

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

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

Стоит отметить, что SCRAM хоть и является в чистом виде SASL-механизмом, но в то же время он полностью соответствует требованиям к GSS-API механизму^[3]^[2].

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

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

Строгая аутентификация на основе PKI является лучшим выбором для:

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

Аутентификация на основе пароля лучше, так как

аппаратный подход к аутентификации стоит намного дороже^[2].

ПримечанияПравить

ЛитератураПравить

SCRAM: A New Protocol for Password Authentication (англ.) // isode.com : электронный журнал. — 2010. — 19 May.
RFC 1994 (англ.). — 1996.
RFC 3454 (англ.). — 2002.
RFC 3629 (англ.). — 2003.
RFC 4422 (англ.). — 2006.
RFC 4616 (англ.). — 2006.
RFC 5802 (англ.). — 2010. — ISSN 2070-1721.
RFC 6287 (англ.). — 2011. — ISSN 2070-1721.
Melnikov, A. Moving DIGEST-MD5 to Historic (англ.). — 2008. — 10 July.
Zeilenga, K. CRAM-MD5 to Historic (англ.). — 2008. — November.

[_f6670ca9aac21b1e-1] RFC 4422, 2006.

[_ad14dd8e10832671-2] ¹ ² ³ ⁴ ⁵ ⁶ ⁷ SCRAM: A New Protocol for Password Authentication, 2010.

[_ed7e99062c7a2414-3] ¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸ RFC 5802, 2010.

[_f4e45c435d0d75e8-4] RFC 3454, 2002.

[_1f533b16b1db30bf-5] RFC 3629, 2003.

[_44cd0456cc0a4fd6-6] Melnikov, 2008.

[_a3e3c3cc9f07862c-7] Zeilenga, 2008.

[_e7cbb414d1028bcb-8] RFC 4616, 2006.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]