PayCal Technologies Inc.

Codes de récupération lisibles sans affaiblir la récupération de compte

En juin 2026, nous avons repensé la récupération de compte PayCal pour la rendre plus simple pour de vrais utilisateurs sous stress : Recovery Codes enregistrés plus courts, Verification Code par email clair, checksums résistants aux fautes de frappe, collage tolérant et formulaire calme. La règle de sécurité n’a pas changé : la récupération doit prouver à la fois l’accès à la boîte mail et la possession du secret de compte enregistré.

Publié : · Dernière mise à jour :

Résumé exécutif

Pourquoi nous l’avons fait La récupération de compte doit être rapide, lisible et calme sans devenir permissive
Facteur enregistré Recovery Code : XXXXXX-XXXXXX-CC, où 12 caractères sont secrets et 2 sont un checksum
Facteur email Verification Code : XXXXCC, où 4 caractères sont secrets et 2 sont un checksum
Alphabet ABCDEFGHJKLMNPQRTUWXYZ346789, choisi pour éviter les caractères visuellement confus
Limites serveur Fenêtre de 10 minutes pour le code email, usage unique, limites de tentatives, délai de renvoi, TTL de transaction et télémétrie d’abus
Frontière de sécurité Le code email prouve l’accès à la boîte mail. Le Recovery Code prouve la possession du secret de compte enregistré. Aucun des deux ne suffit seul pour une récupération protégée.

Le problème que nous résolvions

La récupération n’est pas une connexion normale. Les personnes y arrivent quand quelque chose s’est déjà mal passé : appareil perdu, passkey manquante, nouveau téléphone ou échéance. Une conception de récupération peut être solide cryptographiquement et échouer quand même si le code est trop long, difficile à lire, difficile à copier ou facile à mal saisir.

Le but n’était pas de rendre la récupération désinvolte. Le but était de rendre le chemin honnête moins douloureux tout en gardant le serveur strict. Cela signifiait réduire les erreurs de transcription, garder tous les champs importants sur un seul écran, rendre le collage tolérant et valider les fautes évidentes avant que l’utilisateur attende une réponse serveur.

Les nouveaux codes

Les deux codes utilisent le même alphabet d’accessibilité PayCal :

ABCDEFGHJKLMNPQRTUWXYZ346789

Nous excluons volontairement les caractères souvent confondus à la lecture, à la copie, à l’impression ou à la saisie. Les entrées sont normalisées en majuscules et en supprimant espaces et traits d’union, afin que les utilisateurs puissent coller des codes groupés ou non groupés.

Code Format affiché Caractères secrets Caractères checksum
Recovery Code XXXXXX-XXXXXX-CC 12 2
Verification Code XXXXCC 4 2

Le checksum n’est pas secret et n’ajoute pas d’entropie de sécurité. Il sert à détecter les erreurs honnêtes. Si les deux derniers caractères ne correspondent pas à la partie secrète, le navigateur peut immédiatement dire : « Vérifiez les deux derniers caractères », avant que l’utilisateur consomme une tentative serveur.

Les calculs

Le Recovery Code comporte 12 caractères secrets tirés de 28 symboles possibles. Cela donne :

28^12 = 232,218,265,089,212,416 possibilities
log2(28^12) ~= 57.7 bits

Le Verification Code par email comporte 4 caractères secrets :

28^4 = 614,656 possibilities
log2(28^4) ~= 19.2 bits

Lorsque les deux facteurs sont considérés ensemble, l’espace secret de recherche est :

28^16 = 142,734,349,946,674,946,768,896 possibilities
log2(28^16) ~= 76.9 bits

Une supposition aléatoire contre le Recovery Code enregistré vaut environ 1 chance sur 232 quadrillions. Une supposition aléatoire contre les deux facteurs ensemble vaut environ 1 chance sur 142 sextillions. Avec cinq suppositions combinées, la probabilité reste d’environ 3,5 x 10^-23, soit environ 1 sur 28,5 sextillions.

Pourquoi la force brute en ligne prend si longtemps

L’expression importante est récupération en ligne. Les attaquants ne peuvent pas lancer des essais illimités dans PayCal aussi vite que leur matériel calcule. Le serveur contrôle le rythme, compte les échecs, expire les codes, enregistre la télémétrie d’abus et exige que l’état de transaction corresponde.

