pierroons a écrit 9 commentaires

Sur le reset automatique au niveau 3 : tu as raison, des signaux non-secrets ne devraient pas suffire. La logique correcte, c'est que sans secret fort vérifié, la décision revient à un humain, le scoring sert alors à l'éclairer, pas à ouvrir automatiquement. C'est la correction que j'apporte.

Sur le calcul côté client : il a quand même deux intérêts, le mot brut ne quitte jamais le navigateur (une fuite serveur ne le révèle pas), et la dérivation est liée au domaine donc non réutilisable ailleurs. Mais tu as raison de dire que la dépêche introduit le sel sans l'expliquer et que la formule varie d'une section à l'autre : à clarifier, tout comme la phrase « le secret n'est pas dans le mot de passe », mal tournée. Le texte est trop long et pas assez clair sur la base, je le reprends.

Merci pour le retour, et l'idée de RFC me parle, à creuser, je ne sais pas s'il existe déjà un standard qui couvre précisément la récupération sans email.

Sur le « second mot de passe qu'on oublie » : je crois qu'il y a un malentendu sur la nature du secret de récupération. Ce n'est pas un second mot de passe fort à mémoriser. Le schéma, c'est : ton mot de passe quotidien peut être fort et généré dans un gestionnaire, et le moyen de récupération peut être un mot simple et mémorable, du genre « voiture », que tu n'as pas besoin de stocker. La passphrase forte, elle, est un secours qu'on range dans un coffre, pas qu'on mémorise.

Sur « réutiliser le même partout = pire » : c'est justement ce que le domain-binding évite. Le même mot « voiture » produit une clé différente sur chaque site (HMAC avec le domaine), donc le réutiliser n'a pas les conséquences d'un mot de passe réutilisé, une fuite de base sur un site ne donne rien ailleurs, et les valeurs ne sont pas corrélables. Et ce mot n'est jamais utilisable seul : il faut aussi un identifiant propre au site (non public) plus le rate-limit. Connaître « voiture » ne suffit donc pas à récupérer quoi que ce soit.

Pour le changement de domaine : tu as raison, et c'est une vraie limite de l'implémentation actuelle. Aujourd'hui la dérivation inclut le nom de domaine (le hostname), donc si l'URL change suite à un rachat, les secrets dérivés ne correspondent plus. La bonne correction, que je vais apporter, c'est de dériver à partir d'un identifiant de service stable et configurable plutôt que du hostname littéral, pour que l'adresse puisse évoluer sans rien casser. Et tu vois juste : ce composant joue le rôle d'un sel, il peut donc être stocké côté serveur sans souci, un sel n'ayant pas à être secret.

Merci, c'est le genre de retour qui fait avancer le projet, des vraies questions.

Sur le scoring : les valeurs ont été calibrées empiriquement pour le premier déploiement réel du protocole, un service à faible enjeu, et elles sont prévues pour être configurables selon l'enjeu, c'est typiquement le genre de seuils qui doivent s'adapter au contexte, pas des constantes universelles. Ce qui ne dispense pas de revoir le poids relatif : tu as raison qu'un identifiant semi-public ne devrait pas peser autant qu'un secret.

