SRP не передаёт пароль внутри протокола; это не означает отказ от пароля, невосприимчивость к фишингу или безвредность verifier.
Passkey и SRP — два разных способа аутентификации. Passkey использует пару ключей и может устранить необходимость в пароле. SRP по-прежнему основан на пароле, но при правильной реализации протокола не отправляет сам пароль серверу, чтобы доказать его знание.
Поэтому «вход без отправки пароля» и «вход без наличия пароля» — не одно и то же. Выбор между этими методами должен опираться на риск фишинга, управление учётными данными, восстановление и качество реализации, а не на общий ярлык «нулевое знание».
Что меняет passkey?
При аутентификации с помощью passkey сервис хранит открытый ключ, а пользователь подтверждает вход, контролируя закрытый ключ. Привязка учётных данных к соответствующему сервису и источнику — важная часть устойчивости метода к фишингу. Объяснение passkey от FIDO.
Не все passkey обязательно синхронизируются через облако. Одни привязаны к устройству или ключу безопасности, другие переносятся между устройствами через поставщика учётных данных. Модель восстановления и защиту синхронизации нужно изучать у конкретного поставщика. Сам по себе «облачный обмен» не позволяет заключить, что компания хранит ключи в читаемом виде.
Безопасность сеанса после входа — отдельный вопрос. Passkey не обезвреживает автоматически вредоносное ПО на устройстве и не предотвращает автоматически кражу действующего сеанса.
Что SRP передаёт серверу?
SRP относится к семейству обмена ключами с аутентификацией по паролю. Вместо самого пароля сервер хранит данные вроде соли и проверочного значения, или verifier. Обмениваясь сообщениями протокола, стороны проверяют знание секрета и общий ключ.
Но verifier — не безвредные данные. Раздел 3.3 RFC 5054 прямо указывает, что злоумышленник, получивший проверочное значение, может провести словарную атаку для подбора пароля. Поэтому утверждение «кража базы данных не даёт никакой возможности автономного подбора» неверно.
Надёжный пароль, защита сервера, подходящие параметры, проверка входных данных и контроль попыток входа по-прежнему необходимы. SRP также не гарантирует безопасность страницы, на которой вы вводите пароль: вредоносный код может перехватить его до выполнения протокола.
Корректное сравнение
| Вопрос | Passkey | SRP |
|---|---|---|
| Запоминает ли пользователь пароль сервиса? | Обычно нет; необходим контроль учётных данных | Да, метод основан на знании пароля |
| Что сервис хранит для входа? | Открытый ключ и связанные сведения | Проверочное значение и связанные параметры |
| Как достигается устойчивость к фишингу? | Привязкой учётных данных к сервису/источнику в архитектуре FIDO | Отсутствия передачи пароля в протоколе недостаточно, чтобы сделать поддельное поле ввода безопасным |
| Обязательно ли облако? | Нет; существуют и варианты с привязкой к устройству | Протокол по своей природе не требует стороннего поставщика идентификации, но требует сервиса аутентификации |
| Как выполняется восстановление? | Зависит от типа учётных данных и поставщика | Это определяет политика аккаунта и продукта, а не название SRP |
Из этой таблицы нельзя вывести абсолютный рейтинг всех реализаций. Слабый процесс восстановления может подорвать преимущество надёжного способа входа.
Как вход в аккаунт связан с ключами чата?
Аутентификация сообщает сервису, кому разрешено действовать. Ключи шифрования сообщений определяют, кто может открыть содержимое. Продукт может связывать эти два механизма, но связь должна быть документирована.
В документации по безопасности Livara SRP описан как механизм входа, а пакет восстановления v7 для зашифрованной идентичности рассматривается отдельно. Этот пакет восстанавливает идентичность, а не историю чатов. Поэтому «пароль для входа верен» не означает «все ключи и старые сообщения восстановлены».
Эта статья — концептуальное сравнение, а не практический тест всех способов входа в Livara и не подтверждение точной реализации какого-либо RFC в продукте.
О чём спросить при выборе?
- Если устройство потеряно, каков альтернативный способ входа и кто его контролирует?
- Не слабее ли способ восстановления, чем основной вход?
- Как просматривать и отзывать неизвестные сеансы?
- Меняет ли смена способа входа ключи сообщений или связанные устройства?
- Какой аккаунт и какая независимая защита необходимы для синхронизации учётных данных?
Вывод: Не называйте passkey по определению «небезопасным из-за облака», а SRP — «неуязвимым к взлому благодаря нулевому знанию». Границы каждого метода и политика восстановления продукта — основа достоверного сравнения.
