Voer een geldig geheim in om de code te zien.
Controleer een code zoals de server dat zou doen: de huidige code wordt geaccepteerd en tot 2 stappen ervoor of erna, om afwijkende klokken op te vangen.
Hoe het werkt
TOTP (Time-based One-Time Password, RFC 6238) is het algoritme achter de zescijferige codes van Google Authenticator, Microsoft Authenticator, Authy of 1Password. De dienst en je telefoon delen een geheim; elke 30 seconden berekenen beide een HMAC van het geheim met de huidige tijd, verdeeld in stappen, korten die in tot zes cijfers en vergelijken het resultaat. Omdat niemand de code verstuurt totdat je hem intypt, werkt het ook als je telefoon geen verbinding heeft.
HOTP (RFC 4226) is het basisalgoritme: in plaats van de tijd gebruikt het een teller die oploopt telkens wanneer een code wordt opgevraagd. TOTP is HOTP waarbij de teller is vervangen door het aantal verstreken perioden sinds 1970. Het geheim wordt in Base32 geschreven en zit in een otpauth://-URI die als QR-code wordt getoond wanneer je tweestapsverificatie inschakelt.
De tool genereert geheimen met de cryptografische generator van de browser, berekent de huidige, vorige en volgende code, stelt de URI en de QR-code samen, leest een bestaande URI uit en controleert een code met dezelfde kloktolerantie die servers gebruiken. Het geheim verlaat nooit je browser en wordt niet opgenomen in de deellink.
Voorbeelden
GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ · SHA1 · 8 · T = 59 s94287082Testvector uit RFC 6238. Het geheim is de ASCII-tekst 12345678901234567890, gecodeerd in Base32; 59 seconden na het begin van de Unix-epoch is de stap 1 en moet de achtcijferige code precies deze zijn.GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ · SHA1 · 8 · T = 1111111109 s07081804Nog een vector uit RFC 6238, handig om te controleren dat je implementatie geen voorloopnullen kwijtraakt: de code is een reeks cijfers van vaste lengte, geen geheel getal.HOTP · GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ · contador 0755224Eerste vector uit RFC 4226 met zes cijfers. Met de teller op 1 wordt de code 287082.otpauth://totp/Ejemplo:ana%40example.com?secret=JBSWY3DPEHPK3PXP&issuer=EjemploTOTP · SHA1 · 6 · 30 sHet Key URI-formaat dat Google Authenticator definieerde en dat de andere apps overnamen. Als algorithm, digits en period ontbreken, worden SHA1, 6 en 30 aangenomen, dus de meeste QR-codes bevatten alleen het geheim en de uitgever.Gebruiksscenario's
- De 2FA-activering van je applicatie testen: een geheim genereren, de QR-code met je telefoon scannen en controleren dat de server dezelfde code accepteert die de app toont.
- Uitzoeken waarom een server geldige codes weigert: als ze overeenkomen met de vorige of volgende stap, wijst dat op een afwijkende klok.
- Een eigen TOTP- of HOTP-implementatie valideren met de testvectoren uit RFC 6238 en 4226.
- Een uit een andere app geëxporteerde otpauth://-URI uitlezen om te zien welk algoritme, hoeveel cijfers en welke periode het account gebruikt.
- Een testaccount waarvan je het geheim al in Base32 hebt toevoegen aan een tweede app of een wachtwoordmanager.
Veelgestelde vragen
Waarom weigert de server een code die de app als geldig toont?
Bijna altijd ligt het aan de klok. TOTP vereist dat telefoon en server het eens zijn over de tijd: bij 30 seconden verschil berekenen ze al verschillende stappen. Daarom accepteren servers één of twee stappen naar elke kant. Komt de code overeen met de vorige of volgende stap, synchroniseer dan de servertijd via NTP en schakel de automatische tijd op je telefoon in.
Is het veilig om hier het geheim voor een echt account te genereren?
Het geheim wordt gegenereerd met crypto.getRandomValues en verlaat je browser niet, maar in productie moet de server die de codes controleert het genereren en opslaan. Deze tool is bedoeld om te testen en te debuggen. Behandel elk echt geheim als een wachtwoord: wie het heeft, kan voor altijd je codes genereren.
Is het beter om SHA-256, 8 cijfers of 60 seconden te gebruiken?
In theorie zijn ze sterker, maar verschillende apps, waaronder versies van Google Authenticator, negeren die parameters en berekenen altijd SHA-1 met 6 cijfers elke 30 seconden, waardoor de gebruiker codes ziet die de server weigert. SHA-1 is als HMAC nog steeds veilig. Voor compatibiliteit gebruiken bijna alle diensten de standaardwaarden.
Hoe lang moet het geheim zijn?
RFC 4226 vereist minstens 128 bits en raadt 160 aan, wat in Base32 32 tekens is. Veel diensten gebruiken 80 bits (16 tekens) en apps accepteren die ook. Deze tool genereert 160 bits.
Beschermt TOTP tegen phishing?
Niet helemaal. Het is veel beter dan SMS, dat onderschept of via een SIM-swap gestolen kan worden, maar een nepsite kan je om de code vragen en die binnen dezelfde 30 seconden op de echte site gebruiken. FIDO2-beveiligingssleutels en passkeys zijn aan het domein gebonden en zijn bestand tegen die aanval.
Wat gebeurt er als ik mijn telefoon kwijtraak?
Zonder het geheim is er geen manier om de codes te berekenen. Daarom geven diensten herstelcodes wanneer je 2FA inschakelt: bewaar ze buiten je telefoon. Sommige apps laten je de accounts versleuteld in de cloud back-uppen of als QR-code exporteren om ze naar een ander apparaat over te zetten.