Успешный вход в аккаунт не доказывает, что устройство способно расшифровать старую переписку. А наличие локальных ключей не означает, что сервер разрешил выполнить административную операцию. В ZionVox я разделяю эти утверждения с самого начала.
В предыдущей статье были связи User и Device. Теперь разберу границы доверия: пароль, серверная сессия, локальный storage key и криптографическая идентичность решают разные задачи.
В backend/src/routes/auth.routes.ts серверная аутентификация использует bcrypt, access/refresh cookie, CSRF и ограничения запросов. Этот контур отвечает на вопрос, кому принадлежит обращение к API и допустима ли операция в рамках текущей сессии.
bcrypt на backend защищает проверочное значение серверного пароля. Argon2id на клиенте требует памяти и времени для вывода локального ключа. В коде клиентские параметры по умолчанию — 64 MiB памяти, три прохода, parallelism 1 и результат 32 байта.
Access и refresh существуют отдельно. В auth.routes.ts предусмотрены ротация refresh и обработка reuse. Это важно для сценария, где старое подтверждение пытаются использовать повторно после смены состояния сессии.
В текущем register обязателен Welcome Token. Сервер проверяет подпись и использование jti. Значит, возможность придумать логин и пароль ещё не означает право создать аккаунт в этом контуре.
При блокировке пути Core остаётся живым. Альтернативный маршрут может восстановить доступ к API, но не должен заменять проверку сессии. Мост — новый способ довезти запрос, а не основание доверять ему больше.
В frontend/src/db/appDb.ts рядом существуют encrypted_keys, ratchet state и явно названные own_message_plain/e2ee_decrypted_plain. Из наличия защищённого ключевого хранилища нельзя вывести, что любая запись IndexedDB недоступна в открытом виде.
На клиенте frontend/src/crypto/argon2idKdf.ts выводит локальный ключ через Argon2id. Его задача — защита хранения на устройстве, а не повторение серверной проверки пароля. Входными данными этого контура служат mnemonic/passphrase; смешивать их с механизмом bcrypt неверно.
В полной статье — последовательность операций, разбор отказов и практический чек-лист. Я проектирую такие архитектуры и для клиентских продуктов.
https://arhellist.ru/blog/vhod-v-akkaunt-i-dostup-k-klyucham-raznye-zadachi/