Pour le reste, cooldown par IP ou par compte, sécurité du compte admin (qui relève en partie d'une autre brique, la sécurisation du serveur), et le DoS via le mécanisme de blocage, ce sont de vraies questions auxquelles je préfère répondre code en main plutôt qu'à chaud. Je reprends ça proprement et je reviens avec des réponses précises, en corrigeant ce qui doit l'être.

Merci, t'as parfaitement résumé l'idée, et le « pas de stockage client ni de tiers », c'est exactement le but.

Tu mets le doigt sur le bon arbitrage, et il faut séparer deux choses.

Côté sécurité, tu as raison : deux voies de récupération, c'est deux surfaces à protéger, et la résistance globale = celle de la voie la plus faible. C'est précisément pour ça que la voie « mot simple » n'est jamais utilisable seule, il faut le mot et un identifiant propre au site (non public), plus une limite de tentatives et une escalade. La voie passphrase, elle, est forte par construction. Donc oui, deux maillons, mais chacun durci, pas un maillon faible à nu.

Côté utilisateur, en revanche, pas besoin de retenir deux secrets : les voies sont alternatives (l'une ou l'autre suffit pour récupérer), donc on n'en mémorise qu'un, le « simple », l'autre étant un secours fort qu'on range dans un coffre. C'est un défaut de présentation actuel : je vais le clarifier et demander la correction dans la dépêche.

Tu as raison, et merci de l'avoir relevé : je vais apporter des modifications rapidement pour que ce soit cohérent. À force de relire le texte dans tous les sens, j'avais zappé cette phrase.

Ce que je voulais dire : je n'ai pas réécrit les primitives. HMAC, le hachage, les vérifications, ce sont les fonctions standard de PHP (hash_hmac, password_hash/Argon2id, password_verify). Ce qui a été écrit, c'est le code qui les assemble, la dérivation par domaine, l'enchaînement, pas les primitives elles-mêmes. La dépêche disait « écriture des primitives crypto », c'est faux, ce sera reformulé en « intégration de primitives standard ».

Merci d'avoir pris le temps et d'avoir creusé la dépêche.

Je ne prétends pas réinventer la question secrète, SelfRecover c'est juste un moyen de récupération sans email, ni compte tiers pour récupérer l'accès à ton compte. Si ce n'est pas assez clair, j'apporterai des modifications pour clarifier.

Le code est trop frais en l'état pour prétendre être intégré directement, il doit encore être testé et surtout pas que par moi. Je n'écris pas de crypto, j'utilise des lib existantes. Si ce n'est pas assez clair je peux le préciser.

Tu ne trouves pas Pierroons ? Cool, je ne suis pas du milieu dev-natif, je n'ai donc pas publié sur les forums et d'une manière générale j'essaie de ne pas encombrer avec des questions déjà posées et résolues. Quant aux réseaux sociaux, j'ai jamais accroché et je reste à l'écart de ce genre de moyen de communication d'une manière générale. Je reste juste dans mon coin pour bricoler ce que je peux, comme je le peux.

Merci pour le plus, et surtout pour ce retour : un utilisateur qui n'évalue pas la crypto mais qui raconte son vécu, c'est exactement le public qui compte. Une sécurité qui ne tient pas pour l'utilisateur lambda ne tient pas du tout.

Votre histoire illustre parfaitement le problème. Le TOTP est lié à un appareil : on change de téléphone sans avoir anticipé le transfert, et on se retrouve coincé, à éplucher trois docs, pour finir par un ticket qui désactive carrément le 2FA. Autrement dit, la sécurité a sauté parce que la récupération était trop dure. C'est l'échec d'ergonomie typique, et il est très courant.

SelfRecover essaie justement de retirer ces points de friction pour l'utilisateur ordinaire :

Il n'y a rien à transférer ni à migrer. Le secret est un mot que vous retenez, pas une application liée à un téléphone. Votre mésaventure (le changement d'appareil) ne peut pas se reproduire, puisqu'il n'y a pas d'appareil dans la boucle).

La technique est invisible. On tape un mot, point. Tout le reste (le calcul, la liaison au site) se fait tout seul dans le navigateur : rien à comprendre ni à configurer.

Et si on se trompe, on n'est pas laissé seul devant une doc : le système oriente vers le niveau de récupération suivant, jusqu'à une vérification avec un humain en dernier recours. L'idée est qu'on ne tombe jamais dans une impasse silencieuse.

Cela dit, soyons honnêtes : faire adopter un outil de sécurité au grand public reste le vrai défi, et aucun protocole ne le règle d'un coup de baguette. SelfRecover ne supprime pas ce travail, il enlève des obstacles connus (pas d'appareil, pas d'e-mail, pas de doc à déchiffrer). Le reste se joue dans le soin apporté à l'interface et à l'accompagnement, et ça, c'est un chantier permanent.

Vous touchez le point le plus dur, et honnêtement SelfRecover ne le fait pas disparaître. Aucun système ne le peut sans réintroduire un tiers (e-mail, séquestre, support), c'est-à-dire exactement la surface d'attaque qu'on cherche à retirer.

Vos variantes ont d'ailleurs un point commun : ce sont des pertes de support. Compte Google inaccessible, fichier KeePass effacé, PC formaté, fichier de passphrase égaré, à chaque fois c'est le contenant du secret qui a disparu.

Ce que SelfRecover change, c'est qu'il ne mise pas sur un secret unique, mais sur une escalade de plusieurs filets. D'abord un mot de récupération que vous mémorisez, combiné à votre numéro de compte propre au site (num client, num ID forum etc) : il faut les deux, et il vit dans votre tête, sans fichier à perdre. Ensuite en cas d'échec, une passphrase forte générée à l'inscription, à conserver comme clé de secours. Et si tout a été perdu, un dernier recours par vérification avec un humain.

Sur ce mot (de récup), justement : il peut être tout simple, même « bob ». D'une part il ne quitte jamais votre navigateur tel quel, il est transformé en une empreinte propre au site (le serveur ne voit jamais « bob »).
D'autre part, comme un mot simple resterait devinable, on ne peut pas le marteler en ligne : quelques tentatives ratées et le compte est bloqué temporairement, puis l'échec répété fait basculer vers le niveau supérieur, jusqu'à la vérification humaine. Et de toute façon, sans votre numéro de compte en plus, le mot seul ne suffit pas.

