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, ліміт спроб, блокування, відновлення доступу;
- що вже готово — код, дизайн, аналітика відмов, звернення користувачів;
- вимоги до безпеки та зберігання секрету на пристрої;
- цільові платформи та мінімальні версії операційних систем;
- критичні сценарії: офлайн-підпис, зміна пристрою, втрата доступу;
- доступи для команди — репозиторій, тестові збірки, канал зв'язку.
Старт будуємо так: архітектор мобільного напряму розбирає потік підтвердження та межі довіри, до нього підключаються інженери за платформами, тестувальник за сценаріями безпеки і серверний інженер, якщо потрібна синхронізація.
Етапи йдуть короткими відрізками: розбір і модель загроз, прототип підтвердження на тестовому контурі, реалізація, перевірка на живих пристроях.
Результат кожного відрізка — робоча збірка і звіт: які сценарії закриті, що залишилося, які ризики відкриті. Точки перевірки узгодимо заздалегідь: демонстрація на пристрої, прогін відмов і блокувань, розбір коду та захищеного сховища. Опишіть задачу — повернемося з оцінкою, складом команди та порядком етапів.
