SCRAM

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

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

Предпосылки[править | править исходный текст]

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

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

Общая схема[править | править исходный текст]

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

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

  • «:=»: Переменная слева обозначает последовательность 8-ми битных байтов.
  • «+»: Объединение байтовых строк.
  • «[ ]»: Часть выражения заключенного в «[» и «]» не может быть включена в результат при некоторых обстоятельствах. Такие обстоятельства будут описаны отдельно.
  • 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() по сути является генератором псевдослучайных чисел.

Перед началом процесса SCRAM-клиент имеет в своем распоряжении имя пользователя и пароль. Клиент посылает имя пользователя на сервер, который достает из базы данных сведения(solt, StoredKey, ServerKey, i), соответствующие полученным данным. Сервер посылает solt и итерационный счетчик клиенту, который вычисляет значения следующих величин и посылает серверу 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].

Другие механизмы аутентификации[править | править исходный текст]

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

Преимущества SCRAM[править | править исходный текст]

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

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

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

Аутентификация не использующая пароль[править | править исходный текст]

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

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

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

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

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

Примечания[править | править исходный текст]

Источники[править | править исходный текст]