L'idée n'est pas qu'un seul de ces éléments soit infaillible, mais qu'il faille les perdre tous en même temps pour être vraiment bloqué, sans jamais dépendre d'un e-mail ni d'un tiers à pirater.

Reste le cas où l'on a vraiment tout perdu, sans rien avoir retenu ni noté. Là, soyons honnêtes, aucun système ne fait de miracle, et SelfRecover ne prétend pas le contraire. Mais plutôt que de promettre un «lien magique » par e-mail (qui serait justement la faille), il accompagne ce cas jusqu'au dernier niveau, la vérification humaine. C'est une limite assumée, pas un angle mort caché.

En somme, SelfRecover ne supprime pas la galère ultime, mais il empile les filets au lieu de faire reposer toute la récupération sur un canal unique et fragile comme l'e-mail.

Bonjour, et merci pour ce retour précis, il fait avancer le sujet.

Sur Keycloak, les flows sont suffisamment configurables pour permettre ça, et ma formulation méritait d'être nuancée. Pour rester factuel cela dit : dans la documentation officielle et la configuration par défaut, les Recovery Authentication Codes sont positionnés comme une méthode de second facteur (2FA) de secours, un repli pour se connecter quand l'OTP ou WebAuthn est indisponible (cf. l'annonce Keycloak d'octobre 2025). Le reset du mot de passe principal, lui, passe par le flow « forgot password » vers l'email (SMTP). Obtenir une réinitialisation du mot de passe via les Recovery Codes suppose donc un flow self-service sur mesure, pas le comportement standard.

Une précision d'abord, car elle lève peut-être le malentendu : SelfRecover ne remplace pas le mot de passe. On se connecte au quotidien avec un mot de passe classique. Le mot de récupération, lui, ne sert qu'à retrouver ce mot de passe quand on l'a perdu : il prend la place du traditionnel « lien de réinitialisation par e-mail ». Le secret n'est donc pas dans le mot de passe, il est dans le moyen de le retrouver, sans e-mail ni tiers.

Et ce moyen de récupération n'est pas un mot de passe non plus, ni dans sa nature, ni dans son fonctionnement.

Un secret de type mot de passe est statique : on le tape, il transite (sous TLS) jusqu'au serveur, qui le voit en clair au moment de la vérification avant de le comparer à son empreinte. C'est une valeur fixe, identique partout où on la réutilise.

Le mot de récupération SelfRecover, lui, ne quitte jamais le navigateur. Concrètement : le navigateur calcule localement une dérivation HMAC-SHA256(mot de récup, domaine du site + sel), et seule cette clé dérivée est envoyée au serveur (POST), qui n'en conserve qu'un hash Argon2id. Le mot lui-même ne part jamais sur le réseau.

      mot de récup (dans votre tête)
         │  reste local, ne part jamais sur le réseau
         ▼
      HMAC-SHA256(mot, domaine + sel)   (calculé DANS le navigateur)
         │
         ▼
      clé dérivée  --POST-->  serveur : stocke/compare Argon2id(clé dérivée)

Trois conséquences qui n'existent pas avec un mot de passe :

1. Le mot lui-même n'est jamais transmis ni stocké. Ce qui circule, c'est une dérivée. Le serveur ne voit jamais le mot ; en base il n'en garde qu'un hash Argon2id (non réversible).

2. Le secret est lié au domaine. La même phrase produit une clé différente sur chaque site (le domaine entre dans le HMAC). Une dérivée captée sur site-a.fr est inutile sur site-b.fr, et un site de phishing calcule une clé qui ne correspond à rien.

3. C'est donc une graine, pas un mot de passe. Une seule phrase mémorisable (diceware, conçue pour la tête) sert de filet de récupération sur tous vos sites, sans jamais être ni transmise, ni réutilisable, ni stockée.

D'où la réponse à « ne retombe-t-on pas toujours sur le support humain ? » : non. Qui a sa phrase (en tête ou en coffre) récupère son accès en self-service, sans e-mail ni humain. Le cas « tout perdu » garde un fallback (scoring, support), mais SelfRecover réduit la part des cas qui y tombent, et supprime l'e-mail comme point de défaillance et surface d'attaque.

Pour l'utilisateur déjà rigoureux avec un gestionnaire, le gain reste modeste, je l'accorde. Mais le mécanisme n'est pas « un mot de passe rangé ailleurs » : c'est le moyen de retrouver son accès, qui ne transite pas, ne se stocke pas, et n'a pas de valeur hors de son domaine.

Dernière chose, puisque la portée revient souvent : le même principe de dérivation (un secret racine vers des clés filles par label, via Argon2id) sert aussi, dans un module compagnon en cours de validation, à déverrouiller un volume LUKS, où le label cloisonne la clé « web » et la clé « disque ». La logique « récupération sans tiers » s'étend ainsi au chiffrement de disque, pas seulement aux comptes web.