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.
[^] # Re: L'aspect standardisation est intéressant
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 (+2/-2). Dernière modification le 30 mai 2026 à 13:13.
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.