Wpisz prawidłowy sekret, aby zobaczyć kod.
Sprawdź kod tak, jak zrobiłby to serwer: akceptowany jest bieżący kod oraz do 2 kroków wcześniej lub później, aby tolerować rozbieżności zegarów.
Jak to działa
TOTP (Time-based One-Time Password, RFC 6238) to algorytm stojący za sześciocyfrowymi kodami Google Authenticator, Microsoft Authenticator, Authy czy 1Password. Usługa i Twój telefon współdzielą sekret; co 30 sekund oba obliczają HMAC sekretu z bieżącym czasem podzielonym na kroki, skracają wynik do sześciu cyfr i porównują go. Ponieważ nikt nie przesyła kodu, dopóki go nie wpiszesz, działa to nawet wtedy, gdy telefon nie ma połączenia.
HOTP (RFC 4226) to algorytm bazowy: zamiast czasu używa licznika, który zwiększa się przy każdym żądaniu kodu. TOTP to HOTP, w którym licznik zastąpiono liczbą okresów, które upłynęły od 1970 roku. Sekret zapisuje się w Base32 i jest przekazywany w URI otpauth://, wyświetlanym jako kod QR podczas włączania weryfikacji dwuetapowej.
Narzędzie generuje sekrety za pomocą kryptograficznego generatora przeglądarki, oblicza bieżący, poprzedni i następny kod, tworzy URI i jego kod QR, odczytuje istniejący URI i weryfikuje kod z taką samą tolerancją zegara, jakiej używają serwery. Sekret nigdy nie opuszcza Twojej przeglądarki i nie jest dołączany do linku do udostępniania.
Przykłady
GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ · SHA1 · 8 · T = 59 s94287082Wektor testowy z RFC 6238. Sekret to tekst ASCII 12345678901234567890 zakodowany w Base32; w 59. sekundzie od początku epoki Uniksa krok wynosi 1, a ośmiocyfrowy kod musi być dokładnie taki.GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ · SHA1 · 8 · T = 1111111109 s07081804Kolejny wektor z RFC 6238, przydatny do sprawdzenia, czy Twoja implementacja nie gubi zer wiodących: kod to ciąg cyfr o stałej długości, a nie liczba całkowita.HOTP · GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ · contador 0755224Pierwszy wektor z RFC 4226 z sześcioma cyframi. Przy liczniku równym 1 kod zmienia się na 287082.otpauth://totp/Ejemplo:ana%40example.com?secret=JBSWY3DPEHPK3PXP&issuer=EjemploTOTP · SHA1 · 6 · 30 sFormat Key URI zdefiniowany przez Google Authenticator i przyjęty przez inne aplikacje. Jeśli brakuje algorithm, digits i period, przyjmuje się SHA1, 6 i 30, dlatego większość kodów QR zawiera tylko sekret i wystawcę.Przypadki użycia
- Testowanie włączania 2FA w Twojej aplikacji: wygenerowanie sekretu, zeskanowanie kodu QR telefonem i sprawdzenie, czy serwer akceptuje ten sam kod, który pokazuje aplikacja.
- Diagnozowanie, dlaczego serwer odrzuca prawidłowe kody: zgodność z poprzednim lub następnym krokiem wskazuje na rozbieżny zegar.
- Walidacja własnej implementacji TOTP lub HOTP za pomocą wektorów testowych z RFC 6238 i 4226.
- Odczytanie URI otpauth:// wyeksportowanego z innej aplikacji, aby sprawdzić, jakiego algorytmu, ilu cyfr i jakiego okresu używa konto.
- Dodanie do drugiej aplikacji lub menedżera haseł konta testowego, którego sekret masz już w Base32.
Najczęstsze pytania
Dlaczego serwer odrzuca kod, który aplikacja pokazuje jako prawidłowy?
Prawie zawsze chodzi o zegar. TOTP wymaga, aby telefon i serwer zgadzały się co do czasu: już przy 30 sekundach różnicy obliczają różne kroki. Dlatego serwery akceptują jeden lub dwa kroki w każdą stronę. Jeśli kod pasuje do poprzedniego lub następnego kroku, zsynchronizuj czas serwera przez NTP i włącz automatyczny czas w telefonie.
Czy bezpiecznie jest generować tutaj sekret dla prawdziwego konta?
Sekret jest generowany za pomocą crypto.getRandomValues i nie opuszcza Twojej przeglądarki, ale w środowisku produkcyjnym musi go generować i przechowywać serwer, który będzie weryfikował kody. To narzędzie służy do testowania i debugowania. Traktuj każdy prawdziwy sekret jak hasło: kto go ma, może generować Twoje kody na zawsze.
Czy warto używać SHA-256, 8 cyfr lub 60 sekund?
Teoretycznie są silniejsze, ale kilka aplikacji, w tym niektóre wersje Google Authenticator, ignoruje te parametry i zawsze oblicza SHA-1 z 6 cyframi co 30 sekund, przez co użytkownik widzi kody odrzucane przez serwer. SHA-1 jako HMAC nadal jest bezpieczny. Ze względu na zgodność prawie wszystkie usługi używają wartości domyślnych.
Jak długi powinien być sekret?
RFC 4226 wymaga co najmniej 128 bitów i zaleca 160, co w Base32 daje 32 znaki. Wiele usług używa 80 bitów (16 znaków), a aplikacje i tak je akceptują. To narzędzie generuje 160 bitów.
Czy TOTP chroni przed phishingiem?
Nie całkowicie. Jest znacznie lepszy niż SMS, który można przechwycić lub ukraść przez podmianę karty SIM, ale fałszywa strona może poprosić Cię o kod i użyć go na prawdziwej w ciągu tych samych 30 sekund. Klucze bezpieczeństwa FIDO2 i passkeys są powiązane z domeną i są odporne na ten atak.
Co się stanie, jeśli zgubię telefon?
Bez sekretu nie da się obliczyć kodów. Dlatego usługi przekazują kody odzyskiwania przy włączaniu 2FA: przechowuj je poza telefonem. Niektóre aplikacje pozwalają tworzyć zaszyfrowaną kopię zapasową kont w chmurze lub eksportować je jako kod QR, aby przenieść je na inne urządzenie.