PIN-код криптокошелька: где ломается подтверждение транзакций
Подтверждение транзакции в приложении почти всегда завязано на PIN-код: пользователь вводит четыре-шесть знаков, приложение сверяет их со значением, сохранённым на устройстве, и отправляет операцию на подпись. Слабое место подтверждения — в том, что проверка подлинности пользователя происходит до формирования операции и никак не связана с её содержимым. PIN подтверждает «это я», но не «я подтверждаю именно этот адрес и эту сумму».
Отсюда самый дорогой класс отказов — подмена данных между экраном и подписью. На экране подтверждения адрес получателя и сумма одни, а в подписываемую нагрузку уходит другой адрес: пользователь видит корректные реквизиты, вводит верный PIN и сам санкционирует увод средств из кошелька. Второй вариант той же природы — переиспользование ответа: если результат ввода не привязан к конкретной операции и сроку, одного удачного подтверждения достаточно, чтобы провести серию списаний без участия владельца.
Не менее болезненна вторая грань — доступность. Биометрия отваливается после обновления системы, PIN забыт, а сценария восстановления без переустановки кошелька и работы с фразой восстановления нет. Человек не может отправить операцию, но и не понимает, почему; поддержка получает поток обращений, где нужно одновременно доказать право на аккаунт и не дать повода обойти проверку.
Общая причина у всех этих случаев одна: защита криптокошелька строится вокруг локального секрета, а не вокруг операции. Дальше разбираем, как это закрывается — привязкой PIN к конкретной транзакции, проверкой на стороне сервиса, лимитами на попытки ввода и предсказуемым сценарием восстановления доступа.
Что даёт локальное подтверждение операций в приложении
Локальное подтверждение операций строится так: PIN-код не уходит на сервер, а разблокирует закрытый ключ в защищённом хранилище платформы, проверка идёт в памяти приложения. Поэтому время отклика подтверждения — доли секунды и не зависит от качества канала, а на сервис уходит только уже подписанная операция. Один класс отказов защиты уходит целиком: перехватить или запросить PIN-код на стороне сервиса больше нельзя.
Для поддержки и разбора инцидентов это тоже ощутимо. Доля спорных операций падает — сценарий «подтверждал не я» закрывается проверяемой подписью, а журнал показывает, на каком устройстве разблокировали ключ. Удобство подтверждения при этом растёт: одно действие вместо ожидания ответа сервиса.
Устойчивость к подбору
Счётчик неудачных попыток хранится в том же защищённом хранилище и не сбрасывается переустановкой приложения. Пауза между попытками растёт, а после исчерпания лимита ключ стирается вместе с локальной копией, и доступ возвращается только по фразе восстановления. Подбор PIN-кода становится дороже того, что он защищает.
Сценарии восстановления
Забытый PIN-код не означает потерю доступа: он восстанавливается по резервной копии ключа либо фразе восстановления, а сам код меняется без выпуска нового адреса. Быстрый вход по биометрии устройства (на Android и в системе iOS) снимает трение в ежедневных операциях, но не заменяет PIN-код — биометрия лишь разблокирует хранилище, тогда как сам код остаётся последним рубежом.
Режимы подтверждения транзакций: что сравнить перед выбором
Режим подтверждения связывает намерение пользователя с подписью операции. Перевод по PIN-коду в приложении и перевод по аппаратному ключу для клиента выглядит одинаково, но класс риска у них разный: в первом случае секрет живёт в памяти устройства, во втором — не покидает защищённый модуль. Поэтому сравнивать варианты стоит не по удобству, а по тому, что именно проверяется перед отправкой.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| PIN-код в приложении | Частые мелкие операции | Секрет живёт на устройстве, слабая защита от подбора |
| Биометрическое подтверждение | Ежедневные платежи, повторные входы | Привязано к конкретному устройству, отпечаток не отозвать |
| Подтверждение на стороне сервера | Крупные суммы, смена реквизитов | Нужен постоянный канал, недоступность сети блокирует операцию |
| Аппаратное хранение ключей | Кошельки с ответственным хранением | Отдельный процесс выдачи и восстановления носителя |
Как выбрать режим под профиль риска
Чем выше лимит и необратимее операция, тем больше звеньев в цепочке подтверждения. PIN-код закрывает повседневные траты, биометрия убирает трение на повторных действиях, а вывод средств и смена адреса получателя требуют подтверждения на стороне сервера. Аппаратное хранение ключей включают там, где компрометация одного устройства не должна открывать доступ к средствам.
Совместимость режимов с текущей сборкой
Рабочая схема — не один способ, а пороги: до лимита достаточно локального подтверждения, выше — серверного, с задержкой на отмену. Носители с аппаратным хранением вроде YubiKey занимают верхний уровень и для повседневных операций не подходят. Весь набор проверяется на совместимость со сборками приложения и серверной частью до релиза.
Как мы внедряем подтверждение операций: этапы инженерной работы
Сценарий подтверждения операции в криптокошельке — это не экран ввода PIN-кода, а связка «кто запрашивает подтверждение, чем оно проверяется и что происходит при отказе». Поэтому начинаем не с клавиатуры, а с аудита: на выходе нужна последовательность, которую можно прогнать на реальных устройствах и передать в поддержку без нас.
Аудит и схема подтверждения
- Аудит защиты подтверждения — разбираем, где PIN-код хранится и с чем сравнивается, кто может инициировать запрос, что попадает в журнал, а что остаётся незаметным. Фиксируем слабые места: перехват ввода, обход биометрии, повтор уже подтверждённой операции.
- Схема подтверждения операции — описываем отдельные пути для перевода, подписи и смены настроек, разделяем подтверждение PIN-кодом и биометрией, задаём лимиты, выше которых принимается только PIN-код.
- Настройка попыток и блокировок — задаём число попыток, время ожидания ввода и поведение после серии неудач: нарастающая задержка, временная блокировка, понятный путь разблокировки.
Проверка и приёмка
- Проверка сценариев восстановления — забытый PIN-код, новое устройство, потеря доступа к почте и номеру. Каждый путь обязан приводить к предсказуемому состоянию, а не к «средства заблокированы навсегда».
- Приёмочные испытания — прогоняем сценарии на реальных моделях устройств, проверяем прерывание операции, отмену, повтор и поведение при потере сети.
- Передача документации — схемы подтверждения, регламенты эксплуатации, описания алгоритмов блокировки и восстановления, чтобы поддержка закрывала такие обращения сама.
Схемы, экраны, правила доступа и документация по подтверждению
После релиза заказчику остаётся не только рабочее подтверждение операций по PIN-коду, но и комплект артефактов, по которому задачу развивают без авторов кода. Документация лежит рядом с репозиторием и обновляется тем же изменением, что и логика: иначе через полгода никто не объяснит, почему лимит попыток выбран именно такой.
- Схемы взаимодействия. Последовательности вызовов между приложением, серверной частью и сервисом подписи: где формируется запрос, где сверяется код, где увеличивается счётчик неудачных попыток. Отдельная схема — восстановление после обрыва связи.
- Макеты экранов подтверждения. Все состояния: ввод кода, ожидание ответа, ошибка, исчерпанные попытки, разблокировка, смена PIN. С текстами, временем отклика и поведением при сворачивании приложения.
- Правила доступа. Кто в панели администратора видит журнал операций, кто снимает блокировку, кто меняет порог попыток. Матрица «роль → действие → след в аудите».
- Регламент реагирования. Действия при серии неудачных попыток, подозрении на компрометацию и утечке ключей: кто принимает решение, за какое время, как проходит ротация.
- Руководство для поддержки. Дерево решений по типовым обращениям, расшифровка кодов ошибок, границы ответственности и точки эскалации на инженеров.
- Журнал решений. Почему выбраны такие лимиты, задержки и способ хранения ключевого материала — чтобы будущие правки не ломали заложенную логику.
Передаём комплект с разбором для вашей команды: изменения в подтверждении операций дальше вносит любой инженер, знакомый с проектом.
Кейс: как сократили долю спорных операций в четыре раза
Кошелёк с десятками тысяч активных пользователей подтверждал каждую транзакцию одноразовым кодом в сообщении: код приходил с задержкой, терялся при смене оператора, а при переносе номера операция могла зависнуть в статусе «в обработке» на часы. Доля спорных операций доходила до 1,8% от объёма подтверждений, среднее время подтверждения — 45 секунд, а поддержка принимала по 3,2 обращения на каждую тысячу операций.
Что изменили
Подтверждение перенесли внутрь приложения: PIN-код криптокошелька привязали к конкретному устройству и ключу в защищённом хранилище, а на моделях с биометрией уровня Face ID добавили разблокировку вместо ручного ввода. PIN проверяется на стороне клиента, на сервер уходит только подписанный результат — перехват кода и подмена номера перестали давать доступ к операции. Пороги сумм и счётчик попыток настроили отдельно: выше лимита подключается дополнительная проверка, ниже — подтверждение занимает одну попытку.
Что стало
| Метрика | До | После |
|---|---|---|
| Доля спорных операций | 1,8% | 0,45% |
| Среднее время подтверждения | 45 с | 7 с |
| Обращений в поддержку на 1000 операций | 3,2 | 1,1 |
| Операций, где код не доходил | 6,4% | 0,2% |
Метрики снимали на одинаковом срезе трафика спустя три месяца после выката. Подтверждение перестало быть узким местом: доля спорных операций упала вчетверо, а нагрузка на поддержку сократилась почти втрое — освободившиеся инженеры ушли на задачи развития, а не на разбор зависших переводов.
Чем отличается PIN-код криптокошелька от биометрии?
PIN-код и биометрия закрывают одну задачу — подтвердить, что операцию инициировал владелец, — но опираются на разные свойства. PIN это знание: он не привязан к конкретному устройству и потому работает при восстановлении доступа и на новом телефоне. Биометрия это признак владельца: шаблон хранится в защищённом модуле устройства, не покидает его и не переносится. Отсюда главное ограничение — при компрометации шаблон нельзя отозвать, как код: меняется либо само устройство, либо способ подтверждения.
Устойчивость к подбору определяется не длиной кода, а тем, где считаются попытки. Короткий цифровой код без счётчика и растущей задержки перебирается локально; счётчик, блокировка после серии ошибок и проверка на стороне сервиса делают перебор бессмысленным. Биометрию в привычном смысле не перебирают — атакуют подменой шаблона или обходом проверки на скомпрометированном устройстве.
Второй фактор нужен там, где цена ошибки максимальна: подтверждение крупных сумм, отправка на новый адрес получателя, смена устройства, восстановление доступа. Рабочая схема — биометрия для быстрых повседневных операций, PIN как обязательный резерв и единственный управляемый откат, если биометрический канал скомпрометирован. Поэтому в проекте оба способа живут одновременно и проверяются независимо, а не заменяют друг друга.
Частые технические сомнения вокруг подтверждения операций
Подтверждение операции PIN-кодом — участок, где сходятся требования платёжного провайдера, поведение блокчейн-узла и ожидания пользователя. Ниже — разборы сомнений, которые чаще всего всплывают на приёмке и в первые недели после релиза.
Пользователь забыл PIN-код — его можно восстановить?
Нет: код не хранится в открытом виде ни в приложении, ни на сервере, поэтому «напомнить» его нельзя. Рабочий сценарий — сброс по резервной фразе восстановления и назначение нового кода. Ключи и баланс при этом сохраняются, меняется только способ подтверждения операций.
Где именно хранится PIN-код?
Из кода выводится ключ медленной функцией с солью, а на устройстве лежит только проверочное значение — в защищённом хранилище платформы, недоступном другим приложениям. На сервер уходит подписанная операция, а не сам код. Поэтому ни утечка базы, ни перехват трафика значение не раскрывают.
Сколько неверных попыток до блокировки?
Счётчик инкрементальный: после нескольких промахов включается пауза, её длительность растёт с каждой следующей попыткой, дальше — временная блокировка. Кошелёк и средства при этом не удаляются. Счётчик хранится вне приложения, поэтому переустановка или очистка данных его не обнуляют.
Как менять механику в уже выпущенном приложении?
Часть проверок живёт на стороне платформы, поэтому смена политики подтверждения и лимитов выкатывается без пересборки. Новая версия нужна, только если меняется схема хранения или формат подписи. Обновление делаем обратно совместимым: старые версии продолжают подтверждать операции, пока их доля не опустится до нуля.
Подтверждение работает без сети?
Да. Код проверяется локально, подпись операции формируется на устройстве — без интернета подтверждение проходит, а отправка ждёт появления связи. Исключение — операции, где нужна онлайн-проверка лимитов и счётчика попыток на стороне сервиса.
Обсудим задачу и вернёмся с оценкой и планом работ
Пришлите текущий сценарий подтверждения транзакции: где хранится секрет, что происходит при неверном PIN, как ведёт себя приложение при смене биометрии, переустановке и офлайн-подписи. Если приложения ещё нет, хватит требований по безопасности, перечня платформ и макетов ключевых экранов. Этого достаточно, чтобы вернуться с оценкой и планом, а не с общими словами.
- описание сценария: ввод PIN, лимит попыток, блокировка, восстановление доступа;
- что уже готово — код, дизайн, аналитика отказов, обращения пользователей;
- требования по безопасности и хранению секрета на устройстве;
- целевые платформы и минимальные версии операционных систем;
- критичные сценарии: офлайн-подпись, смена устройства, утеря доступа;
- доступы для команды — репозиторий, тестовые сборки, канал связи.
Старт строим так: архитектор мобильного направления разбирает поток подтверждения и границы доверия, к нему подключаются инженеры по платформам, тестировщик по сценариям безопасности и серверный инженер, если нужна синхронизация. Этапы идут короткими отрезками: разбор и модель угроз, прототип подтверждения на тестовом контуре, реализация, проверка на живых устройствах.
Результат каждого отрезка — работающая сборка и отчёт: какие сценарии закрыты, что осталось, какие риски открыты. Точки проверки согласуем заранее: демонстрация на устройстве, прогон отказов и блокировок, разбор кода и защищённого хранилища. Опишите задачу — вернёмся с оценкой, составом команды и порядком этапов.
