Пароль можно сделать длинным, шифрование — стойким, а ключ передать отдельным каналом. Но что делать, когда человека заставляют открыть записку лично? AES-256-GCM не умеет отличать добровольное действие от принуждения. Если владелец вводит правильный пароль, расшифрование срабатывает как обычно. У криптографов для этого класса угроз есть неприятно буквальное название: rubber-hose cryptanalysis, или криптоанализ с применением принуждения.
Режим приманки предлагает другой ответ: подготовить безобидное содержимое, которое открывается отдельным паролем и выглядит как обычная записка. Это дополнительный инструмент для ограниченного сценария, а не обещание безопасности под давлением. При реальной угрозе человеку важнее собственная безопасность, чем сохранность токена. Никакая настройка ссылки не гарантирует, что проверяющий поверит увиденному.
Что такое правдоподобное отрицание
В идеализированной схеме один контейнер допускает два правдоподобных открытия: одно показывает обычные данные, другое — скрытый секрет. Наблюдателю недостаточно получить первый пароль; ему нужно ещё доказать существование второго содержимого. Отсюда название Plausible Deniability — правдоподобное отрицание.
Известный пример — скрытые тома VeraCrypt. Их свойства зависят от конкретного формата, настроек и соблюдения мер предосторожности. Переносить эти гарантии на любой сервис с двумя паролями нельзя. Следы могут оставаться в операционной системе, резервных копиях и истории действий, даже если сам зашифрованный контейнер выглядит убедительно.
У Secure Link более узкая задача: дать одинаковый пользовательский сценарий для настоящего секрета и приманки. Обычный экран чтения не помечает результат как обманку. Но интерфейсная правдоподобность — не доказанная криптографическая неотличимость. Ниже важно не смешивать эти два свойства.
Как устроен Режим приманки в Secure Link
При создании ссылки с паролем включите «Режим приманки» (Decoy Mode). Понадобятся основной пароль, пароль-приманка и два текста: настоящий секрет и безопасное альтернативное содержимое. Пароли должны различаться. После создания получателю нужны ключ ссылки и один из паролей; один пароль без ключа из #-фрагмента внешний контейнер не откроет.
В браузере PBKDF2-HMAC-SHA-256 получает отдельный ключ из каждого пароля. В текущей реализации Decoy Mode используется общая случайная соль и 100 000 итераций. Тексты шифруются независимо с AES-256-GCM и разными векторами инициализации. Затем оба результата упаковываются со случайным заполнением и дополнительно шифруются случайным ключом ссылки. Это два слоя защиты, а не хранение открытой приманки рядом с секретом.
Ключ внешнего слоя находится после # и не передаётся в HTTP-запросе к серверу. В режиме Split-link его можно отправить отдельно. Сервер хранит зашифрованный контейнер, а расшифрование выполняет браузер. При успешной проверке основного пароля интерфейс показывает секрет; при успешной проверке второго — альтернативный текст без отдельного предупреждения.
Есть существенная оговорка про удаление. Сейчас сервер устанавливает для Decoy Mode минимум 3 просмотра. Загрузка зашифрованной записки расходует один просмотр ещё до расшифрования; правильный ввод любого пароля сам по себе не уничтожает оставшуюся запись. Она удаляется из активного Redis-хранилища при исчерпании просмотров, истечении TTL либо ручном сжигании. Поэтому обещание «открыли приманку — настоящий секрет немедленно исчез» для этой версии неверно.
И ещё одна граница: серверная запись содержит технический признак включённого Decoy Mode. Заполнение уменьшает очевидность длины текста, но не делает все контейнеры одинаковыми, а ветви расшифрования не заявлены как неразличимые по времени. Анализ реализации, доступ к данным сервера или наблюдение за созданием ссылки могут показать больше, чем обычный экран получателя.
Три правила правдоподобной приманки
- 1Сохраните контекст, уберите ценность. Если обсуждался тестовый API, альтернативный текст должен выглядеть как тестовый токен с понятной ролью, а не список покупок. Используйте заведомо неработающее значение: настоящий доступ, даже «почти ненужный», не становится безопасным от названия «приманка».
- 2Не оставляйте прямого противоречия в переписке. Сообщение «внутри два пароля и скрытый production-ключ» разрушает правдоподобность заранее. При этом отсутствие такого сообщения ничего не доказывает: собеседник мог видеть создание записки или знать, что сервис поддерживает приманки.
- 3Проверьте сценарий на вымышленных данных. Заранее разберитесь, какой пароль открывает какой текст, где находится ключ и как расходуются просмотры. Для реальной передачи создайте новую записку. Проверять рабочую ссылку «на всякий случай» — значит тратить её лимит и создавать лишние копии.
Не усложняйте приманку декоративными подробностями. Длинная история, выдуманные адреса и лишние инструкции дают больше поводов для вопросов. Лучше короткий правдоподобный текст, который действительно не предоставляет доступа ни к одному ресурсу. И всё же убедительность остаётся оценкой человека, а не параметром алгоритма.
От чего защищает — и от чего не защищает
| Сценарий | Что даёт приманка | Где проходит предел |
|---|---|---|
| Требуют пароль от ещё не открытой ссылки | Можно показать альтернативный текст обычным способом | Проверяющий может не поверить; безопасность человека не гарантируется |
| Смотрят только на экран открытия | Нет отдельной метки «это приманка» | Это не защита от анализа сервера, кода или времени обработки |
| На устройстве отправителя кейлоггер | Надёжной защиты нет | Вредоносная программа может увидеть оба текста, пароли и ключ |
| Контейнер или открытый текст уже скопирован | Удаление серверной записи ограничивает дальнейшую выдачу | Чужие копии и запись экрана оно не стирает |
Дополнительный пароль полезен только вместе с надёжным устройством и разумным обращением с ключом. Если браузер скомпрометирован, он видит данные до шифрования или после расшифрования. Если сохранён контейнер и ключ внешнего слоя, слабые пароли могут проверяться офлайн. Приманка не отменяет ни один из этих рисков.
Для особо важных доступов сначала рассмотрите отдельную учётную запись с минимальными правами и возможностью отзыва. Ссылка решает задачу передачи, а не последующего контроля над секретом. После подозрительного открытия отзывайте сам доступ, а не только создавайте ещё одну записку.
Когда этот режим уместен
Decoy Mode имеет смысл, когда вы понимаете узкий сценарий проверки и готовы принять его ограничения. Если нужна строго одна выдача с сервера, не считайте режим приманки эквивалентом обычной записки с одним просмотром: сейчас у них разные правила.
Начните с генератора, выберите короткий TTL и используйте длинные разные пароли. Перед передачей пароля проверьте настройки на отдельном тестовом примере. Режим приманки расширяет варианты поведения интерфейса, но не превращает принуждение в задачу, которую можно гарантированно решить криптографией.