Fenêtre TOTP : secondes restantes et indice
À l’instant Unix 1700000000 avec une période de 30 secondes, vous vous trouvez dans la fenêtre 56666666 et il reste 10 secondes avant que le compteur avance. Indiquez période et horodatage pour examiner des codes qui semblent expirer trop tôt, sans aucun secret. Gratuit dans votre navigateur.
- Gratuit
- Fonctionne dans votre navigateur
- Sans inscription
- Vos données restent sur votre appareil
Lancer gratuitement
Exemple résolu
- Période
- 30
- Heure actuelle
- 1 700 000 000
- Secondes restantes
- 10
- Indice de la fenêtre
- 56 666 666
Ce calculateur de fenêtre temporelle TOTP convertit la durée d’une période et un horodatage Unix en deux valeurs pratiques : l’indice de la fenêtre active et le nombre de secondes entières avant le début de la suivante. Il facilite la création, le test et le diagnostic des systèmes de mots de passe à usage unique fondés sur le temps, notamment lorsqu’un code semble expirer trop tôt. Le calcul est déterministe, n’utilise aucune clé secrète, ne génère aucun mot de passe et ne consulte jamais l’horloge de votre appareil. Une entrée identique produit donc toujours le même résultat.
Comprenez ce que représente une fenêtre temporelle TOTP
Un système TOTP divise le temps Unix en fenêtres consécutives de même durée. Trente secondes constituent une période courante, mais le calcul accepte tout nombre entier positif de secondes. L’indice de la fenêtre correspond à l’horodatage Unix divisé par la période, puis arrondi à l’entier inférieur.
Tous les horodatages donnant le même quotient appartiennent à la même fenêtre ; un authentificateur et un serveur peuvent ainsi sélectionner indépendamment le même compteur mobile. Ce calculateur affiche directement ce compteur, sans demander de secret partagé ni produire de code d’authentification. Il indique également combien de secondes entières restent avant le passage au compteur suivant.
À la première seconde exacte d’une fenêtre, toute la période reste disponible ; à la dernière, il reste une seconde. Cette convention rend les comptes à rebours utiles et évite d’afficher zéro alors que la fenêtre actuelle est encore active.
Choisissez les entrées et interprétez le résultat
Définissez period comme la durée configurée d’un pas TOTP, exprimée par un nombre entier positif de secondes. L’indice commence à zéro à l’époque Unix et représente généralement un entier élevé pour les horodatages actuels. Ce n’est pas un code et vous ne devez pas le comparer aux chiffres affichés par un authentificateur.
Comparez plutôt les indices de fenêtre pour vérifier que deux composants partagent la même notion du temps, ou utilisez la valeur restante afin de déterminer quand un test doit attendre la prochaine limite. La fonction n’applique aucune tolérance au décalage d’horloge, acceptation des fenêtres adjacentes, correction des secondes intercalaires ou latence réseau. Ces éléments relèvent de la politique du vérificateur.
Le résultat décrit uniquement la fenêtre mathématiquement active pour l’horodatage et la période fournis, ce qui rend les tests automatisés prévisibles et les écarts plus faciles à isoler.
Utilisez le calculateur en toute sécurité lors des tests et opérations
Utilisez cette capacité lorsque vous avez besoin d’informations temporelles sans exposer une graine TOTP. Dans les tests d’intégration, des horodatages fixes permettent de contrôler le comportement juste avant, au moment et après une limite, sans simuler une horloge cachée dans ce calculateur. Gardez à l’esprit qu’une fenêtre concordante ne prouve pas la validité d’un mot de passe à usage unique soumis.
La vérification nécessite encore le secret partagé, les paramètres convenus de hachage et de nombre de chiffres, une protection contre la réutilisation et une politique de tolérance explicite. Évitez de consigner des secrets avec ces diagnostics temporels : la période, l’horodatage, l’indice et le compte à rebours suffisent pour analyser la plupart des problèmes de synchronisation.
Cas d’usage
Diagnostiquer l’alignement de l’horloge d’un authentificateur
Comparez les indices calculés pour les horodatages enregistrés côté client et serveur afin de repérer un écart d’horloge ou de période sans partager de graine TOTP.
Créer un compte à rebours avant le changement
Affichez le nombre de secondes entières avant que le compteur TOTP actif avance et qu’un nouveau code appartienne à la fenêtre suivante.
Tester les limites exactes des fenêtres
Utilisez des horodatages Unix fixes juste avant et exactement à une limite pour rendre les tests temporels d’authentification déterministes et reproductibles.
Questions fréquentes
Combien coûte cette capacité ?
La version pour navigateur peut effectuer localement le même calcul déterministe.
Génère-t-elle ou vérifie-t-elle un code TOTP ?
Non. Elle calcule uniquement des métadonnées temporelles et n’accepte jamais de secret partagé ni de mot de passe à usage unique.
Pourquoi la période complète est-elle renvoyée à une limite exacte ?
La nouvelle fenêtre vient de commencer : aucune de ses secondes entières ne s’est écoulée et toute la période reste disponible.
Faut-il saisir le temps en secondes ou en millisecondes ?
En secondes Unix entières, jamais en millisecondes. Une valeur en millisecondes pointerait vers une fenêtre très lointaine dans le futur. Un horodatage explicite permet aussi de reproduire le résultat dans des tests, des journaux ou des rapports d’incident.
Si deux systèmes partagent la même fenêtre, le code est-il valable ?
Pas forcément. Une fenêtre identique montre seulement que les deux côtés s’accordent sur l’heure. Pour valider un code, il faut encore le secret partagé, les réglages convenus, une protection contre la réutilisation et une tolérance claire au décalage d’horloge.
Outils associés
Pour les développeurs — accès API
Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.
Endpoint
Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.
Appeler depuis votre stack
curl -X POST https://api.kit.forhosting.com/security/otp-time-window-calc \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"period":30,"current_time":1700000000}'const res = await fetch("https://api.kit.forhosting.com/security/otp-time-window-calc", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"period": 30,
"current_time": 1700000000
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/security/otp-time-window-calc",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"period": 30,
"current_time": 1700000000
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/security/otp-time-window-calc", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"period":30,"current_time":1700000000}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"period":30,"current_time":1700000000}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/security/otp-time-window-calc", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Exemple de requête
{
"period": 30,
"current_time": 1700000000
}Exemple de réponse
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "security.otp_time_window_calc",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.
Tarifs
Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.
Erreurs
| HTTP | Code | Signification |
|---|---|---|
401 | unauthorized | Clé API absente ou invalide : vérifiez l’en-tête Authorization. |
402 | insufficient_balance | Solde insuffisant : rechargez votre compte pour lancer cette tâche. |
404 | unknown_type | Type de tâche inconnu : vérifiez le champ type de votre requête. |
429 | rate_limited | Trop de requêtes : ralentissez la cadence, puis réessayez. |
Notes techniques
Comprenez ce que représente une fenêtre temporelle TOTP
Saisissez explicitement l’horodatage en secondes Unix, et non en millisecondes, afin de reproduire le résultat dans les journaux, les tests et les comptes rendus d’incident sans dépendre de l’horloge du navigateur ou du processus API.
Choisissez les entrées et interprétez le résultat
Fournissez ensuite current_time sous la forme d’un horodatage Unix non négatif en secondes entières. La réponse contient seconds_remaining et window_index. Par exemple, si dix secondes se sont écoulées dans la fenêtre actuelle d’une période de trente secondes, seconds_remaining vaut vingt.
Utilisez le calculateur en toute sécurité lors des tests et opérations
Une tâche de surveillance peut calculer l’indice actuel à partir d’un horodatage enregistré, tandis qu’une interface peut exploiter seconds_remaining pour avertir qu’un code est sur le point de changer. Chaque appel API coûte $0.002, tandis que la version pour navigateur peut s’exécuter localement. Comme l’algorithme effectue un calcul en temps constant sans accès au réseau, au hasard ou à l’horloge, des appels identiques renvoient le même JSON et conviennent aux tests de référence et aux pistes d’audit.
Questions techniques
current_time doit-il être exprimé en secondes ou millisecondes ?
Utilisez des secondes Unix entières. Convertissez un horodatage en millisecondes en secondes avant de le soumettre.
Que se passe-t-il si la période vaut zéro ou est négative ?
La requête échoue avec une erreur invalid_input, car une fenêtre temporelle TOTP doit avoir une durée positive.