SRP позволяет не отправлять пароль при входе; это не делает украденный верификатор безвредным.
Secure Remote Password, или SRP, позволяет клиенту и серверу аутентифицироваться с помощью пароля, не отправляя его в обычном обмене протокола. Это может уменьшить раскрытие пароля серверу, который иначе получал бы его при входе.
SRP не удаляет с сервера все связанные с паролем секреты. Сервер хранит верификатор, а украденный верификатор может позволить подбирать пароль в автономном режиме. Это различие необходимо учитывать при оценке заявлений о «входе с нулевым разглашением».
Что меняется по сравнению с обычным входом по паролю?
В обычной схеме клиент отправляет пароль по аутентифицированному соединению TLS. Хорошо спроектированный сервер сравнивает подходящий хеш пароля с солью, не записывает учётные данные в журналы и применяет защиту от подбора. TLS защищает соединение; хеш пароля иным способом защищает сохранённые учётные данные.
SRP меняет обмен. При регистрации система создаёт соль и материал верификатора. При входе обе стороны используют свежие значения протокола и свои секреты для установления и подтверждения общего ключевого материала. Клиент использует пароль, сервер — свой верификатор. Честный клиент не передаёт сам пароль в качестве содержимого запроса входа.
Спецификация SRP в RFC 2945 объясняет основы протокола. Для последующих профилей и реализаций необходимо проверять точные параметры и проверки сообщений; название «SRP» не доказывает правильность каждого решения реализации.
| Вопрос | Обычный вход с передачей пароля по TLS | Правильно реализованный обмен SRP |
|---|---|---|
| Получает ли сервер приложения введённый пароль при входе? | Обычно да | Не в рамках обмена протокола |
| Какой чувствительный материал аутентификации хранится? | Обычно хеш пароля с солью | Соль и верификатор, полученный из пароля |
| Может ли украденная база позволить автономный подбор? | Да, в зависимости от сохранённого материала | Да, украденный материал верификатора SRP может позволить подбор |
| Защищает ли это от кейлоггера? | Нет | Нет |
| Шифрует ли это автоматически историю сообщений? | Нет | Нет |
Почему украденный верификатор всё равно важен
Раздел 3.3 RFC 5054 прямо рассматривает украденные верификаторы. В нём объясняется, что верификатор может позволить злоумышленнику выдать себя за сервер и проводить словарные атаки для восстановления пароля.
Важное различие: верификатор — не просто многократно используемый токен входа клиента. Это не делает его безвредным. Злоумышленник может проверять кандидаты пароля по украденному материалу, а не решать задачу дискретного логарифма для каждого возможного секрета. Слабый или повторно используемый пароль остаётся серьёзным риском.
Ограничения частоты онлайн-запросов могут замедлить попытки против работающего сервиса, но не управляют вычислениями над украденной базой. Защита базы, тщательная обработка паролей и стойкие уникальные пароли по-прежнему важны.
От чего SRP не защищает
Скомпрометированное конечное устройство: Вредоносное ПО может перехватить пароль до начала протокола или украсть аутентифицированную сессию после него.
Злонамеренная страница входа: Если сама страница, запрашивающая пароль, враждебна, она может отправить введённый текст в другое место. Веб-приложению всё равно нужен надёжный путь доставки.
Все пути восстановления: Процедура через электронную почту, SMS или поддержку, предоставляющая доступ к аккаунту, имеет собственные требования. Самый сильный обычный метод входа может быть подорван более слабым запасным путём.
Любая активная сетевая атака: Важны параметры протокола, проверка входных данных, взаимное подтверждение и окружающее аутентифицированное соединение. Не заменяйте предусмотренную для развёртывания защиту TLS лозунгом «пароль никогда не передаётся».
Метаданные или шифрование чата: Аутентификация отвечает на вопрос, следует ли допустить сессию. Она не определяет, какие записи разговоров существуют и у кого находятся ключи расшифрования сообщений.
Как Livara отделяет вход от восстановления идентичности
Обзор безопасности Livara описывает аутентификацию SRP отдельно от протокола сообщений LVR1. Он также документирует зашифрованную резервную копию идентичности версии 7, защищённую отдельным случайным 256-битным ключом восстановления.
Копия криптографически запечатывается до загрузки и восстанавливает криптографическую идентичность, а не историю чата. Одного знания пароля аккаунта недостаточно для восстановления этих ключей шифрования. И наоборот, заявление о том, что поддержка не может воссоздать секрет шифрования, не доказывает невозможность любых действий управления аккаунтом или процедуры смены пароля.
Модель угроз также учитывает компрометацию устройства и видимые метаданные связи. Не следует использовать SRP как повод объявлять весь сервис «ничего не знающим» о каждой стороне активности пользователя.
Практический список для оценки
Пользователю стоит выбрать уникальный стойкий пароль, защитить устройство, хранить материал восстановления в подходящем отдельном месте и понимать, как отзываются сессии. Не вводите секрет на недоверенном сайте только потому, что он заявляет об использовании SRP.
Техническому эксперту следует запросить точный профиль протокола, обработку преобразования пароля в верификатор, проверку входных данных, обработку сбоев, процесс регистрации и схему сброса. Проверяйте клиент и сервер совместно. Включайте тесты недопустимых публичных значений, повторного воспроизведения и прерванных сессий, а не полагайтесь лишь на тест успешного входа.
SRP — полезный инструмент ограничения раскрытия пароля во время аутентификации. Его ценность яснее, когда реальные преимущества описываются вместе с кражей верификатора, компрометацией конечного устройства и рисками восстановления, а не преподносятся как конец проблем безопасности паролей.
