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 — корисний інструмент обмеження розкриття пароля під час автентифікації. Його цінність зрозуміліша, коли реальні переваги описані разом із викраденням верифікатора, компрометацією кінцевого пристрою та ризиками відновлення, а не подані як кінець проблем безпеки паролів.
