Одна з частих вразливостей мобільних криптогаманців — зберігання PIN-коду в UserDefaults або у вигляді звичайного рядка. Ми бачили проєкти, де PIN порівнювався через == з числом, отриманим із SharedPreferences. Це прямий шлях до крадіжки коштів.
Без обмеження спроб зловмисник може перебрати всі 10000 комбінацій за пару годин на сучасному смартфоні. Результат — втрата контролю над гаманцем. Ми вирішуємо це завдання за 1–3 дні на будь-якому стеку.
За 5 років ми впровадили PIN-захист у 15+ криптогаманцях, щоразу адаптуючи під вимоги App Store Review і Google Play. У цій статті розберемо, як правильно хешувати PIN, організувати блокування та зробити кастомний numpad, який не дасть витоку через автозаповнення. Якщо ви хочете уникнути аудиту безпеки з high-критичними знахідками, впровадження під ключ — ваш варіант. Ми пропонуємо готове рішення з вихідним кодом та документацією. Зв'яжіться з нами — і за 2 дні отримаєте захищений PIN-ввід. Гарантуємо сумісність з iOS 15+ і Android 8+.
Проблеми, які вирішуємо
- Зберігання PIN без хешу. Часто розробники використовують MD5 або навіть plaintext. Це перша ж знахідка при пентесті.
- Відсутність блокування. Без затримок і повного блокування зловмисник перебирає PIN за хвилини.
- Системна клавіатура. Вона не дає візуального контролю введення і може пропонувати автозаповнення з iCloud Keychain — ризик витоку PIN.
Як ми реалізуємо хешування PIN
PIN ніколи не зберігається як є. Мінімальний прийнятний варіант — PBKDF2-HMAC-SHA256 з унікальною сіллю (32 байти з CSPRNG) і кількістю ітерацій від 100 000. Краще — bcrypt або Argon2id, але останній потребує сторонню бібліотеку на iOS.
На iOS: PBKDF2 через CCKeyDerivationPBKDF з CommonCrypto:
func deriveKey(from pin: String, salt: Data, iterations: UInt32 = 200_000) -> Data { var derivedKey = Data(count: 32) let pinData = pin.data(using: .utf8)! derivedKey.withUnsafeMutableBytes { derivedPtr in pinData.withUnsafeBytes { pinPtr in salt.withUnsafeBytes { saltPtr in CCKeyDerivationPBKDF( CCPBKDFAlgorithm(kCCPBKDF2), pinPtr.baseAddress, pinData.count, saltPtr.baseAddress, salt.count, CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256), iterations, derivedPtr.baseAddress, 32 ) } } } return derivedKey } Сіль + хеш зберігаються в iOS Keychain з kSecAttrAccessibleWhenUnlockedThisDeviceOnly. PIN з пам'яті обнуляється відразу після деривації.
Порівняння: PBKDF2 з 200 000 ітерацій в 10 000 разів повільніший за звичайний SHA256, що робить атаку перебором неефективною.
"Елементи Keychain зберігаються після видалення додатку при використанні типу доступності
kSecAttrAccessibleWhenUnlockedThisDeviceOnly." — Apple Keychain Documentation.
Поетапне керівництво реалізації
- Генерація солі (32 байти, CSPRNG).
- Хешування PIN через PBKDF2 (200 000 ітерацій).
- Збереження хешу та солі в Keychain / EncryptedSharedPreferences.
- Налаштування лічильника спроб (зберігати там же).
- Розробка кастомного numpad з візуальним зворотним зв'язком.
- Опціонально: інтеграція з біометрією (Face ID / Touch ID).
- Тестування граничних випадків: перевстановлення, скидання даних, багатопотокове введення.
Чому потрібно обмежувати спроби введення
Без обмеження зловмисник може перебирати PIN нескінченно. Після 3 невдалих спроб — затримка 30 секунд. Після 5 — хвилина. Після 10 — повне блокування гаманця з вимогою відновлення через seed-фразу. Лічильник спроб зберігається в Keychain (не UserDefaults — його можна скинути видаленням даних додатку без root).
Атаку через видалення та перевстановлення додатку частково нейтралізуємо: на iOS Keychain з kSecAttrAccessibleWhenUnlockedThisDeviceOnly переживає перевстановлення. На Android — блокування зберігаємо через EncryptedSharedPreferences в окремому contentProvider або бекенд.
Кастомний numpad чи системна клавіатура: що безпечніше
Системна цифрова клавіатура зручна, але не дає візуального контролю — не видно, скільки цифр введено. Кастомний numpad (6 кружечків + 10 цифр + backspace) — стандарт для криптогаманців. Він виключає автозаповнення (textContentType = .none), запобігаючи витоку PIN через менеджери паролів.
| Платформа | Сховище | Поведінка при перевстановленні |
|---|---|---|
| iOS | Keychain з kSecAttrAccessibleWhenUnlockedThisDeviceOnly |
Дані зберігаються |
| Android | KeyStore / EncryptedSharedPreferences | KeyStore знищується, потрібен бекенд |
Порівняння методів хешування
| Метод | Ітерацій | Безпека | Швидкість (відн.) |
|---|---|---|---|
| PBKDF2-HMAC-SHA256 | 100k–200k | Добра | 1x |
| bcrypt | cost=10 | Краще | 0.5x |
| Argon2id | m=19MB, t=2, p=1 | Найкраща | 0.2x |
Процес роботи
- Аналіз вимог та аудит поточної реалізації безпеки.
- Проектування схеми: хешування, блокування, numpad.
- Реалізація на Swift / Kotlin / Flutter.
- Тестування на вразливості (перебір, скидання лічильника, перевстановлення).
- Деплой та документація.
Терміни та вартість
Терміни: 1–3 дні. Вартість розробки — від $270–390. Економія від запобігання витоку даних — до $9k–13k. (вартість інциденту при крадіжці коштів).
Замовте розробку під ключ — отримайте готовий код, захищений від перебору та витоків. Зв'яжіться з нами для консультації.