W Polsce większość codziennych płatności mobilnych kojarzy się z BLIK-em — systemem, w którym aplikacja bankowa wyświetla sześciocyfrowy, tymczasowy kod ważny tylko kilka minut. Mechanizm BLIK jest własnościowy i nie jest zgodny ze standardem TOTP, ale opiera się na tej samej intuicji: krótko żyjący kod jest bezpieczniejszy niż stałe hasło, bo okno na jego przechwycenie i wykorzystanie jest bardzo wąskie.
Wspólny sekret plus czas
Podczas konfiguracji serwer i aplikacja uwierzytelniająca wymieniają jeden wspólny klucz tajny (to właśnie jest zakodowane w kodzie QR). Następnie obie strony niezależnie obliczają HMAC z tego sekretu i aktualnego czasu unix, zaokrąglonego do 30-sekundowego interwału — otrzymując ten sam kod bez wzajemnej komunikacji.
Dlaczego to działa bez internetu
Ponieważ kod jest obliczany lokalnie z sekretu i zegara systemowego urządzenia, aplikacja uwierzytelniająca nie potrzebuje połączenia sieciowego do wygenerowania kodu. Jedynym wymogiem jest to, by zegary serwera i telefonu pozostawały zsynchronizowane w niewielkim dopuszczalnym zakresie (zwykle ±30–60 sekund).
Dlaczego kod zmienia się co 30 sekund
Krótki interwał czasowy ogranicza okno, w którym przechwycony kod pozostaje ważny, zmniejszając ryzyko jego ponownego użycia przez atakującego. Serwer zwykle akceptuje aktualny interwał plus jeden poprzedni, aby zrekompensować niewielkie opóźnienie sieciowe podczas wpisywania kodu.
Do czego to się przydaje
- Zrozumienie mechaniki uwierzytelniania dwuskładnikowego przy konfiguracji lub diagnozowaniu problemów z aplikacjami uwierzytelniającymi.
- Testowanie własnej implementacji TOTP podczas tworzenia systemu uwierzytelniania.
- Generowanie kodów do testów automatycznych bez ręcznego wpisywania ich z telefonu.
Przed czym TOTP nie chroni
TOTP skutecznie chroni przed kradzieżą hasła osobno od kodu, ale nie przed phishingiem w czasie rzeczywistym: jeśli ofiara wpisze zarówno hasło, jak i aktualny kod TOTP na fałszywej stronie, atakujący może natychmiast użyć obu wartości na prawdziwej stronie, dopóki kod jest jeszcze ważny. Przed takim atakiem chronią jedynie klucze sprzętowe zgodne ze standardem FIDO2/WebAuthn, kryptograficznie powiązane z konkretną domeną.