Hachage/Crypto
TOTP Generator/Verifier
Mots de passe à usage unique basés sur le temps (TOTP, RFC 6238) — générer le code actuel à partir d'un secret et vérifier un code saisi avec tolérance au décalage d'horloge.
------
TOTP (Time-based One-Time Password, RFC 6238) is a two-factor authentication algorithm that generates a one-time code from a secret and the current time. It's exactly what runs under the hood in Google Authenticator, Authy, and similar apps.
How to use it
- Generate: paste a secret key (usually Base32, the same one encoded in a 2FA setup QR code) and the tool shows the current 6-digit code along with the time left before it changes.
- Verify: enter a secret and a code from an authenticator app to check whether they match.
- Verification tolerates a small amount of clock drift — it accepts a code from a neighboring time step, not just the current one.
Common uses
- Debugging your own 2FA implementation on the backend — checking that the server generates and accepts codes correctly.
- Manually generating a code for an account when you don't have your phone with the authenticator app handy.
- Figuring out why an app's code is being rejected by the server (usually the cause is a clock out of sync).
Things to keep in mind
A TOTP code is only valid for a short window (usually 30 seconds) — that time limit is the main protection, not the secret alone.
Code accuracy depends directly on the device's clock being synced; a noticeable clock drift is the most common cause of rejected 2FA codes.
Questions fréquentes
Sur quelle norme repose le TOTP ?
TOTP est défini par la RFC 6238 : il dérive un code à usage unique à partir d'un secret partagé et de l'heure actuelle via HMAC, sur le même principe que Google Authenticator ou d'autres applications d'authentification à deux facteurs.
Pourquoi le code change-t-il toutes les 30 secondes ?
Le code est calculé sur une fenêtre de temps fixe (généralement 30 s), appelée pas de temps : à chaque nouvelle fenêtre, un nouveau code est généré. Cela limite la durée de validité d'un code intercepté.
Pourquoi un code TOTP peut-il être refusé alors qu'il semble correct ?
Si l'horloge de l'appareil qui génère le secret n'est pas synchronisée (via NTP) avec celle du vérificateur, les codes calculés ne correspondent plus, même à quelques secondes de décalage. La fenêtre de tolérance compense de petits écarts, mais pas un décalage important.
TOTP protège-t-il contre le phishing ?
Pas totalement. Si la victime saisit son mot de passe et le code TOTP actuel sur un site frauduleux, l'attaquant peut instantanément réutiliser les deux valeurs sur le vrai site tant que le code est encore valide. Seules les clés matérielles conformes au standard FIDO2/WebAuthn protègent contre ce type d'attaque en temps réel.
Pourquoi le serveur accepte-t-il aussi l'intervalle de temps précédent, et pas seulement l'actuel ?
Cela compense un léger délai réseau entre la génération du code sur le téléphone et le moment où le serveur le reçoit et le vérifie. Sans cette marge, des codes légitimes seraient parfois rejetés à cause d'un simple retard de quelques secondes.