Форматы передачи пароля

Передача пароля в системах, использующих библиотеку Iron в JavaScript, опирается не на сам факт отправки секретного значения, а на преобразование данных в защищённые структуры, устойчивые к перехвату и подмене. В основе лежит принцип: пароль никогда не передаётся в открытом виде, а используется только для получения криптографических ключей или для защиты полезной нагрузки.

Открытый текст (plaintext)

Передача пароля в исходном виде встречается исключительно в начальной точке ввода (например, форма логина). Дальнейшие операции должны исключать его повторную отправку по сети.

Основной риск:

  • перехват через сетевые атаки
  • логирование на промежуточных узлах
  • утечки через браузерные инструменты разработчика или прокси

В контексте Iron такой формат рассматривается только как входной, но не транспортный.

Хешированное представление

Пароль преобразуется в необратимую форму с использованием криптографических функций.

Типичная схема:

  • PBKDF2
  • bcrypt
  • scrypt

Хеширование само по себе не является механизмом Iron, но используется для получения ключей, которые затем участвуют в процессе шифрования или подписи.

Ключевой момент:

  • хеш не предназначен для восстановления пароля
  • одинаковый пароль при одинаковой соли даёт одинаковый результат

Использование пароля как основы для ключа шифрования

В Iron пароль не используется напрямую. Он участвует в процессе вывода ключей (key derivation).

Типичный процесс:

  1. Пользовательский пароль
  2. Соль (salt)
  3. Алгоритм KDF (например PBKDF2)
  4. Производный ключ
  5. Использование ключа в Iron для seal/unseal

Формат sealed-данных (основной формат Iron)

Iron реализует механизм «sealing» — упаковки данных в защищённый контейнер.

Структура sealed-строки

Результат обычно выглядит как строка с несколькими сегментами, закодированными в Base64:

  • зашифрованные данные
  • IV (инициализационный вектор)
  • HMAC-подпись
  • служебные метаданные

Формат концептуально можно представить так:

{payload}.{iv}.{mac}.{id}

Каждый сегмент:

  • payload — зашифрованная полезная нагрузка
  • iv — случайный вектор для симметричного шифрования
  • mac — код аутентичности сообщения
  • id — идентификатор ключа

Передача пароля через Iron seal

Сценарий упаковки

Пароль может быть включён в структуру данных, которая затем «запечатывается»:

  • создаётся объект с полем password
  • объект сериализуется в JSON
  • применяется Iron seal

Пример логики:

  • вход: { username, password }
  • преобразование: JSON
  • защита: seal
  • результат: строка sealed-формата

Важно: в корректной архитектуре пароль не должен покидать клиент, но если это происходит, он должен быть сразу преобразован в sealed-формат.

Формат передачи ключа Iron

Iron использует ключи, состоящие из нескольких компонентов:

  • encryption key (AES)
  • integrity key (HMAC)
  • optional password-derived key

Ключи обычно кодируются в Base64 и хранятся в виде строки или объекта конфигурации.

Пример структуры:

{
  key: "base64-key",
  algorithm: "aes-256-cbc",
  hmacAlgorithm: "sha256"
}

Сериализация данных перед шифрованием

Перед использованием Iron данные всегда проходят сериализацию:

JSON-формат

Наиболее распространённый вариант:

{
  "user": "admin",
  "password": "secret"
}

После сериализации:

  • строка JSON
  • передача в Iron seal
  • шифрование

Buffer-формат

Используется при бинарных данных:

  • более эффективен
  • меньше накладных расходов
  • применяется в низкоуровневых системах

Кодирование результата передачи

После применения Iron результат кодируется:

Base64

Стандартный вариант:

  • безопасен для передачи через HTTP
  • не содержит управляющих символов
  • легко декодируется

URL-safe Base64

Используется при передаче через query string:

  • заменяет + и /
  • исключает = или заменяет padding

Подпись и целостность данных

Iron включает механизм HMAC, который обеспечивает:

  • защиту от подмены данных
  • проверку целостности
  • привязку к ключу

Формат:

  • данные шифруются
  • затем создаётся подпись
  • при расшифровке подпись проверяется

Любое изменение sealed-строки делает её недействительной.

Обратное преобразование (unseal)

Процесс восстановления данных включает:

  1. декодирование Base64
  2. извлечение IV
  3. проверка HMAC
  4. расшифровка payload
  5. десериализация JSON

Если пароль использовался для derivation ключа, неверный пароль приводит к невозможности расшифровки.

Типы транспортных форматов пароля в Iron-экосистеме

1. Inline sealed string

Полностью упакованная строка:

  • используется в cookies
  • передаётся через HTTP headers
  • хранится на клиенте

2. JSON envelope

Пароль внутри защищённого объекта:

{
  "data": "<sealed>",
  "meta": {...}
}

3. Binary envelope

Используется в системах с высокой нагрузкой:

  • компактное представление
  • минимизация overhead

Использование Iron в HTTP-транспорте

Один из наиболее распространённых сценариев:

  • пароль или сессия упаковываются в sealed cookie
  • сервер расшифровывает при каждом запросе

Структура cookie:

Set-Cookie: session=<sealed-string>; HttpOnly; Secure

Header-based формат

Используется для API:

Authorization: Iron <sealed-token>

Body-based формат

При POST-запросах:

{
  "auth": "<sealed-password-object>"
}

Особенности безопасности форматов

Ключевые свойства Iron-передачи:

  • невозможность чтения без ключа
  • проверка целостности встроена в формат
  • привязка к алгоритму шифрования
  • устойчивость к replay-атакам при правильной настройке

Ошибки при работе с форматами передачи

Повторное использование IV

Критическая ошибка, приводящая к снижению стойкости шифрования.

Отсутствие HMAC

Открывает возможность подмены данных.

Передача raw password внутри sealed без защиты канала

Даже sealed-формат требует HTTPS.

Неправильное кодирование Base64

Приводит к невозможности восстановления данных.

Взаимодействие Iron с другими форматами безопасности

JWT

В отличие от JWT:

  • Iron делает упор на симметричное шифрование
  • JWT чаще использует подпись без шифрования

OAuth токены

Iron может использоваться как контейнер для OAuth access token, но не заменяет сам протокол.

Хранение пароля в транспортных структурах

Пароль в Iron-архитектуре:

  • либо не хранится вообще
  • либо хранится только в sealed форме
  • либо используется однократно для derivation

Любое долговременное хранение предполагает использование хешей, а не исходного значения.

Форматирование данных внутри sealed контейнера

Перед шифрованием структура обычно нормализуется:

  • сортировка ключей JSON
  • удаление лишних пробелов
  • фиксированная кодировка UTF-8

Это необходимо для:

  • детерминированного результата
  • корректной проверки HMAC
  • воспроизводимости seal/unseal процессов