Хеші/крипто

TOTP Generator/Verifier

Одноразові коди за часом (TOTP, RFC 6238) — генерація поточного коду з секрету та перевірка введеного коду з урахуванням дрейфу часу.

------


                    

TOTP (Time-based One-Time Password, RFC 6238) — алгоритм двофакторної автентифікації, який генерує одноразовий код на основі секрету й поточного часу. Саме він працює під капотом у Google Authenticator, Authy та подібних застосунках.

Як користуватися

Типові сценарії

Що варто памʼятати

TOTP-код дійсний лише короткий проміжок часу (зазвичай 30 секунд) — це і є основний захист, а не сам секрет.

Точність коду напряму залежить від синхронізації годинника пристрою; помітний розсинхрон часу — найчастіша причина відхилених кодів 2FA.

Стаття про цей інструмент: TOTP: як працюють одноразові коди в застосунках-автентифікаторах

Часті запитання

Чому згенерований код так швидко закінчується?

Коди TOTP прив'язані до часу — за замовчуванням вони оновлюються кожні 30 секунд, обчислюючись з поточного Unix-часу та спільного секрету. Це коротке вікно обмежує, як довго витік коду залишається корисним.

Що станеться, якщо годинник мого пристрою розсинхронізований?

TOTP покладається на те, що обидві сторони приблизно узгоджені щодо поточного часу. Більшість застосунків-автентифікаторів і серверів допускають невелике відхилення (зазвичай один часовий крок), але більший зсув призведе до відхилення дійсних кодів.

Чи надсилається мій секретний ключ кудись під час генерації коду тут?

Ні. Код TOTP обчислюється повністю у вашому браузері — секретний ключ ніколи не залишає ваш пристрій.

Чи захищає TOTP від фішингу?

Не повністю. Якщо жертва вводить пароль і поточний TOTP-код на підробленому сайті, зловмисник може миттєво використати обидва значення на справжньому сайті, поки код ще дійсний. Від такої атаки в реальному часі захищають лише апаратні ключі за стандартом FIDO2/WebAuthn.

Чому сервер приймає й попередній часовий інтервал, а не лише поточний?

Це компенсує невелику мережеву затримку між генерацією коду на телефоні й моментом, коли сервер його отримує та перевіряє. Без такого допуску легітимні коди інколи відхилялися б через звичайну затримку в кілька секунд.

Статті: Хеші/крипто

Hash Generator: чим MD5, SHA-1 і SHA-256 відрізняються одна від одної

Чому MD5 досі використовують для перевірки цілісності файлів, але не для паролів.

Checksum Verifier: як перевірити, що файл не пошкоджено

Чому збіг контрольної суми підтверджує цілісність файлу, але не те, хто його створив.

HMAC: чим хеш з ключем відрізняється від звичайного хешу

Чому звичайний SHA-256 не захищає від підробки повідомлення, а HMAC — захищає.

Bcrypt: чому паролі хешують повільно, а не швидко

Чому швидкий SHA-256 — погана ідея для паролів, а повільний bcrypt — правильна.

UUID: як генерують ідентифікатори, що майже ніколи не повторюються

Чому UUID v4 можна генерувати незалежно на мільйонах машин без ризику колізій.

Генератор паролів: що насправді робить пароль стійким

Чому довгий пароль зі словника надійніший за короткий з символами й цифрами.

AES: як працює симетричне шифрування

Чому той самий ключ шифрує і розшифровує дані в AES, і чим це відрізняється від асиметричного шифрування.

Argon2: чому цей алгоритм переміг конкурс на хешування паролів

Чим Argon2 краще захищає від атак на відеокартах, ніж старіші алгоритми хешування паролів.

Scrypt: навіщо алгоритму потрібно багато пам'яті

Чому scrypt навмисно вимагає багато пам'яті, щоб ускладнити перебір на ASIC-пристроях.

PBKDF2: найстаріший стандарт розтягування ключів

Чому рекомендована кількість ітерацій PBKDF2 зростає з кожним роком.

X.509: що всередині SSL-сертифіката

Що саме браузер перевіряє в сертифікаті сайту, перш ніж показати зелений замочок.

PGP: як працює шифрування з відкритим і приватним ключем

Чому можна вільно ділитися публічним ключем PGP, але не приватним.