Защищённая паролем передача файлов: обезопасьте общие файлы

Защищённая паролем передача файлов означает, что получатель не сможет расшифровать содержимое без секрета, выбранного отправителем. Пароль — это не просто шлюз для входа: он является входными данными для PBKDF2-HMAC-SHA256 (или Argon2id), который выводит ключ AES-256-GCM, используемый для шифрования байтов. Без него шифртекст на сервере — просто шум. Это принципиально отличается от инструментов передачи с «защитой паролем», которые хранят файлы в открытом виде и лишь проверяют пароль на HTTP-уровне. Реальная парольная защита связывает пароль непосредственно с криптографией.

Разница между шлюзом и деривацией

Большинство потребительских платформ обмена файлами до 2020 года использовали шлюзирование паролем. Вы загружали .pdf, сервер сохранял его в S3, а Rails-контроллер проверял введённый пароль по bcrypt-хешу перед отдачей файла. Администратор с доступом к базе данных или по судебному запросу видел всё. Шифрование на основе пароля переворачивает это: браузер запускает PBKDF2 с 600 000 итерациями (базовый уровень OWASP 2023), растягивает пароль в 256-битный ключ и шифрует данные перед загрузкой. Сервер держит шифртекст и случайную соль. Нет пароля — нет ключа, нет файла. Firefox Send использовал именно эту модель до того, как Mozilla закрыла его в 2020 году.

Выбор между PBKDF2 и Argon2id

PBKDF2 — рабочая лошадка: входит в Web Crypto API, работает везде и при большом количестве итераций устойчив к перебору. Argon2id новее и лучше: устойчив к памяти, поэтому GPU-атакующие не могут дёшево перебирать радужные таблицы. Камень преткновения — поддержка браузером. Нативного Argon2 в Web Crypto пока нет, поэтому сервисы реализуют его через libsodium.js, что добавляет около 180 КБ к бандлу. Для передачи 10 ГБ, где узкое место — скорость загрузки, компромисс в пользу Argon2id с m=64 МБ, t=3, p=1 оправдан. Для вложения 20 МБ PBKDF2 с 600 000 итерациями завершается за 400 мс на среднем телефоне.

Что делает пароль достаточно надёжным

12-символьный пароль из прописных, строчных букв, цифр и символов даёт примерно 78 бит энтропии — вполне достаточно против современных автономных атак на Argon2id. Кодовая фраза из четырёх слов в стиле Diceware (наподобие correcthorsebatterystaple) даёт 51 бит и её проще продиктовать по телефону. Избегайте коротких паролей даже при растяжении KDF; злоумышленник с похищенным шифртекстом и солью может запускать PBKDF2 на RTX 5090 со скоростью 20 миллионов попыток в секунду. Шестизначные пароли падают за минуты. Объясняйте каждому пользователю, который пытается ввести «Summer2026!», что длина важнее сложности.

Передача пароля без нивелирования защиты

Отправить ссылку на файл и пароль в одном письме — значит уничтожить всю защиту. Злоумышленник, получивший доступ к почтовому ящику, получает и то, и другое. Разделяйте каналы: ссылку — по электронной почте, пароль — по SMS или через Signal. Ещё лучше использовать сервис одноразовых секретов, например Psst! от 1Password, или личное сообщение в Slack, которое нельзя переслать без скриншота. Для постоянных получателей договоритесь о схеме деривации пароля вне основного канала (например, «название месяца плюс идентификатор проекта»), чтобы ничего чувствительного не передавалось по сети.

Соль, нонс и почему они не являются паролем

Вместе с шифртекстом передаются три компонента: соль для KDF (16 байт), нонс для GCM (12 байт) и тег аутентификации (16 байт). Ни один из них не должен оставаться секретным — они лишь должны быть уникальными для каждой передачи. Повторное использование нонса с одним и тем же ключом в GCM катастрофично: это раскрывает XOR открытых текстов. Криптографически случайная генерация через crypto.getRandomValues() решает эту проблему, а соль хранится в заголовке метаданных файла. Пароль — единственный секрет; всё остальное передаётся вместе с шифртекстом.

Защита от подмены на стороне клиента

Вредоносное браузерное расширение может прочитать пароль в момент ввода. Защита: заголовки Content Security Policy, запрещающие встроенные скрипты и внешние соединения (connect-src 'self'), Subresource Integrity на всех объединённых JavaScript-файлах и строгий Referrer-Policy, чтобы рефереры не утекали в аналитику. Проверяйте WASM-бандл с помощью хешей подресурсов в манифесте. Это не защищает от скомпрометированной ОС, но поднимает планку выше случайных перехватчиков. HexaTransfer публикует SHA-384-хеши, чтобы опытные пользователи могли убедиться, что загруженный бандл соответствует репозиторию с исходным кодом.

Возобновление прерванных загрузок без утечки ключа

Для 5-гигабайтного .iso-файла загрузка может занять часы. Если вкладка закрылась, возобновление должно работать без повторного ввода пароля. Храните производный ключ в SessionStorage (никогда в LocalStorage — он сохраняется между перезапусками) и очищайте его после завершения загрузки или закрытия вкладки. В модели пофрагментной загрузки каждый блок по 5 МБ получает собственный подключ HKDF, производный от мастер-ключа; таким образом, при возобновлении приостановленной сессии раскрывается только подключ текущего фрагмента, а не корневой. Smash и SwissTransfer поддерживают запросы диапазонов, но по-разному работают с ключевым материалом.

Когда парольная защита недостаточна

Пароль не мешает авторизованному получателю переслать файл. Как только Анна расшифровала .docx, она может отправить его куда угодно. Для реального ограничения сочетайте пароли с DRM-подобными ограничениями: одноразовые ссылки для скачивания, доступ, привязанный к IP, или короткие окна истечения (15 минут для пакета доказательств PCI DSS 4.0). Для соответствия GDPR Article 32 ведите журнал, кто и когда получал доступ. Парольная защита — это пол, а не потолок: она повышает стоимость случайного перехвата, не решая проблему внутренних угроз.

Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.