• # L'aspect standardisation est intéressant

    Posté par . En réponse à la dépêche SelfRecover — protocole AGPL de récupération de compte sans email. Évalué à 5 (+3/-0). Dernière modification le 30 mai 2026 à 11:39.

    Salut,
    je trouve que l'idée de proposer un standard pour normaliser les interactions de récupération est super. Avoir la même logique d'un service à un autre permet de mieux s'y retrouver, plutôt que d'avoir des trucs différents (codes de récup, lien par mail, clé de secours...). Ce serait sans doute intéressant d'en faire une RFC si ça n'existe pas déjà.

    Après, sur ce qui est proposé ici, l'idée centrale de retenir un second mot de passe (que tu n'utilises jamais, donc que tu oublies facilement) au cas où tu oublies le mot de passe principal (que tu utilises souvent), ça me semble voué à l'échec, sauf à réutiliser le même mot de passe de secours d'un service à un autre, ce qui est pire que le problème que tu cherches à résoudre.

    J'ai une question aussi :

    Côté navigateur, on calcule HMAC-SHA256(secret, domaine) : une fonction cryptographique standard qui combine le secret de l'utilisateur avec le nom de domaine du site, et produit une empreinte impossible à inverser

    Que se passe-t-il quand le nom de domaine change ? Par exemple, une entreprise se fait racheter, et l'URL du service passe de https://labaguette.fr/ à https://theworldbakery.com/baguette/ ? Ton condensat HMAC ne fonctionne plus ? Ou bien il faut stocker sur quel domaine il a été généré car ça peut changer. Ce qui revient à dire que le nom de domaine devient un second sel, qu'il faut donc stocker côté serveur ?