Pour commencer, le module a beaucoup changé depuis cette dépêche. Je te donne tous les liens à la fin du msg.
Tu as raison, et autant le dire clairement : mon premier message était trompeur. Le domain-binding ne protège pas contre la réutilisation d'un secret. Si quelqu'un connaît ta phrase de récup en clair et que tu la réutilises ailleurs, il recalcule la clé sur chaque site. Aucune dérivation ne sauve un secret brut connu et réutilisé.
Ce que le binding fait, c'est autre chose : il empêche la corrélation des empreintes stockées d'un service à l'autre. Si la base de plop.fr fuite, l'attaquant récupère HMAC(secret, plop.fr), qui ne rejoue pas sur coin.com (la valeur y est différente). Ça protège contre le rejeu de hash entre services, pas contre un secret en clair réutilisé.
Dans SelfRecover un secret réutilisé reste atténué, pas annulé. La récup n'est pas « secret → accès » : il faut aussi l'identifiant. L'identifiant étant semi-public, on ne peut pas le considérer comme un second facteur fort. C'est pour ça que je travaille sur un code de récupération généré (type recovery codes), conservé côté utilisateur : pas une garantie absolue, mais un second facteur nettement plus solide qu'un simple identifiant.
Sur la question du changement de domaine : tu avais raison, et c'est ce qui m'a fait changer d'approche. J'ai retiré le domaine littéral de la dérivation. À la place : un label de service stable (une constante, pas l'URL) + un sel par utilisateur. Le label reprend le rôle que tu donnais au domaine — séparer les services — et le sel par-user ajoute une séparation par compte que le domaine ne faisait pas. Du coup un rachat ou un changement d'URL ne casse plus rien, et deux comptes avec le même secret ne produisent pas la même empreinte.
[^] # 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 (+0/-0).
Bonjour cg,
Pour commencer, le module a beaucoup changé depuis cette dépêche. Je te donne tous les liens à la fin du msg.
Tu as raison, et autant le dire clairement : mon premier message était trompeur. Le domain-binding ne protège pas contre la réutilisation d'un secret. Si quelqu'un connaît ta phrase de récup en clair et que tu la réutilises ailleurs, il recalcule la clé sur chaque site. Aucune dérivation ne sauve un secret brut connu et réutilisé.
Ce que le binding fait, c'est autre chose : il empêche la corrélation des empreintes stockées d'un service à l'autre. Si la base de plop.fr fuite, l'attaquant récupère HMAC(secret, plop.fr), qui ne rejoue pas sur coin.com (la valeur y est différente). Ça protège contre le rejeu de hash entre services, pas contre un secret en clair réutilisé.
Dans SelfRecover un secret réutilisé reste atténué, pas annulé. La récup n'est pas « secret → accès » : il faut aussi l'identifiant. L'identifiant étant semi-public, on ne peut pas le considérer comme un second facteur fort. C'est pour ça que je travaille sur un code de récupération généré (type recovery codes), conservé côté utilisateur : pas une garantie absolue, mais un second facteur nettement plus solide qu'un simple identifiant.
Sur la question du changement de domaine : tu avais raison, et c'est ce qui m'a fait changer d'approche. J'ai retiré le domaine littéral de la dérivation. À la place : un label de service stable (une constante, pas l'URL) + un sel par utilisateur. Le label reprend le rôle que tu donnais au domaine — séparer les services — et le sel par-user ajoute une séparation par compte que le domaine ne faisait pas. Du coup un rachat ou un changement d'URL ne casse plus rien, et deux comptes avec le même secret ne produisent pas la même empreinte.
Codes Github :
SelfRecover : https://github.com/Pierroons/my-self/tree/main/bi-self/selfrecover
SelfRecover-LUKS : https://github.com/Pierroons/my-self/tree/main/self-security/selfrecover-luks
SelfDataGuard: https://github.com/Pierroons/my-self/tree/main/self-security/selfdataguard
Si tu veux voir le code de la dérivation : https://github.com/Pierroons/my-self/blob/c952678/bi-self/selfrecover/demo/index.html#L659-L682
J'ai aussi fait faire un pentest, sur mon serveur perso LNMP, à Opus que tu peux retrouver sur cette page : https://my-self.fr/pentest.html
Ce serveur est protégé par les 3 modules cités au dessus.
Pour le l3 j'ai aussi fait une page web afin de pas tartiner le msg : https://bi-self.my-self.fr/selfrecover/l3.html
Et pour la RFC : oui, c'est une piste que je garde en tête.
Merci.