Avec les valeurs conservatrices actuelles, la récupération est bornée par des contrôles comme :

  • les Verification Codes par email expirent après 10 minutes ;
  • les Verification Codes par email sont à usage unique ;
  • les endpoints de vérification et de preuve sont limités en tentatives ;
  • les démarrages de récupération sont limités par jour ;
  • les renvois sont limités par heure et ont un délai ;
  • les échecs de checksum vus par le serveur comptent dans la télémétrie d’abus et la politique de tentatives ;
  • les transactions de récupération et fenêtres bootstrap expirent ;
  • le serveur, pas le navigateur, reste l’autorité.

À cinq essais par heure, essayer la moitié de l’espace du Recovery Code prendrait environ 2,65 billions d’années. Essayer la moitié de l’espace combiné Recovery Code plus code email au même rythme en ligne prendrait environ 1,63 trillions d’années. C’est ce que nous voulons dire par « vraiment, vraiment très longtemps » : non parce que l’utilisateur doit porter un code énorme, mais parce que la récupération en ligne a plusieurs facteurs et que le serveur ne laisse pas les essais tourner librement.

La fenêtre de 10 minutes

Le code email est volontairement court parce qu’il n’est pas censé protéger le compte à lui seul. Il est limité dans le temps, envoyé dans la boîte mail de l’utilisateur, limité en tentatives et consommé au succès.

Avec 614 656 secrets possibles de code email, cinq essais dans une fenêtre de 10 minutes donnent au plus 0,000813 % de chance de deviner le code par hasard, soit environ 1 sur 122 931. Cela ne compléterait toujours pas une récupération protégée, car le Recovery Code enregistré et la preuve de récupération doivent aussi passer.

Ce qui a changé dans l’expérience utilisateur

Nous avons réduit l’écran de récupération à un seul formulaire centré. L’utilisateur voit le champ email, le champ Verification Code, le champ Recovery Code et une action principale : Verify and continue.

  • L’utilisateur peut coller le Recovery Code enregistré pendant qu’il attend l’email.
  • Les espaces et traits d’union sont acceptés et normalisés.
  • Les Recovery Codes sont autoformatés en XXXXXX-XXXXXX-CC.
  • Les Verification Codes sont autoformatés en XXXXCC.
  • Les caractères invalides de l’alphabet affichent un message clair en ligne.
  • Les échecs de checksum sont détectés localement avant la requête serveur.
  • Quand les deux formats semblent corrects, le formulaire affiche « Checking... » et s’envoie automatiquement après un court debounce.
  • Le bouton Verify and continue reste disponible comme solution de secours.

Le résultat est plus rapide pour l’utilisateur normal : moins d’étapes, moins de surprises, moins d’état caché et moins de pénalité lorsqu’un code est copié avec des espaces ou des traits d’union.

Ce qui a changé dans le modèle de sécurité

La refonte a aussi renforcé plusieurs frontières de récupération :

  • Les Recovery Codes bruts ne sont pas envoyés par email. Ils sont affichés une seule fois lors de leur création et doivent être enregistrés par l’utilisateur.
  • PayCal stocke du matériel recovery-wrapped et un état de vérificateur, jamais le Recovery Code brut.
  • Les magic links ne peuvent pas rendre à eux seuls un compte protégé existant prêt pour passkey.
  • Le bootstrap email seul est permis uniquement pour la configuration du premier passkey lorsqu’il n’existe aucun matériel crypto protégé et aucun passkey existant.
  • Terminer la récupération exige que l’ID de credential passkey enregistré dans la transaction de récupération corresponde à la demande de finalisation.
  • Les anciens passkeys sont révoqués après une récupération de compte réussie afin que le nouveau passkey devienne l’identifiant de confiance.

Ce que cela ne signifie pas

Ce n’est pas une affirmation qu’un code humainement lisible de 12 caractères est un secret hors ligne de 256 bits. La récupération de compte PayCal est un flux en ligne, médié par serveur, à deux facteurs. Le Recovery Code est un facteur ; l’accès à la boîte mail et l’état de transaction en sont un autre ; l’enregistrement de passkey est l’étape finale liée à l’appareil.

Cette distinction compte. Nous avons rendu le code lisible parce que les personnes doivent le sauvegarder et le saisir correctement. Nous avons gardé le serveur strict parce qu’une récupération lisible ne doit pas signifier une récupération faible.

La règle que nous appliquons maintenant

Le code email prouve l’accès à la boîte mail.
Le Recovery Code prouve la possession du secret de compte enregistré.
Aucun des deux ne suffit seul pour une récupération de compte protégée.

C’est l’équilibre que nous voulions : une récupération qui semble facile, rapide et simple pour le propriétaire du compte, tout en restant assez stricte pour que deviner via le serveur ne soit pas une voie pratique.