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 :
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).
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.
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.
[^] # Re: Keycloak
Posté par pierroons (site web personnel) . En réponse à la dépêche SelfRecover — protocole AGPL de récupération de compte sans email. Évalué à 0 (+3/-3).
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.
Trois conséquences qui n'existent pas avec un mot de passe :
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).
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.
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.