SCRAM

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

Передумови

• Потребу в механізмі, який би підтримував усі нові можливості, що описані в SASL: підтримка інтернаціоналізованих логінів і паролів, підтримка здійснення єдиності автентифікації, підтримка прив'язки каналу.
• Потреба в протоколі двосторонньої автентифікації.
• Бажання щоб збережена в ідентифікаційній базі даних інформація була недостатньою для того, щоб зловмисник міг видати себе за клієнта.
• Необхідність у тому, щоб у сервера не було можливості видати себе за клієнта перед іншим сервером(виключаючи проксі-сервер авторизації).
• Суттєва необхідність у механізмі, який простіший в реалізації, ніж вже наявний(DIGEST-MD5).

В цілому, всі передумови показують недоліки інших механизмів аутентифікації. Тому у червні 2010 року було створено SCRAM, позбавлений проблем інших механизмів, який відповідає вимогам сучасності.

Загальна схема

Розглянемо нижче опис повного обміну автентифікаційними даними, в якому використовується стиснення SASL SCRAM .

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

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

Надійність механізму

У випадках коли SCRAM використовують без додаткового рівня безпеки, наприклад TLS , то пасивний перехоплювач може отримати достатню кількість інформації для організації повного перебору його пароля в офлайн режимі. Кількість часу, необхідне для підбору пароля, залежить від використовуваної криптографічної геш-функції, складності пароля. Зовнішній шар мережевої безпеки запобігає цій атаці.

У мережах з TLS, механізм прив'язки порту може бути використаний для виявлення атаки типу людина посередині. Однак, у атакуючого з'явиться можливість для офлайн брутфорс-атаки.

У разі крадіжки автентифікаційної інформації з автентифікаційної бази даних, з допомогою брутфорс-атаки можна буде отримати пароль користувача. Використовувана сіль пом'якшує вплив цієї атаки, змушуючи підбирати кожен пароль окремо.

Важливим є той факт, що ефективність будь-якого механізму автентифікації на основі пароля буде сильно залежати від дотримання користувачем політики паролів.

На практиці SCRAM є одним з найбільш безпечних механізмів автентифікації на основі пароля.

Інші механізми автентифікації

• DIGEST-MD5 механізм дуже складний в реалізації і тестуванні, що робить його слабо сумісними. Рівень безпеки в ньому часто не реалізується. Замість цього повсюдно використовується TLS.
• CRAM-MD5 SASL механізм, попри свою широку поширеність, теж має свої проблеми. Зокрема, в ньому відсутні деякі нові SASL можливості, такі як можливість використання міжнародних логінів і паролів. Також відсутні можливості автентифікації сервера і прив'язки каналу.
• PLAIN SASL механізм дозволяє здійснити атаку перехоплення автентифікації і перенесення її на інший сервер, де користувач має такий же пароль. Пересилає пароль у відкритому вигляді у випадку, якщо мережа не використовує TLS.

Переваги SCRAM

• Інформація для автентифікації зберігається в спеціальній базі даних. Цієї інформації недостатньо, щоб представитися клієнтом перед іншим сервером.
• До всієї інформації в базі застосовується сіль, що запобігає перебору по словнику.
• Механізм дозволяє використовувати проксі сервери авторизації, не вимагаючи при цьому наявності у проксі-сервера прав суперкористувача на сервері.
• Двостороння автентифікація підтримується, але в той же час ім'я є тільки у клієнта (сервер ім'ям не ідентифікується).
• При використанні в якості SASL механізму, SCRAM здатний передавати та ідентифікаційні дані від клієнта до сервера.
• Для простоти SCRAM не включає в себе узгодження на рівні безпеки. Передбачається використання з зовнішнім шаром безпеки, що надаються TLS або SSH.

• Створювався для використання з будь-яким геш-алгоритмом, тому має великий потенціал для покращення криптостійкості схеми. Під час розробки передбачалося використання SHA-1

Оскільки SCRAM створювався для того, щоб виправити недоліки попередніх механізмів, то описані вище проблеми йому не притаманні (його основною перевагою є відсутність недоліків).

Варто відзначити, що SCRAM хоч і є в чистому вигляді SASL-механізмом, але в той же час він повністю відповідає вимогам до GSS-API механізму.

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

Заснована на паролі схема безпеки спирається на загальний секрет, який відомий двом сторонам. Це тягне за собою труднощі в управлінні налаштуваннями безпеки між багатьма частинами системи. Це також створює проблему доставки секретної інформації в різні точки. Для PKI, один закритий ключ можна захистити дуже надійно, наприклад, зберігаючи його на смарт-карті, що дасть додатковий фактор автентифікації, а також забезпечення захисту.

Автентифікація на основі PKI є кращим вибором для:

• автентифікації сервер-сервер
• автентифікації користувач-користувач
• автентифікації з високим рівнем безпеки

Аутентифікація на основі пароля краще, бо

• апаратний підхід до автентифікації коштує набагато дорожче.

Примітки

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.

Література

• 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.