Mister Old
Посвященный
One Time Secret: Рискованный API или Угроза безопасности?
В мире анонимного обмена данными существуют сервисы вроде Privnote, которые позволяют передавать одноразовые сообщения, исчезающие после первого прочтения. Однако недавно я обратил внимание на One Time Secret, аналогичный проект, который предлагает API для автоматизации отправки и получения секретов. И здесь возникает очевидный вопрос: зачем вообще делать API для привнот-сервиса, если это ломает саму идею безопасности?
Оптимальный алгоритм работы таких сервисов выглядит так:
Пример ссылки:
Если сервис действительно использует клиентское шифрование, то даже если сервер скомпрометирован, он не сможет получить доступ к данным без части после #. Это доказываемо безопасно – код браузерного JavaScript можно проанализировать, и если он правильно шифрует данные, сервер не сможет их расшифровать.
Главное преимущество одноразовых секретов в том, что они не хранятся на сервере дольше, чем необходимо, а значит, никто не может их перехватить или прочитать. Но когда сервис предоставляет API, это автоматически делает систему уязвимой, потому что:
У Privnote нет API, а значит, использование сервиса хотя бы в теории безопаснее. Но! Хотя код у них закрытый, это не так критично, если сервис действительно использует клиентское шифрование. Однако без открытого кода мы не можем проверить, не делает ли сервер что-то нежелательное, например, логирование или хранение сообщений дольше положенного срока. Единственное решение – open-source сервисы, которые можно развернуть самостоятельно, например PrivateBin.
Вот что можно предположить о мотивах создателей One Time Secret:
Вывод
В мире анонимного обмена данными существуют сервисы вроде Privnote, которые позволяют передавать одноразовые сообщения, исчезающие после первого прочтения. Однако недавно я обратил внимание на One Time Secret, аналогичный проект, который предлагает API для автоматизации отправки и получения секретов. И здесь возникает очевидный вопрос: зачем вообще делать API для привнот-сервиса, если это ломает саму идею безопасности?
Как должен работать безопасный сервис одноразовых сообщений?
Оптимальный алгоритм работы таких сервисов выглядит так:
- Шифрование на стороне клиента. Перед отправкой сообщение шифруется в браузере отправителя с использованием надежного алгоритма (например, AES-256).
- Передача зашифрованных данных. На сервер отправляется только зашифрованный текст, и сервер не имеет доступа к исходному содержимому.
- Одноразовое хранение. Сообщение хранится на сервере временно и удаляется сразу после первого прочтения.
- Удаление после истечения времени. Если сообщение не открыто в течение заданного времени, оно автоматически удаляется без возможности восстановления.
- Отсутствие логирования. Сервер не должен вести логи IP-адресов, метаданных и других идентификаторов пользователей.
Как устроены ссылки в Privnote и подобных сервисах?
Пример ссылки:
Код:
https://privnote.com/4IJWS9Kf#A3h37DyHl- Часть до # (
Будь ласка, Увійти або Реєстрація щоб переглянути вміст URL-адреси!) – идентификатор заметки, который сервер использует для поиска сообщения.
- Часть после # (A3h37DyHl) – важный момент! Этот фрагмент не передается на сервер и остается в браузере. Он может содержать ключ дешифрования, который используется для расшифровки сообщения в клиенте.
Если сервис действительно использует клиентское шифрование, то даже если сервер скомпрометирован, он не сможет получить доступ к данным без части после #. Это доказываемо безопасно – код браузерного JavaScript можно проанализировать, и если он правильно шифрует данные, сервер не сможет их расшифровать.
API и его главная проблема
Главное преимущество одноразовых секретов в том, что они не хранятся на сервере дольше, чем необходимо, а значит, никто не может их перехватить или прочитать. Но когда сервис предоставляет API, это автоматически делает систему уязвимой, потому что:
- Кто-то может перехватывать запросы. API позволяет сторонним скриптам автоматически отправлять и запрашивать секретные сообщения. В таком сценарии разработчики сервиса (или злоумышленники) могут логировать данные до их удаления.
- Непрозрачность хранения данных. Нет гарантии, что сервер действительно уничтожает данные сразу после прочтения.
- Отсутствие end-to-end шифрования. Если данные не шифруются до отправки (а API обычно предполагает, что сервер имеет к ним доступ), то их может видеть владелец сервиса.
Privnote против One Time Secret: кто надежнее?
У Privnote нет API, а значит, использование сервиса хотя бы в теории безопаснее. Но! Хотя код у них закрытый, это не так критично, если сервис действительно использует клиентское шифрование. Однако без открытого кода мы не можем проверить, не делает ли сервер что-то нежелательное, например, логирование или хранение сообщений дольше положенного срока. Единственное решение – open-source сервисы, которые можно развернуть самостоятельно, например PrivateBin.
Кто и зачем делает API для секретов?
Вот что можно предположить о мотивах создателей One Time Secret:
- Некомпетентность – они просто не подумали о том, что API убивает безопасность.
- Внутренний проект, случайно ставший публичным – возможно, API создавали для определенного круга пользователей, а потом решили сделать общедоступным.
- Сервис-ловушка – если API позволяет перехватывать секреты, это может быть инструмент для сбора конфиденциальной информации.
- Коммерческий интерес – сбор данных для анализа, продажи или шантажа.
Вывод
Если сервис предоставляет API для привнот-функционала, он небезопасен по определению. Использование One Time Secret – это либо риск попасть на сбор данных, либо доверие к людям, которые изначально не понимают принципов безопасности. В любом случае, это не выглядит надежным решением.
Лучший вариант? Либо использовать проверенные сервисы без API, либо разворачивать свой собственный PrivateBin.
Как думаете, это не похоже на "спящий скам"?
Останнє редагування:
