Je me suis souvent posé la question de comment identifier un utilisateur sans avoir d'information sur lui.
Le problème que vous remontez n'est pas réellement le soucis. Du coup, la solution technique, recursive, n'est pas attrayante. S'il faut une pass-phrase maître, c'est de-facto le mot de passe, et l'ancien "mot de passe" n'est qu'un jeton (un token). Du coup, l'oubli de l'ancien mot de passe dans votre procédure, c'est exactement ce que fait la génération d'un nouveau token JWT (sans en dire les mots), et c'est nul. Le problème de votre solution c'est que le serveur doit faire confiance au navigateur/utilisateur (dont le localStorage peut être capturé) et donc vous exposez le serveur à justement ce que vous critiquez avec l'ANTS: de l'usurpation d'identité.
Je ne vois pas l'intérêt.
Pour qu'un mot de passe soit retenu, il faut l'utiliser souvent (technique de répétition espacée). La passphrase, c'est très mauvais pour l'humain, car, n'étant que jamais utilisée, elle est encore plus encline à être oubliée. Donc la solution contre un oubli d'une information fréquente, c'est de recracher une information perdue => ça ne fonctionne pas.
Donc au final, s'il faut stocker la passphrase dans un gestionnaire de mots de passe, autant y stocker le mot de passe, ou, encore mieux, le générateur d'un TOTP.
Utiliser le navigateur pour stocker des informations ne fonctionne pas non plus, car les utilisateurs utilisent plusieurs systèmes hétérogènes dont les caches et les "profils" ne sont pas synchronisés (ce qui est plutôt une bonne chose, la synchronisation est une hérésie de sécurité, si l'un seul des systèmes tombe, tout est perdu).
Du coup, le fruit de ma réflexion (non achevée) c'est que c'est toute l'architecture des mots de passe est à jeter. Il n'y a pas de solution à ce problème.
Il a par contre des solutions à l'identification de l'utilisateur:
Les secrets partagés (type Shamir), type 2/3 (2 informations secrètes sont nécessaires sur 3 secrets pour retrouver un secret). Ici, il y a un tiers (pas de confiance, mais partagé avec plusieurs sites dont l'utilisateur reconnaît), qui stocke un des 3 shards (secrets), l'utilisateur en stocke un autre, le serveur le dernier. Pour l'authentification normale, l'utilisateur communique son secret (soit directement soit via Diffie Helman) et le serveur aussi, 2/3 => secret commun calculable. En cas d'oubli de l'utilisateur, l'utilisateur contacte le tiers qui prévient le serveur qu'une rotation des secrets est obligatoire, puis transmet son secret à l'utilisateur, 2/3 => secret commun calculable, le serveur régénère 3 shards et les distribue à chacun. C'est le principe du mot de passe oublié actuel, mais sans email, sans possibilité de MITM, où chaque partie n'a pas assez pour que l'information fuitée (quand ça arrive) soit utile.
L'historique des utilisateurs. Puisque le serveur connaît des informations sur l'utilisateur, il peut utiliser ces informations pour calculer un indice de confiance sur l'utilisateur en lui posant des questions ou suivant ce qu'il observe de l'utilisateur. En gros au lieu de demander un mot de passe à 27 caractères, avec 3 caractères spéciaux mais sans guillemet et 4 chiffres non successifs, ce que les humains sont très mauvais à retenir, il demande "quand a eu lieu votre dernière connexion?", "quel était l'objet de votre dernière connexion?", "en quelle année avez vous créé votre compte?", "citez 2 articles que vous avez acheter sur ce site récemment", etc... Les humains sont excellents pour se rappeler d'un contexte, il faut que le système s'adapte à eux et pas le contraire.
L'anonymat. Après tout, pour la majorité des cas, il n'est pas nécessaire de savoir précisément qui est l'utilisateur. Tu navigues sur Amazon pour acheter un slip, les seules informations absolument nécessaires sont... l'adresse de livraison. Ce que le navigateur peut remplir automatiquement. Le paiement se fait par un tiers de toute façon. Le tracking publicitaire est une plaie.
# Une solution en recherche de problème?
Posté par xryl669 . En réponse à la dépêche SelfRecover — protocole AGPL de récupération de compte sans email. Évalué à 6 (+5/-0).
Je me suis souvent posé la question de comment identifier un utilisateur sans avoir d'information sur lui.
Le problème que vous remontez n'est pas réellement le soucis. Du coup, la solution technique, recursive, n'est pas attrayante. S'il faut une pass-phrase maître, c'est de-facto le mot de passe, et l'ancien "mot de passe" n'est qu'un jeton (un token). Du coup, l'oubli de l'ancien mot de passe dans votre procédure, c'est exactement ce que fait la génération d'un nouveau token JWT (sans en dire les mots), et c'est nul. Le problème de votre solution c'est que le serveur doit faire confiance au navigateur/utilisateur (dont le localStorage peut être capturé) et donc vous exposez le serveur à justement ce que vous critiquez avec l'ANTS: de l'usurpation d'identité.
Je ne vois pas l'intérêt.
Pour qu'un mot de passe soit retenu, il faut l'utiliser souvent (technique de répétition espacée). La passphrase, c'est très mauvais pour l'humain, car, n'étant que jamais utilisée, elle est encore plus encline à être oubliée. Donc la solution contre un oubli d'une information fréquente, c'est de recracher une information perdue => ça ne fonctionne pas.
Donc au final, s'il faut stocker la passphrase dans un gestionnaire de mots de passe, autant y stocker le mot de passe, ou, encore mieux, le générateur d'un TOTP.
Utiliser le navigateur pour stocker des informations ne fonctionne pas non plus, car les utilisateurs utilisent plusieurs systèmes hétérogènes dont les caches et les "profils" ne sont pas synchronisés (ce qui est plutôt une bonne chose, la synchronisation est une hérésie de sécurité, si l'un seul des systèmes tombe, tout est perdu).
Du coup, le fruit de ma réflexion (non achevée) c'est que c'est toute l'architecture des mots de passe est à jeter. Il n'y a pas de solution à ce problème.
Il a par contre des solutions à l'identification de l'utilisateur: