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 — «невразливим до зламів завдяки нульовому знанню». Межі кожного методу та політика відновлення продукту — основа надійного порівняння.
