SCRAM

SCRAM (Salted Challenge Response Authentication Mechanism, RFC 5802. Архів оригіналу за 18 грудня 2013. Процитовано 5 квітня 2018.) — механізм зберігання даних і протокол автентифікації за допомогою пароля. 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() по суті є генератором псевдовипадкових чисел. Перед початком процесу 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. — 2010-05-19.
RFC 4422. — 2006.
RFC 6287. — 2011. — ISSN 2070-1721.
RFC 5802. — 2010. — ISSN 2070-1721.
RFC 1994. — 1996.
RFC 3454. — 2002.
RFC 4616. — 2006.
Melnikov, A. Moving DIGEST-MD5 to Historic. — 2008-07-10.
Zeilenga, K. CRAM-MD5 to Historic. — 2008-11.

[FOOTNOTERFC_44222006-1] RFC 4422, 2006.

[FOOTNOTESCRAM:_A_New_Protocol_for_Password_Authentication2010-2] а ^б ^в ^г ^д ^е ^ж SCRAM: A New Protocol for Password Authentication, 2010.

[FOOTNOTERFC_58022010-3] а ^б ^в ^г ^д ^е ^ж ^и RFC 5802, 2010.

[FOOTNOTERFC_34542002-4] RFC 3454, 2002.

[FOOTNOTERFC_36292003-5] RFC 3629, 2003.

[FOOTNOTEMoving_DIGEST-MD5_to_Historic2008-6] Moving DIGEST-MD5 to Historic, 2008.

[FOOTNOTECRAM-MD5_to_Historic2008-7] CRAM-MD5 to Historic, 2008.

[FOOTNOTERFC_46162006-8] RFC 4616, 2006.

[1]