PAKEs — протоколы обмена ключами с парольной аутентификацией | OTUS
🔥 Начинаем BLACK FRIDAY!
Максимальная скидка -25% на всё. Успейте начать обучение по самой выгодной цене.
Выбрать курс

Курсы

Программирование
iOS Developer. Basic
-25%
Python Developer. Professional
-25%
Разработчик на Spring Framework
-25%
Golang Developer. Professional
-25%
Python Developer. Basic
-25%
iOS Developer. Professional
-25%
Highload Architect
-25%
JavaScript Developer. Basic
-25%
Kotlin Backend Developer
-25%
JavaScript Developer. Professional
-25%
Android Developer. Basic
-25%
Unity Game Developer. Basic
-25%
Разработчик C#
-25%
Программист С Web-разработчик на Python Алгоритмы и структуры данных Framework Laravel PostgreSQL Reverse-Engineering. Professional CI/CD Vue.js разработчик VOIP инженер Программист 1С Flutter Mobile Developer Супер - интенсив по Kubernetes Symfony Framework Advanced Fullstack JavaScript developer Супер-интенсив "Azure для разработчиков"
Инфраструктура
Мониторинг и логирование: Zabbix, Prometheus, ELK
-25%
DevOps практики и инструменты
-25%
Архитектор сетей
-25%
Инфраструктурная платформа на основе Kubernetes
-25%
Супер-интенсив «ELK»
-16%
Супер-интенсив «IaC Ansible»
-16%
Супер-интенсив "SQL для анализа данных"
-16%
Базы данных Сетевой инженер AWS для разработчиков Cloud Solution Architecture Разработчик голосовых ассистентов и чат-ботов Внедрение и работа в DevSecOps Администратор Linux. Виртуализация и кластеризация Нереляционные базы данных Супер-практикум по использованию и настройке GIT IoT-разработчик Супер-интенсив «СУБД в высоконагруженных системах»
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

PAKEs — протоколы обмена ключами с парольной аутентификацией

Crypto_Deep_16.5_site-5020-5bfb05.png

Сегодня мы поговорим о Пэйках (PAKE, Password Authenticated Key Exchange) — протоколах обмена ключами с парольной аутентификацией. Заметка основана на статье «Should you use SRP» Мэтью Грина и на оригинальной статье Томаса Ву «SPR-6: Improvements and refinements to the secure remote password protocol».

Зачем нужны Пэйки?

Возьмём север, хранящий пароли пользователей в хэшированном виде. При логине, пользователь вводит свой пароль, сервер вычисляет его хэш-значение и сверяет результат с тем, что хранится на сервере. В таком подходе есть очевидная дыра: сервер «видит» пароль пользователя в открытом виде при каждом доступе! Даже если сервер и не сохраняет пароли в открытом виде (а такое происходило), передача подразумевает наличие защищённого канала (TLS).

Криптографический примитив, позволяющий пользователю не отправлять свой пароль на сервер в открытом виде, называется PAKE. Самая распространённая реализация PAKE — SRP (Secure Remote Password), предложенная Томасом Ву в 1998 году. SRP, имеющий прототипом протокол Diffie-Hellman, используется в TLS. Ниже мы расскажем в деталях, как работает протокол SRP.

Как работает PAKE?

PAKE — особая форма протокола обмена ключами, в результате которого клиент (пользователь) и север генерируют на основе открытых данных общий ключ, используемый затем в качестве симметричного ключа. Популярный пример такого протокола -- обмен ключами Diffie-Hellman, в своей примитивной форме страдающий от атак «человек по середине». Протоколы PAKE не уязвимы к такого рода атакам и позволяют пройти аутентификацию зарегистрированному на сервере пользователю без отправки пароля.

PAKE состоит из двух шагов:

– Регистрация (sign up): новый клиент отправляет на сервер проверочный материал для своего пароля. Сервер сохраняет в базе полученный материал для данного Id. – Генерация ключа/логин: клиент и сервер генерируют общий сессионный ключ.

По сути протокол реализует доказательство с нулевым разглашением (zero-knowledge proof). SRP решает два шага PAKE следующим образом. Перед началом общения клиент и сервер располагают общими параметрами: большим простым числом N (вида N = 2*q +1, где q — простое число), g — генератором мультипликативной группы по модулю N и хэш-функцией H(). Значение k равно 3. Все вычисления проводятся по модулю N.

PAKE_Setup-36085-849647.png

Клиент генерирует пароль passwd и «солевое» значение salt (случайное значение небольшой по сравнению с passwd длины). Сервер сохраняет значение соли и «зашифрованный» результат хэширования пароля с солью.

PAKE_Step1-36085-b6e911.png

Клиент и сервер генерируют общий пароль K.

PAKE_Step2-36085-d916a3.png

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

PAKE_verification-36085-aa817d.png

Есть два значительных недостатка протокола SRP: – отсутствие доказательства стойкости протокола, следовательно нет внятно сформулированной проблемы для криптоанализа; – невозможность реализации протокола на эллиптических кривых.

Альтернативой протоколу SRP является более эффективный протокол OPAQUE. Несмотря на свои преимущества, протокол идёт в пакете с доказательством и адаптивен к эллиптическим кривым, OPAQUE не столь широко распространен, как SRP. Однако среди практиков безопасности сети есть мнение, что OPAQUE ничем не лучше существующих решений для веб серверов.

На этом пока всё. Не забывайте оставлять свои комментарии!

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться
🎁 Максимальная скидка!
Черная пятница уже в OTUS! Скидка -25% на всё!