Короткий пароль на ссылке кажется разумным компромиссом: секрет уже зашифрован, адрес известен только получателю, а четыре цифры удобно продиктовать. Проблема начинается, когда кто-то получает адрес и пробует варианты автоматически. Без ограничений сервис становится устройством для проверки чужих догадок. Насколько быстро подберут пароль, зависит от его сложности, алгоритма и оборудования; обещать конкретные секунды без измерений нельзя.
Burn-on-Failure меняет стоимость ошибок: неудачная попытка расходует доступный просмотр. Но у механизма есть границы, особенно когда шифрование выполняется в браузере. Разберём не рекламную формулу «перебор невозможен», а то, какие действия действительно ограничивает текущая версия Secure Link.
Два вектора атаки: онлайн и офлайн
Онлайн-перебор требует обращаться к сервису. Если сервер проверяет каждый пароль, он может ограничивать именно проверки. В Secure Link пароль проверяется иначе: расшифрование происходит локально, поэтому сервер не знает, была ли введена верная строка. Он считает выдачи зашифрованных данных и сообщения клиента о неудачах.
Офлайн-перебор начинается после получения шифртекста и необходимых параметров расшифрования. Дальше атакующий проверяет кандидаты на своём устройстве, не спрашивая API. Серверный счётчик, TTL и удаление записи уже не управляют этой копией. Для внешнего слоя Decoy Mode дополнительно нужен ключ ссылки из #-фрагмента.
Уже одной копии может хватить для локального подбора: проверка AES-GCM позволяет определить успешное расшифрование без повторного обращения к серверу.
Именно поэтому «цифровая пломба» — ограниченная метафора. Она помогает заметить расход просмотров, но не доказывает отсутствие сохранённой копии. Пустая ссылка также может означать истечение таймера или случайное открытие, а не обязательно успешную атаку. Для важного доступа сомнение — повод отозвать сам ключ или пароль.
Как Burn-on-Failure работает в Secure Link
При загрузке зашифрованной записки сервер атомарно уменьшает счётчик в Redis. Последний доступный просмотр удаляет активную запись, а запрашивающий клиент получает данные для локального расшифрования. При лимите 1 просмотр серверная копия поэтому исчезает ещё до того, как получатель проверит пароль.
Если расшифрование с введённым паролем не удалось, штатный клиент отправляет отдельный запрос расходования просмотра. При достижении нуля запись удаляется. Если просмотры остались, следующая ошибка может потратить ещё один. Это ограничивает повторные попытки обычного интерфейса, а не является серверной проверкой каждого кандидата.
Важная оговорка: модифицированный клиент может не отправлять уведомление об ошибке и продолжать работать со скачанным шифртекстом. Поэтому утверждение «после трёх ошибок никакой перебор больше невозможен» неверно. Механизм сокращает дальнейшую выдачу с сервера; защиту сохранённой копии обеспечивают криптография и сложность пароля.
PBKDF2-HMAC-SHA-256 увеличивает вычислительную стоимость каждой догадки. Для обычного режима с паролем сейчас используется 200 000 итераций; у Decoy Mode — 100 000. Случайная соль мешает повторно использовать заранее подготовленные вычисления между записками. Но соль не секрет, а PBKDF2 не превращает 123456 в стойкий пароль. Длинное случайное значение остаётся обязательной частью защиты.
Отдельный слой — серверный Rate Limiting на базе HMAC-SHA-256. Приложение вычисляет псевдоним из адреса клиента, секрета сервера и области API. В Redis для ограничителя сохраняется этот идентификатор, а не исходный IP; он не привязывается к содержимому записки. Сетевой адрес всё равно обрабатывается инфраструктурой, поэтому говорить о полном отсутствии обработки IP нельзя.
HMAC здесь не усложняет пароль и не шифрует записку. Он позволяет считать запросы без сохранения открытого IP в ограничителе. Лимиты относятся к обращениям к API и действуют отдельно от бюджета просмотров; офлайн-вычисления они не замедляют. Вместе эти механизмы уменьшают поверхность атаки, но не заменяют друг друга.
Сравнение способов передачи
| Свойство | ZIP с паролем в чате | Обычная ссылка с паролем | Secure Link: Burn-on-Failure |
|---|---|---|---|
| Что остаётся у получателя | Скачиваемый архив | Зависит от реализации сервиса | Полученный шифртекст можно скопировать |
| Ограничение ошибок | Обычно отсутствует после скачивания | Зависит от серверной проверки | Штатный клиент расходует просмотры при ошибке |
| Удаление источника | Не стирает копию архива | Зависит от TTL и настроек | Redis-запись удаляется по лимиту, TTL или вручную |
| Офлайн-подбор | Возможен для сохранённого архива | Возможен при наличии нужных данных | Также возможен; нужен сильный пароль |
Таблица не означает, что любой ZIP одинаков или все остальные сервисы устроены плохо. Формат шифрования и способ выдачи важнее названия. Полезный вопрос перед передачей: что получатель уже успел скачать и какие ограничения ещё способен обеспечить сервер?
Если получатель опечатался
На телефоне легко перепутать символы. Лимит 3 просмотра оставляет больше пространства для исправления, но это не три гарантированные попытки пароля: первоначальная загрузка уже расходует одну, а ошибки штатного клиента — дополнительные. При включённом Decoy Mode сервер устанавливает минимум три просмотра независимо от меньшего выбора в форме.
- Используйте длинный автоматически сгенерированный пароль из менеджера паролей, а не короткий PIN ради удобства.
- Передавайте дополнительный пароль отдельным каналом; не кладите его рядом со ссылкой в одном сообщении.
- Выбирайте короткий TTL под время встречи или передачи. Он ограничивает серверное хранение, но не срок жизни скачанной копии.
- Если ссылка неожиданно исчерпана, уточните ситуацию у получателя. Для чувствительного доступа отзовите или ротируйте сам секрет, затем создайте новую записку.
Просто пересоздать ссылку с прежним токеном недостаточно, если токен мог утечь. Новый адрес не меняет права старого API-ключа в системе, для которой он выпущен.
Практический итог
Создайте одноразовую ссылку, выберите подходящий бюджет просмотров и сильный дополнительный пароль. Burn-on-Failure полезен как ограничение штатных попыток и серверной выдачи. Честная защита начинается с этой границы: удалённая запись — не то же самое, что уничтоженная чужая копия.