SCRAM

SCRAM (Salted Challenge Response Authentication Mechanism, RFC 5802.) — механізм зберігання даних і протокол автентифікації за допомогою пароля. 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].


Примітки
  1. RFC 4422, 2006.
  2. SCRAM: A New Protocol for Password Authentication, 2010.
  3. RFC 5802, 2010.
  4. RFC 3454, 2002.
  5. RFC 3629, 2003.
  6. Moving DIGEST-MD5 to Historic, 2008.
  7. CRAM-MD5 to Historic, 2008.
  8. RFC 4616, 2006.

Література
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.