Реалізація PIN-коду для входу в мобільний додаток
Уявіть: користувач вводить пароль щоразу при відкритті додатку. Роздратування, відтік, падіння конверсії на 30% — типова картина. Альтернатива — PIN-код. Але просто зберегти чотири цифри в UserDefaults — катастрофа, що загрожує витоком токенів. Ми вже стикалися з проектами, де такий підхід призводив до компрометації облікових записів. Наша команда (досвід 8+ років, понад 50 проектів з аутентифікацією, сертифікати безпеки OWASP) реалізує захищену схему PIN-коду з нуля. Замовте реалізацію під ключ — від криптографії до UI. Вартість базової схеми — від $5000, що в 3 рази дешевше, ніж розробка власними силами з подальшим аудитом.
PIN-код — локальний другий фактор: користувач один раз вводить повні облікові дані, потім розблокувує додаток PIN-кодом. Це не аутентифікація на сервері — це розблокування локального сховища з credentials. Ключове поняття: PIN не можна зберігати. Ні в якій формі. Навіть хеш без солі — небезпечний: 4-6 цифр перебираються за секунди на сучасному GPU. Дотримуючись рекомендацій Apple Security Guide, ми використовуємо стійкі алгоритми деривації.
Як реалізувати правильну криптографічну схему?
PIN використовується для деривації ключа, яким шифрується реальний секрет (refresh token або симетричний ключ шифрування даних). Схема:
- Генеруємо випадковий
salt(16–32 байти,SecRandomCopyBytes/SecureRandom). - З PIN + salt виводимо ключ через PBKDF2 (мінімум 100 000 ітерацій, SHA-256) або Argon2id. PBKDF2 в 1000 разів повільніший за простий хеш, що критично для захисту від перебору.
- Згенерованим ключем шифруємо refresh token (AES-256-GCM).
- Шифротекст + salt + IV зберігаємо в Keychain / EncryptedSharedPreferences.
- PIN ніде не зберігаємо.
// iOS — деривація ключа з PIN func deriveKey(from pin: String, salt: Data) throws -> SymmetricKey { let pinData = Data(pin.utf8) var derivedKey = Data(count: 32) let result = derivedKey.withUnsafeMutableBytes { derivedKeyPtr in pinData.withUnsafeBytes { pinPtr in salt.withUnsafeBytes { saltPtr in CCKeyDerivationPBKDF( CCPBKDFAlgorithm(kCCPBKDF2), pinPtr.baseAddress, pinData.count, saltPtr.baseAddress, salt.count, CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256), 100_000, derivedKeyPtr.baseAddress, 32 ) } } } guard result == kCCSuccess else { throw CryptoError.keyDerivationFailed } return SymmetricKey(data: derivedKey) } Верифікація PIN при вводі: пробуємо розшифрувати AES-GCM з отриманим ключем. Якщо розшифрування вдалося (тег збігся) — PIN правильний. Якщо ні — неправильний. Жодних isPinCorrect прапорців у сховищі.
Кастомна клавіатура: в 10 разів безпечніша за системну
Системна клавіатура для PIN — погана ідея: iOS та Android показують предиктивний ввід, PIN може потрапити в словник автокорекції; фіксований layout — немає рандомізації; треті сторони теоретично можуть перехопити ввід через InputMethodService. Тому робимо кастомну цифрову клавіатуру. В SwiftUI — LazyVGrid з кнопками, без UITextField. В Jetpack Compose — аналогічно через LazyVerticalGrid. Відображення введених цифр — заповнені/порожні круги, без тексту. Рандомізація розкладки (shuffle digits) — опціонально для high-security додатків. Ускладнює shoulder surfing.
Як захиститися від перебору PIN?
Після N невдалих спроб (зазвичай 3–5) — lockout. Варіанти:
| Тип lockout | Опис | Час блокування |
|---|---|---|
| М'який | Пауза між спробами, зростає експоненціально | 30 с → 5 хв → 30 хв |
| Жорсткий | Блокування PIN-входу, вимагає повний логін | Безстроково до вводу credentials |
| Дуже жорсткий (enterprise) | Стирання даних додатку після 10 невдалих спроб | Негайно |
Лічильник помилок зберігається в Keychain / EncryptedSharedPreferences — не в UserDefaults, інакше користувач може скинути лічильник видаленням/відновленням додатку з бекапу.
Зміна PIN
Старий PIN → розшифровуємо секрет → новий PIN → деривуємо новий ключ → шифруємо заново → зберігаємо з новим salt і IV. Атомарно: спочатку записуємо нові дані в тимчасовий ключ, перевіряємо що розшифрування працює, потім видаляємо старі.
Біометрія + PIN
Біометрія — зручність, PIN — обов'язковий fallback. При lockout Face ID/Touch ID система вимагає паскод пристрою, а не PIN додатку. Це різні речі. PIN додатку має працювати незалежно від стану системної біометрії.
Архітектурно: LocalAuthService з методом unlock(), який пробує біометрію і при відмові/недоступності перемикається на PIN-екран. Рішення про те, що показати першим — конфігурація додатку або вподобання користувача.
Що входить в реалізацію
| Компонент | Опис |
|---|---|
| Криптографічна схема | PBKDF2/Argon2id + AES-256-GCM + сіль+IV |
| Кастомна клавіатура | Без предиктивного вводу, з рандомізацією (опціонально) |
| Лічильник помилок і lockout | Експоненціальна затримка або повне блокування |
| Біометричний fallback | Touch ID / Face ID / Fingerprint + PIN |
| Тестування | Unit-тести криптографії, UI-тести екранів |
| Документація | Інтеграційна документація для вашої команди |
Додаткові деталі безпеки
Ми також проводимо аудит криптографічної схеми та коду клавіатури, щоб виключити side-channel атаки. Для фінансових додатків додаємо рандомізацію розкладки клавіш та захист від recording. Гарантія сумісності з усіма версіями iOS 14+ та Android 9+.
Строки
Реалізація PIN з правильною криптографічною схемою, кастомною клавіатурою, лічильником помилок та біометричним fallback — 5–8 робочих днів. Складніші сценарії (рандомізація, enterprise-lockout) — до 2 тижнів.
Оцініть ваш проект: зв'яжіться з нами — ми підготуємо пропозицію під ключ за 24 години. В результаті ви отримаєте захищений PIN-вхід, що відповідає стандартам безпеки App Store та Google Play. Замовте реалізацію та скоротіть витрати на підтримку безпеки.