Je suis agriculteur en Creuse et je code sur mon temps libre. J'ai commencé à m'intéresser à la question de la récupération de compte en développant ARC PVE Hub, un site destiné à fédérer une communauté de joueurs. Je n'ai jamais compris pourquoi il fallait transmettre son email pour régénérer un mot de passe — ça déplace la sécurité du compte vers un fournisseur SMTP tiers, qui n'est pas contrôlé par l'utilisateur.
J'ai donc imaginé un protocole de récupération sans email, sans SMS et sans tiers. Le travail s'est étoffé en partenariat avec un assistant IA (Claude), comme outil de réflexion et de mise en forme — j'y reviens en fin de dépêche dans une note de transparence.
L'incident de sécurité ANTS du 15 avril 2026 a publiquement illustré le problème. J'en ai eu connaissance après avoir développé SelfRecover, ce qui m'a confirmé la pertinence d'un protocole sans dépendance à l'email. SelfRecover est publié sous AGPL-3.0-or-later sur GitHub.
Cette dépêche présente le protocole, ses choix de conception, ses limites assumées, et la comparaison avec les approches existantes (Keycloak Recovery Codes en particulier, qui m'a été suggéré en relecture). Audit communautaire bienvenu.
Sommaire
-
- Le contexte
- Le protocole en deux phrases
- Deux modes d'adoption
- SelfRecover vs Keycloak Recovery Codes
-
Que se passe-t-il si l'utilisateur perd son secret ?
- Niveau 1 — Passphrase oubliée
- Niveau 2 — Passphrase perdue, mais identifiant + mot de récupération retenus
- Niveau 3 — Accès complètement perdu
- Chat administrateur humain en mode restreint — état actuel
- Évolution prévue (en réflexion) : pré-traitement optionnel par chatbot LLM local
- Démo standalone vs implémentation de référence
- Pourquoi assumer cette friction
- Pour quel public
- Modèle de menace assumé
- Démos en ligne
- Code et image Docker
- Licence et philosophie
- Note de transparence
- Pour aller plus loin
Le contexte
Depuis l'essor du web, la réponse standard à « l'utilisateur a oublié son mot de passe » est « on lui envoie un lien de réinitialisation par email ». C'est devenu si universel qu'on oublie ce que ça implique :
- La sécurité du compte est déléguée au fournisseur de la boîte mail (Gmail, Outlook, ProtonMail). Si la boîte mail tombe, le compte aussi.
- Le canal email est régulièrement exploité par phishing : campagnes imitant des mails de réinitialisation légitimes pour capturer les mots de passe.
- Les bases de données qui stockent les emails des utilisateurs deviennent une cible massive : leur fuite expose à la fois l'identité et les vecteurs de récupération.
L'incident de sécurité ANTS illustre une autre facette du problème de gestion des données d'authentification dans les services en ligne. Détecté le 15 avril 2026 et rendu public le 20 avril, il a touché 11,7 millions de comptes selon les communiqués officiels. La cause technique identifiée est une faille d'énumération de type IDOR (Insecure Direct Object Reference) : il était possible d'accéder aux données d'un autre compte en modifiant un identifiant dans une URL. La fuite ne concerne ni les mots de passe, ni les pièces justificatives, mais les données personnelles associées aux demandes de titres.
Devant ces limites structurelles autour de l'authentification web, SelfRecover propose une inversion : conserver le secret de récupération chez l'utilisateur, et utiliser le navigateur pour faire les calculs cryptographiques nécessaires à la vérification. Le serveur ne détient plus que des dérivés, jamais les secrets bruts.
Le protocole en deux phrases
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. Côté serveur, on ne stocke que cette empreinte, en plus protégée par un hash adaptatif et memory-hard : Argon2id, qui est le standard moderne recommandé contre les attaques par brute force.
Deux propriétés découlent de cette construction :
- Le secret brut ne quitte jamais le poste de l'utilisateur.
- Un secret capturé sur un site A (par exemple via phishing) est mathématiquement inutilisable sur un site B : la dérivation HMAC produit des empreintes différentes pour des domaines différents. C'est de l'anti-phishing par construction, pas par convention.
Note conceptuelle : l'inspiration vient des machines à rotors historiques type Enigma. Le principe partagé est qu'une même configuration secrète, présente des deux côtés (émetteur et récepteur), permet de produire et vérifier un message dérivé. La cryptographie moderne (HMAC-SHA256 ici) repose sur des fondations mathématiques différentes, mais ce principe de dérivation contrôlée par un secret commun est resté.
Deux modes d'adoption
SelfRecover propose deux modes selon le contexte de déploiement.
Mode Full — Sans email
L'application abandonne entièrement le flow de réinitialisation par email. L'utilisateur génère une passphrase diceware à l'inscription (liste EFF de 7 776 mots, 4 à 7 mots par défaut), qu'il mémorise ou stocke dans son gestionnaire de mots de passe. Cette passphrase, combinée au nom de domaine du site via HMAC-SHA256, permet de réinitialiser le mot de passe sans aucune dépendance externe.
Pour qui : nouveaux projets qui veulent s'affranchir de SMTP dès la conception, ou services qui adoptent un modèle de menace post-fuite (l'email n'est plus considéré comme un canal de confiance).
Mode Lite — Avec email + mot mémorisé
L'application conserve le flow de réinitialisation par email habituel, mais y ajoute une étape supplémentaire : l'utilisateur saisit un mot mémorisé (choisi à l'inscription) qui est dérivé HMAC-SHA256 côté navigateur. Le mot brut n'est jamais transmis au serveur. La validation combine donc deux facteurs :
- La possession de la boîte mail (lien reset reçu)
- La connaissance du mot mémorisé (dérivé HMAC côté client)
Pour qui : applications existantes qui ne peuvent abandonner SMTP du jour au lendemain, mais veulent durcir progressivement leur flow de récupération. Conséquence : un email intercepté seul ne suffit plus à compromettre un compte — il faut aussi connaître le mot mémorisé.
Synthèse
| Mode | Canal email | Crypto utilisateur | Cible |
|---|---|---|---|
| Full | Aucun | Passphrase diceware EFF + HMAC | Nouveaux projets |
| Lite | Conservé | Mot mémorisé + HMAC | Applications existantes |
SelfRecover vs Keycloak Recovery Codes
Lors de la relecture de cette dépêche, devnewton a soulevé une question importante : quelle est la différence avec les Recovery Codes de Keycloak ?
Keycloak est l'IAM (Identity and Access Management) open-source de référence, maintenu par Red Hat sous licence Apache 2.0, déployé dans de nombreuses organisations depuis plus d'une décennie. Son mécanisme de Recovery Codes est un fallback d'authentification à deux facteurs : si l'utilisateur perd son téléphone TOTP, il peut saisir un code de secours préalablement généré côté serveur.
Note importante de positionnement : les Recovery Codes Keycloak adressent le cas « j'ai perdu mon 2FA mais je connais toujours mon mot de passe principal ». Le password reset principal de Keycloak utilise, lui, le canal email standard (configuration SMTP dans l'onglet Email de l'admin console).
SelfRecover s'attaque à un cas différent : « j'ai oublié mon mot de passe principal et je ne veux pas dépendre de l'email pour le récupérer ». Concrètement :
| Aspect | Keycloak Recovery Codes | SelfRecover |
|---|---|---|
| Cible | Fallback 2FA | Password recovery sans email |
| Architecture | Serveur IAM standalone (Java + BDD + admin) | Bibliothèque à intégrer dans le code de l'application |
| Source du secret | Serveur génère, utilisateur sauvegarde | Utilisateur génère/mémorise (diceware ou mot mémorisé) |
| Stockage utilisateur | Codes à sauvegarder physiquement | Passphrase mémorisable (mode Full) ou mot mémorisé (mode Lite) |
| Email reset principal | Reste nécessaire (SMTP configuré dans l'admin) | Aucun (mode Full) ou en complément (mode Lite) |
| Anti-phishing crypto | Pas spécifique au mécanisme | Dérivation HMAC par domaine : un secret capturé sur un site est mathématiquement inutilisable ailleurs |
| Licence | Apache 2.0 | AGPL-3.0-or-later |
| Maturité | 10+ ans, audité, déployé largement | Récent, audit communautaire bienvenu |
Pour la majorité des projets qui acceptent l'email comme canal de récupération, Keycloak (et son écosystème) reste le bon choix. SelfRecover s'adresse aux applications qui veulent réduire ou supprimer leur dépendance à SMTP, et qui n'ont pas besoin de la richesse d'un IAM complet (multi-realm, OIDC/SAML, fédération d'identité, etc.).
Que se passe-t-il si l'utilisateur perd son secret ?
C'est la question critique d'un protocole de récupération. SelfRecover y répond par escalade progressive sur trois niveaux, complétée par un système de litiges et un chat administrateur pour les cas extrêmes.
Niveau 1 — Passphrase oubliée
L'utilisateur saisit son username + sa passphrase diceware (match exact). Sur succès, un nouveau mot de passe est généré et affiché une seule fois. Anti-brute force : 3 tentatives par 15 minutes, 3 blocages successifs → éjection vers L2.
Niveau 2 — Passphrase perdue, mais identifiant + mot de récupération retenus
L'utilisateur saisit son identifiant public (numéro client, identifiant métier — fourni par le site) et son mot de récupération dérivé HMAC-SHA256 côté navigateur. 3 tentatives maximum avec compteur visible. Sur 3 échecs → redirection vers L3. Un litige est automatiquement créé (LIT-XXXX), tracé en base, admin notifié. Les litiges auto-résolus sont purgés après 24 heures.
Niveau 3 — Accès complètement perdu
Entrée par un lien discret « accès perdu » sur la page de connexion. L'utilisateur saisit son identifiant public en premier (anti-timing : délai forcé de 2 à 3 secondes), puis remplit un formulaire de scoring multi-facteur :
| Catégorie | Champs | Points |
|---|---|---|
| Identifiant public | 4 | 20 |
| Mot de récupération (dérivé HMAC) | 5 | 25 |
| Username | 3 | 30 |
| Passphrase (fragments) | 3 | 25 |
Bonus passifs : IP connue (+5), fingerprint connu (+5).
- Score ≥ 60/100 → compte récupéré, nouveau mot de passe généré
- Score < 60/100 après 3 tentatives → le compte passe en mode restreint : l'utilisateur n'a plus accès qu'au chat administrateur, le compte n'est ni utilisable ni écrasable tant que l'admin n'a pas validé
- Cooldown : 1 heure entre tentatives
Chat administrateur humain en mode restreint — état actuel
Dans l'implémentation actuelle (déployée en production sur ARC PVE Hub), le chat L3 est un canal direct entre l'utilisateur en mode restreint et un administrateur humain du site. Pas d'intermédiaire automatisé, pas de bot.
Le canal de chat est bidirectionnel et fonctionne en polling (pas WebSocket temps réel, pour rester simple). L'admin vérifie l'identité par l'échange et décide manuellement :
Accorder la récupération : mot de passe régénéré, compteurs réinitialisés, litige clôturé, mode restreint levé.
Refuser la récupération : ban temporaire de 24 heures, pas de nouveau litige possible pendant cette fenêtre, compteur de refus incrémenté (1/3, 2/3, 3/3). À chaque clic, l'interface admin rappelle explicitement les conséquences via une modale de confirmation (ban 24h aux refus 1 et 2, suppression définitive au 3e refus).
Au 3e refus, le compte est définitivement supprimé : décision exclusivement humaine, prise en pleine connaissance de cause par l'admin via la modale d'avertissement explicite. La suppression libère l'identifiant public pour une nouvelle inscription.
Principe de design MySelf : aucune destruction de données utilisateur n'est déclenchée sans validation humaine consciente. L'interface admin explicite systématiquement les conséquences avant chaque action irréversible. Une IA peut se tromper ou être manipulée ; lui déléguer la décision de supprimer un compte créerait une surface d'attaque.
Ce mécanisme empêche un attaquant de spammer les litiges indéfiniment : chaque refus lui coûte 24 h, et trois échecs effacent toute trace. Un propriétaire légitime bloqué par erreur peut retenter après chaque fenêtre de ban, ou se réinscrire depuis zéro si totalement verrouillé.
Évolution prévue (en réflexion) : pré-traitement optionnel par chatbot LLM local
En complément du chat admin humain (qui resterait toujours disponible), une couche de pré-traitement par un agent conversationnel local (Ollama auto-hébergé) est en cours de design. Le chatbot poserait les questions initiales de vérification d'identité et estimerait si la demande est légitime. Sur estimation positive, le mot de passe serait régénéré directement ; sur doute, l'admin humain reprendrait la main.
Cette option serait configurable par site qui déploie (activable ou non), et le chatbot ne se substituerait jamais à l'admin pour les décisions destructives (suppression de compte) — ces décisions resteraient exclusivement humaines, conformément au principe MySelf énoncé plus haut.
L'enjeu principal en cours de réflexion : calibrer le seuil de confiance du chatbot pour ne pas créer un nouveau vecteur d'attaque par social engineering (un attaquant pourrait essayer de manipuler le LLM par prompts).
Démo standalone vs implémentation de référence
La démo publique (bi-self.my-self.fr/selfrecover/) ne couvre que les niveaux L1 et L2, car L3 nécessite une interface admin, un système de disputes et un dashboard — trop pour une démo à page unique.
L'implémentation de référence en production se trouve sur ARC PVE Hub, un site communautaire de joueurs ARC RAIDERS qui sert de terrain de test à l'écosystème MySelf. L1 + L2 + L3 + mode restreint + chat admin + dispute system y sont fonctionnels.
Pourquoi assumer cette friction
Dans la vie réelle, si l'on perd sa carte bancaire, son code, sa pièce d'identité, son adresse et sa date de naissance, on ne récupère pas son compte bancaire par email. On passe en agence avec preuve d'identité.
SelfRecover applique la même logique en ligne : la sécurité réelle nécessite parfois un passage par l'humain ou un processus d'identification rigoureux. Cette friction est assumée comme un trade-off conscient, pas comme une limitation à compenser.
Pour quel public
Adapté :
- Applications avec un administrateur actif et disponible pour traiter les litiges (forum communautaire, association, e-commerce indépendant, boutique en ligne militante)
- Sites où la sécurité prime sur la fluidité de récupération (services manipulant des données sensibles)
- Communautés à taille humaine (du forum de 50 membres au service de quelques milliers d'utilisateurs)
Non adapté :
- Plateformes à très grande échelle sans admin individuel (réseaux sociaux massifs, services publics avec millions d'utilisateurs) — le volume de litiges dépasse les capacités d'un humain réactif
- Services où une friction de récupération est inacceptable (gaming compétitif, services temps-réel)
- Projets sans maintenance active (l'admin doit pouvoir répondre aux litiges dans des délais raisonnables)
Pour ces cas, un IAM mature comme Keycloak avec ses mécanismes éprouvés reste plus adapté.
Modèle de menace assumé
Pour la transparence, voici les classes d'adversaires explicitement hors périmètre du protocole :
- Compromission du poste utilisateur (logiciels malveillants, RAT, keyloggers) — un attaquant qui contrôle le poste peut capturer la passphrase à la saisie, indépendamment du protocole.
- Compromission du navigateur (extensions malveillantes, exploits 0-day) — même cause, même effet : si le moteur JS qui calcule HMAC est compromis, la sortie l'est aussi.
- Coercition physique — SelfRecover n'offre pas de plausible deniability (pas de second compte caché ou décoy).
- Cryptanalyse théorique de SHA-256 / HMAC / Argon2id — un cassage mathématique de ces primitives mettrait à mal la quasi-totalité des systèmes cryptographiques modernes, pas seulement SelfRecover.
Ces limitations sont le périmètre normal d'un protocole côté navigateur. Pour les usages à plus haute exigence (cérémonies cryptographiques sensibles, génération initiale de clé maître), MySelf-Live est annoncé dans la roadmap V0.2 : une distribution Linux Live USB minimale, RAM-only, signée GPG, qui isolerait les opérations sensibles du système hôte. Pour les usages courants à fort enjeu, Tails ou Qubes OS offrent déjà ce niveau d'isolation et sont recommandés.
Démos en ligne
- Mode Full (sans email) : https://bi-self.my-self.fr/selfrecover/
- Mode Lite (email + mot mémorisé) : https://bi-self.my-self.fr/selfrecover/lite.html
- Comparatif sécurité 8 adversaires × 3 modèles : https://bi-self.my-self.fr/selfrecover/comparison.html
Aucune inscription préalable n'est requise. Les données sont éphémères côté serveur.
Code et image Docker
- Repo : https://github.com/Pierroons/my-self/tree/main/bi-self/selfrecover
- Whitepaper FR : https://github.com/Pierroons/my-self/blob/main/bi-self/selfrecover/docs/whitepaper-fr.md
- Threat model : https://github.com/Pierroons/my-self/blob/main/bi-self/selfrecover/docs/threat-model.md
- Image Docker multi-arch (amd64 + arm64) :
docker run -p 8080:8080 ghcr.io/pierroons/selfrecover:v0.1.1
La démo de référence tourne sur PHP 8.0+ et SQLite (~600 lignes auditables, zéro dépendance externe). Tag GPG-signé v0.1.1, release datée du 5 mai 2026.
Licence et philosophie
AGPL-3.0-or-later. Toute version déployée publiquement doit publier ses modifications sous la même licence. Pas de capture SaaS possible.
SelfRecover est une brique du méta-projet MySelf, un écosystème de modules auto-hébergés qui couvre l'identité, la modération communautaire, le droit, et l'agriculture.
Un module complémentaire répond de manière directe à la problématique illustrée par l'incident ANTS : SelfDataGuard chiffre les données utilisateur côté client de telle sorte qu'une fuite de base de données ne livre que des blobs inexploitables. Le code est public, AGPL, en v0.1.0-beta — une dépêche dédiée pourra suivre quand le module aura plus de maturité (audit communautaire, retours d'intégration).
Note de transparence
Conception en partenariat avec un assistant IA
Ce protocole a été conçu et codé en partenariat avec un assistant IA (Claude), comme outil de réflexion, de revue critique, et d'écriture de code.
Pour être totalement transparent : je ne suis pas développeur de formation. Mon expérience technique vient du dev web amateur (ARC PVE Hub, un site destiné à fédérer une communauté de joueurs ; un outil de gestion de stock pour mon entreprise ; quelques sites perso). Pour SelfRecover, l'écriture des primitives cryptographiques et la mise en œuvre du protocole ont été largement assistées par l'IA, sur la base de mes choix architecturaux et de ma vision.
Ce qui vient de moi (humain) :
- La vision (souveraineté numérique, refus du SMTP comme canal de récupération)
- Les choix philosophiques (AGPL-3.0-or-later, fallback humain assumé, aucune destruction de données sans validation humaine consciente)
- Le contexte initial (besoin né en développant ARC PVE Hub)
- Chaque décision de trade-off d'architecture
- La responsabilité juridique et morale du code publié sous mon nom et signé GPG
Ce qui vient de l'IA :
- L'écriture des primitives cryptographiques (HMAC, dérivations, vérifications)
- L'agencement du code, la structure des fichiers
- La formalisation des paragraphes du whitepaper et de cette dépêche
- La génération de tests unitaires
- La vérification de cohérence interne
Plan d'audit
- Auto-audit interne : en cours et continu (chaque modification est relue critiquement)
- Audit communautaire : ouvert dès maintenant, je réponds aux remarques techniques avec sérieux (cette dépêche en est l'illustration directe)
- Audit tiers certifié : envisagé à moyen terme via un cabinet agréé CESTI ANSSI (Synacktiv, Quarkslab, Wavestone, ou équivalent), sous réserve de financement
Statut du projet
SelfRecover en est à la version 0.1.1, taguée GPG et signée. C'est un état PoC fonctionnel + déployé en production sur un site réel (ARC PVE Hub), mais pas encore mature pour une adoption massive dans des contextes à fort enjeu. La roadmap V0.2 (MySelf-Live, finalisation du chatbot L3, audit tiers) précisera ce périmètre.
Engagement communauté LinuxFr et culture du libre
Mon compte LinuxFr est récent, mais mon ancrage dans la culture du libre ne l'est pas : utilisateur exclusif de distributions Linux depuis quinze ans (principalement Debian), j'ai aidé plusieurs proches à migrer des PC anciens vers Debian pour leur donner une seconde vie au lieu de la déchèterie. J'arrive sur LinuxFr depuis le monde agricole/permaculture et le jeu vidéo (ARC PVE Hub), pas du milieu dev historique.
Je suis salarié couvreur dans une PME et installé en agriculture à temps partiel — mon temps libre pour le développement et la participation communautaire est compté. Je m'engage à répondre aux retours techniques sur cette dépêche et à suivre les disputes sur l'état du projet. Pour le reste (commentaires réguliers, dépêches futures sur d'autres modules MySelf — en particulier SelfDataGuard quand il sera plus mature), ce sera au gré du temps disponible, sans promesse.
Toute critique technique constructive est bienvenue. Pour les critiques sur la légitimité du projet ou la nature humain/IA de la collaboration, j'invite à juger sur les choix concrets, le code public, et la qualité des réponses à vos questions.
Pour aller plus loin
SelfRecover est un module de l'écosystème MySelf, expérimentation citoyenne sur la souveraineté numérique sous licence AGPL-3.0-or-later.
Les retours techniques, audits communautaires, propositions d'intégration et questions de fond sont les bienvenus — en commentaire de cette dépêche ou en issue sur le repo GitHub.
Si une administration ou une organisation souhaite tester le protocole en environnement isolé, l'image Docker et le Dockerfile sont à disposition. Aucune démarche commerciale n'est associée à cette publication.
Merci aux modérateurs et contributeurs de LinuxFr — Pierre Jarillon, devnewton, Florent Zara, bobble bubble — dont les retours pendant la phase de rédaction ont substantiellement amélioré cette dépêche.
Aller plus loin
- Démo live (64 clics)
- Code source (67 clics)
- Whitepaper FR (48 clics)
# Keycloak
Posté par Mathieu CLAUDEL (site web personnel) . Évalué à 6 (+5/-0).
Bonjour,
Les Recovery Codes dans Keycloak peuvent assez simplement permettre la réinitialisation de n’importe quel facteur d’authentification, y compris le mot de passe. Tout dépend de la manière dont on configure les flows d’authentification et/ou de self-service.
Si l’utilisateur a retenu cette passphrase, par exemple en la stockant dans son coffre-fort à mots de passe, pourquoi n’en aurait-il pas fait autant avec son mot de passe ? Du coup, le cas d’usage est-il réellement pertinent ? Ne va-t-on pas toujours tomber dans le cas où il faudra passer par le support et l’intervention d’un humain ?
C’est, je penses, d’ailleurs pour cela que les Recovery Codes sont plutôt mis en avant pour du MFA, où il est plus réaliste de perdre ou de casser son mobile qui porte un facteur.
[^] # Re: Keycloak
Posté par yabb85 . Évalué à 4 (+4/-0).
Je rebondis c'est un cas qui e je croise aussi bien en pro qu'en personnel. Soit j'ai oublié le mot de passe du gestionnaire de mot de passe (c'est plus avec mon entourage que je croise ce cas), soit j'ai perdu la pasphrase original (ça c'est vécu en pro).
Tout ça comprend les variantes suivantes:
- j'utilise chrome pour stocker mes mot de passe mais depuis le changement de pc j'ai plus accès à mon compte google.
- j'utilise keepass mais j'ai delete le fichier sans faire exprès.
- j'ai formaté le pc et j'ai tout perdu.
- je ne retrouve plus le fichier de passphrase, il doit être quelque part dans la machine.
Ça fini toujours par être là galère et je vois pas de solution contre des utilisateurs qui en ont rien à faire.
[^] # Re: Keycloak
Posté par pierroons (site web personnel) . Évalué à 1 (+4/-3).
Vous touchez le point le plus dur, et honnêtement SelfRecover ne le fait pas disparaître. Aucun système ne le peut sans réintroduire un tiers (e-mail, séquestre, support), c'est-à-dire exactement la surface d'attaque qu'on cherche à retirer.
Vos variantes ont d'ailleurs un point commun : ce sont des pertes de support. Compte Google inaccessible, fichier KeePass effacé, PC formaté, fichier de passphrase égaré, à chaque fois c'est le contenant du secret qui a disparu.
Ce que SelfRecover change, c'est qu'il ne mise pas sur un secret unique, mais sur une escalade de plusieurs filets. D'abord un mot de récupération que vous mémorisez, combiné à votre numéro de compte propre au site (num client, num ID forum etc) : il faut les deux, et il vit dans votre tête, sans fichier à perdre. Ensuite en cas d'échec, une passphrase forte générée à l'inscription, à conserver comme clé de secours. Et si tout a été perdu, un dernier recours par vérification avec un humain.
Sur ce mot (de récup), justement : il peut être tout simple, même « bob ». D'une part il ne quitte jamais votre navigateur tel quel, il est transformé en une empreinte propre au site (le serveur ne voit jamais « bob »).
D'autre part, comme un mot simple resterait devinable, on ne peut pas le marteler en ligne : quelques tentatives ratées et le compte est bloqué temporairement, puis l'échec répété fait basculer vers le niveau supérieur, jusqu'à la vérification humaine. Et de toute façon, sans votre numéro de compte en plus, le mot seul ne suffit pas.
L'idée n'est pas qu'un seul de ces éléments soit infaillible, mais qu'il faille les perdre tous en même temps pour être vraiment bloqué, sans jamais dépendre d'un e-mail ni d'un tiers à pirater.
Reste le cas où l'on a vraiment tout perdu, sans rien avoir retenu ni noté. Là, soyons honnêtes, aucun système ne fait de miracle, et SelfRecover ne prétend pas le contraire. Mais plutôt que de promettre un «lien magique » par e-mail (qui serait justement la faille), il accompagne ce cas jusqu'au dernier niveau, la vérification humaine. C'est une limite assumée, pas un angle mort caché.
En somme, SelfRecover ne supprime pas la galère ultime, mais il empile les filets au lieu de faire reposer toute la récupération sur un canal unique et fragile comme l'e-mail.
[^] # Re: Keycloak
Posté par Colin Pitrat (site web personnel) . Évalué à 4 (+2/-0).
Mais du coup, en tant qu'attaquant, si je sais que mon voisin a un fils qui s'appelle Bob et que je connais son identifiant sur un site web qu'on fréquente tous les deux, est-ce que je ne peux pas simplement tenter le coup et monter jusqu'à la phase de récupération par mot simple?
Évidemment, ça reste toujours mieux que la récupération par "question de sécurité" qui l'a toujours fait halluciner, avec des questions du genre "quel est le nom de jeune fille de votre mère ?" ou autre information extrêmement facile à trouver dans le cas d'une attaque ciblée.
[^] # Re: Keycloak
Posté par Colin Pitrat (site web personnel) . Évalué à 4 (+2/-0).
J'ajouterais que pour le dernier niveau, si j'ai réussi à faire que lon voisin se connecte depuis mon navigateur, même si il se déconnecte, je peux tenter la récupération avec son identifiant et username. Comme j'ai fingerprint et IP connues, paf j'ai 60 et je peux récupérer son mot de passe.
Ou pareil si je mets la main sur son téléphone ou son ordinateur débloqué pendant quelques minutes (mais bon on pourrait dire qu'avec l'email c'est aussi le cas)
[^] # Re: Keycloak
Posté par -mat . Évalué à 9 (+12/-4).
Faire rédiger son texte par une IA est pour moi du niveau de l'insulte publique.
On n'écrit pas entre humain pour produire du texte, mais pour communiquer.
Ça pue l'IA et c'est très désagréable à lire. Ça porte sur le lecteur la charge de la validation de ce qu'a produit l'IA.
Merci d'arrêter ça au plus vite.
[^] # Re: Keycloak
Posté par pierroons (site web personnel) . É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.
[^] # Re: Keycloak
Posté par syj . Évalué à 7 (+6/-0). Dernière modification le 31 mai 2026 à 10:39.
Le principale problème de ta proposition est le suivant.
Pour que cela fonctionne , il faut que ton recovery secret soit simple et utiliser sur plusieurs site. Sinon , c est comme un systéme a 2 mot de passe qui est forcement 2 fois moins securisé que si il n y avait qu un mot de passe.
En l occurence, Si ton serveur est corrompu:
-L attaquant peut alors recupérer les empreintes de tous tes utilisateurs. Il peut alors tenter de brute force ce "recovery secret" sans ce soucier de la limite de tentative.
-L attaquant peut corrompre la page de recuperation est recupéré le recovery secret des utilisateurs au moment de la saisie.
Une fois qu il a identifié un secret. Il peut alors le tester sur d autre serveur non compromis et gagner des accès. Bref, ce qui en fait la principale faiblesse.
Historiquement, ce type de recovery a été utilisé, on te demandait de repondre le nom de ta prof de cp, ou de ton premier chien. La recommandation des experts, c est de repondre un truc random et de ne pas utiliser ce type de recovery.
Si on voudrait améliorer l authentification actuel.
Il faudrait mettre en place une authentification par messagerie instantané crypté ou par mail crypté.
Le mail est par essence decentralisé donc cela serait un bon candidat.
Rien empeche d indiquer sa clé public a l inscription sur un site.
Avantage, l utilisateur devient connu par son email et sa clé public
# Et les utilisateurs ?
Posté par dr191 . Évalué à 5 (+4/-0). Dernière modification le 29 mai 2026 à 20:40.
J'ai plussé votre dépêche.
( Je n'ai pas les compétences techniques pour évaluer la proposition. )
Dans le cadre pro sans le choix des outils, en comprenant tout de meme les principes , je me suis fait piéger lors d'un changement de téléphone sur un site web pro nécessitant un 2FA TOTP. J'avais regardé la doc du smartphone, de l'appli TOTP , du site web, sans trouver ou comprendre une solution certaine… au final, un ticket vers le site web pour désactiver le 2FA a permis de solutionner le problème.
Comment faire utiliser un tel outil / protocole à des utilisateurs lambda ?
[^] # Re: Et les utilisateurs ?
Posté par pierroons (site web personnel) . Évalué à -1 (+2/-3).
Merci pour le plus, et surtout pour ce retour : un utilisateur qui n'évalue pas la crypto mais qui raconte son vécu, c'est exactement le public qui compte. Une sécurité qui ne tient pas pour l'utilisateur lambda ne tient pas du tout.
Votre histoire illustre parfaitement le problème. Le TOTP est lié à un appareil : on change de téléphone sans avoir anticipé le transfert, et on se retrouve coincé, à éplucher trois docs, pour finir par un ticket qui désactive carrément le 2FA. Autrement dit, la sécurité a sauté parce que la récupération était trop dure. C'est l'échec d'ergonomie typique, et il est très courant.
SelfRecover essaie justement de retirer ces points de friction pour l'utilisateur ordinaire :
Il n'y a rien à transférer ni à migrer. Le secret est un mot que vous retenez, pas une application liée à un téléphone. Votre mésaventure (le changement d'appareil) ne peut pas se reproduire, puisqu'il n'y a pas d'appareil dans la boucle).
La technique est invisible. On tape un mot, point. Tout le reste (le calcul, la liaison au site) se fait tout seul dans le navigateur : rien à comprendre ni à configurer.
Et si on se trompe, on n'est pas laissé seul devant une doc : le système oriente vers le niveau de récupération suivant, jusqu'à une vérification avec un humain en dernier recours. L'idée est qu'on ne tombe jamais dans une impasse silencieuse.
Cela dit, soyons honnêtes : faire adopter un outil de sécurité au grand public reste le vrai défi, et aucun protocole ne le règle d'un coup de baguette. SelfRecover ne supprime pas ce travail, il enlève des obstacles connus (pas d'appareil, pas d'e-mail, pas de doc à déchiffrer). Le reste se joue dans le soin apporté à l'interface et à l'accompagnement, et ça, c'est un chantier permanent.
# Hein
Posté par Sébastien B. . Évalué à 10 (+24/-3).
À la lecture du journal, j'ai eu envie de laisser le bénéfice du doute à l'auteur, mais quand je vois les commentaires, manifestement rédigés par IA (comme la dépêche je suppose, au moins avant certaines réécritures), je me dis qu'il n'y a rien à sauver et que ça ne sert à rien de prendre des pincettes.
Le projet n'a aucun intérêt, la solution quand on perd son mot de passe qu'on a choisi, c'est soit de retrouver un secret qu'on nous a donné à l'inscription, soit de donner un … mot qu'on a choisi … à l'inscription … Genre en même temps que le mot de passe. Ah et enfin, c'est "contacter le support".
Et pour ce concept complètement bancal qui ne répond à aucune solution, on a le droit à des tartines de texte pour nous expliquer tout dans le détail en rajoutant des termes techniques pour que le concept ait l'air complexe et intelligent.
À la fin, on a du code qui gère de l'authentification, une partie capitale en terme de sécurité, généré par IA, guidée par quelqu'un qui ne sait vraisemblablement pas ce qu'il fait. Intégrer ce truc (on sait même pas ce que c'est, c'est implicitement présenté comme une lib, mais ça n'en est pas une) est un danger pour n'importe quel projet.
Je ne comprends même pas le but, il y a un lien de donation, il est plutôt discret, mais plus je creuse et clique sur des liens, moins ça n'a de sens … Je ne trouve pas de présence en ligne d'une personne avec ce pseudo, plus ça va plus je pense que c'est un profil inventé de toute pièces, et que j'ai perdu beaucoup trop de temps à lire des conneries générés par IA.
[^] # Re: Hein
Posté par gled . Évalué à 10 (+12/-3).
Carrément, pour ma part je me suis arrêté au premier paragraphe qui sentait déjà bien le pâté faisandé, puis j'ai commencé à lire les quelques commentaires… Dont le seul pertinent était le tien.
Mais que vient faire ce ramassis de conneries en dépêche ?
Franchement, virez cette merde du site sans sommation, cela n’en sera que bénéfique pour la crédibilité de LinuxFr.
[^] # Re: Hein
Posté par pierroons (site web personnel) . Évalué à -2 (+4/-6).
Merci d'avoir pris le temps et d'avoir creusé la dépêche.
Je ne prétends pas réinventer la question secrète, SelfRecover c'est juste un moyen de récupération sans email, ni compte tiers pour récupérer l'accès à ton compte. Si ce n'est pas assez clair, j'apporterai des modifications pour clarifier.
Le code est trop frais en l'état pour prétendre être intégré directement, il doit encore être testé et surtout pas que par moi. Je n'écris pas de crypto, j'utilise des lib existantes. Si ce n'est pas assez clair je peux le préciser.
Tu ne trouves pas Pierroons ? Cool, je ne suis pas du milieu dev-natif, je n'ai donc pas publié sur les forums et d'une manière générale j'essaie de ne pas encombrer avec des questions déjà posées et résolues. Quant aux réseaux sociaux, j'ai jamais accroché et je reste à l'écart de ce genre de moyen de communication d'une manière générale. Je reste juste dans mon coin pour bricoler ce que je peux, comme je le peux.
[^] # Re: Hein
Posté par aiolos . Évalué à 9 (+7/-0).
Effectivement, ce ne doit pas être assez clair, parce que moi, je lis exactement l’inverse :
[^] # Re: Hein
Posté par pierroons (site web personnel) . Évalué à -2 (+3/-5).
Tu as raison, et merci de l'avoir relevé : je vais apporter des modifications rapidement pour que ce soit cohérent. À force de relire le texte dans tous les sens, j'avais zappé cette phrase.
Ce que je voulais dire : je n'ai pas réécrit les primitives. HMAC, le hachage, les vérifications, ce sont les fonctions standard de PHP (hash_hmac, password_hash/Argon2id, password_verify). Ce qui a été écrit, c'est le code qui les assemble, la dérivation par domaine, l'enchaînement, pas les primitives elles-mêmes. La dépêche disait « écriture des primitives crypto », c'est faux, ce sera reformulé en « intégration de primitives standard ».
[^] # Re: Hein
Posté par Colin Pitrat (site web personnel) . Évalué à 5 (+3/-0).
L'idée en 2 mots, si j'ai bien compris, c'est que tu as un mot de passe maître, un peu comme pour un gestionnaire de mots de passes, mais qui sert à la récupération du mot de passe. Un seul mot de passe te permet de récupérer tes comptes depuis tous les sites.
L'avantage par rapport au gestionnaire de mots de passe c'est que ça ne nécessite pas d'outil avec son stockage dédié côté client. Ni de confiance dans un tiers pour le stockage (genre Google).
Après, je ne comprends pas l'idée de deux niveaux avec différents mots de passe pour la récupération (passphease et mot simple dans le jargon de la dépêche si je le souviens bien). Ça affaiblit le protocole (deux maillons qui doivent tous les deux tenir) et du point de vue de l'utilisateur, c'est juste deux secrets à retenir…
[^] # Re: Hein
Posté par pierroons (site web personnel) . Évalué à -2 (+2/-4).
Merci, t'as parfaitement résumé l'idée, et le « pas de stockage client ni de tiers », c'est exactement le but.
Tu mets le doigt sur le bon arbitrage, et il faut séparer deux choses.
Côté sécurité, tu as raison : deux voies de récupération, c'est deux surfaces à protéger, et la résistance globale = celle de la voie la plus faible. C'est précisément pour ça que la voie « mot simple » n'est jamais utilisable seule, il faut le mot et un identifiant propre au site (non public), plus une limite de tentatives et une escalade. La voie passphrase, elle, est forte par construction. Donc oui, deux maillons, mais chacun durci, pas un maillon faible à nu.
Côté utilisateur, en revanche, pas besoin de retenir deux secrets : les voies sont alternatives (l'une ou l'autre suffit pour récupérer), donc on n'en mémorise qu'un, le « simple », l'autre étant un secours fort qu'on range dans un coffre. C'est un défaut de présentation actuel : je vais le clarifier et demander la correction dans la dépêche.
[^] # Re: Hein
Posté par dudule42 . Évalué à 8 (+7/-0).
Effectivement un très long texte alors que la base du protocole n'est pas clairement expliquée.
Une fois le calcul est "HMAC-SHA256(secret, domaine)" puis il devient "HMAC-SHA256(mot, domaine + sel)" dans une réponse sans justifier pourquoi le sel a été ajouté. L'IA a dû trouver que ça faisait bien d'ajouter du sel.
La formule de calcul du mot de récupération n'a aucun intérêt puisque le calcul n'est fait que côté client. Le serveur vérifiera juste que le secret qu'il reçoit correspond à celui que l'utilisateur a fourni à l'inscription.
Le serveur doit stocker 2 secrets au lieu d'un seul. L'utilisateur doit se souvenir de 2 secrets au lieu d'un seul.
J'aime beaucoup aussi "Le secret n'est donc pas dans le mot de passe, il est dans le moyen de le retrouver, sans e-mail ni tiers.". Le mot de passe n'est même plus secret ?
Dans le cas de récupération du niveau 3 nous avons "Identifiant public" et "Username". Les deux sont publiques et donnent déjà 50 points sur 100. À 60 points on a accès à la réinitialisation automatique.
Il manque juste les "Bonus passifs : IP connue (+5), fingerprint connu (+5)."
Donc n'importe qui, depuis le navigateur habituel de l'utilisateur (IP connu + fingerprint connu) a un total de 60 points et peut fait un reset du mot de passe.
C'est peut-être ça la vrai innovation ? :-)
[^] # Re: Hein
Posté par pierroons (site web personnel) . Évalué à -3 (+1/-4).
Sur le reset automatique au niveau 3 : tu as raison, des signaux non-secrets ne devraient pas suffire. La logique correcte, c'est que sans secret fort vérifié, la décision revient à un humain, le scoring sert alors à l'éclairer, pas à ouvrir automatiquement. C'est la correction que j'apporte.
Sur le calcul côté client : il a quand même deux intérêts, le mot brut ne quitte jamais le navigateur (une fuite serveur ne le révèle pas), et la dérivation est liée au domaine donc non réutilisable ailleurs. Mais tu as raison de dire que la dépêche introduit le sel sans l'expliquer et que la formule varie d'une section à l'autre : à clarifier, tout comme la phrase « le secret n'est pas dans le mot de passe », mal tournée. Le texte est trop long et pas assez clair sur la base, je le reprends.
[^] # Re: Hein
Posté par Krunch (courriel, site web personnel) . Évalué à 10 (+11/-1).
Je propose de changer le titre de cette dépêche pour quelque chose qui reflète mieux son contenu : « mon Tamagochi a réinventé la roue carrée »
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Hein
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8 (+6/-1).
C'est pas sympa pour les Tamagotchi dont la programmation est bien plus subtile!
# my 2 cents
Posté par passant·e . Évalué à 6 (+4/-0).
Les seuils de scoring semblent tout à fait arbitraire. Il faudrait une étude expliquant pourquoi ces valeurs sont retenues. Comme expliqué par une autre personne on atteint "facilement" les 60 en creusant un peu.
Le cooldown est par IP ? par compte utilisateur?
Aucune mention sur la sécurité du compte admin. Hors, si le vol de compte utilisateur est compliqué, l'attaquant peut se concentrer sur le compte admin qui peut valider n'importe quel demande de récupération de compte.
DoS théorique
Fausse tentative sur le compte admin pour bloquer son compte + fausse tentative sur les comptes utilisateurs pour les faire passer en mode restreint = service bloqué.
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: my 2 cents
Posté par pierroons (site web personnel) . Évalué à -4 (+1/-5).
Merci, c'est le genre de retour qui fait avancer le projet, des vraies questions.
Sur le scoring : les valeurs ont été calibrées empiriquement pour le premier déploiement réel du protocole, un service à faible enjeu, et elles sont prévues pour être configurables selon l'enjeu, c'est typiquement le genre de seuils qui doivent s'adapter au contexte, pas des constantes universelles. Ce qui ne dispense pas de revoir le poids relatif : tu as raison qu'un identifiant semi-public ne devrait pas peser autant qu'un secret.
Pour le reste, cooldown par IP ou par compte, sécurité du compte admin (qui relève en partie d'une autre brique, la sécurisation du serveur), et le DoS via le mécanisme de blocage, ce sont de vraies questions auxquelles je préfère répondre code en main plutôt qu'à chaud. Je reprends ça proprement et je reviens avec des réponses précises, en corrigeant ce qui doit l'être.
# L'aspect standardisation est intéressant
Posté par cg . É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 :
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 ?[^] # Re: L'aspect standardisation est intéressant
Posté par pierroons (site web personnel) . É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.
[^] # Re: L'aspect standardisation est intéressant
Posté par cg . Évalué à 6 (+4/-0).
Ben si, c'est pareil. Si je détermine que sur
plop.frta phrase de passe de récup est "tartine de pain sans gluten grillée", et que tu réutilises la même surcoin.com, ben je vais pouvoir t'usurper ton compte sur les deux sites, vu que le domaine est connu. Le fait que le condensat soit complexe à casser ne règle pas la question de la réutilisation d'un mot de passe, qu'il soit fort ou faible.Où alors il me manque un ingrédient ?
# passkey ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4 (+1/-0).
Ton mecanisme ressemble a une passkey, une clef de securité. En gros, une clef ssh local qui identifie ton navigateur a coup sur. C'est souvent stoquer dans un "vault", il faut donc un mot de passe perso pour l ouvrir.
"La première sécurité est la liberté"
[^] # Re: passkey ?
Posté par cg . Évalué à 4 (+2/-0).
Bof : les passkeys sont construites sur des algos de clés asymétriques, ici c'est un bête secret partagé ("pre shared key") avec le nom de domaine pour le salage. C'est du niveau de
/etc/shadowen fait.# IA... pour animer linuxfr ?
Posté par farfade . Évalué à 5 (+8/-3).
Le projet, c'est pas le mécanisme de récup, c'est de voir si une IA peut animer linuxfr ?
J'ai trouvé ?
[^] # Re: IA... pour animer linuxfr ?
Posté par orfenor . Évalué à 0 (+3/-5).
Effectivement, pour animer linuxfr il y a un truc qui marche : écrire des dépêches, la sienne est restée longtemps en rédaction, il y a eu du boulot humain et des remarques prises en compte. Quand à l'outil il y a de la réflexion et du travail humain, en plus il est déployé. Il ne s'agit pas d'un vague truc généré par IA et balancé ici comme ça.
Qu'il utilise l'IA comme assistante pour aider là où il ne connait pas, c'est peu criticable pour obtenir une preuve de concept. En plus dans la vraie vie d'un adulte, il a deux boulots, une asso, une famille et donc peu de temps de reste.
Bref, tu as du lire un peu vite, relis posément la dépêche, va voir son outil et donne des conseils pour améliorer, ça animera.
[^] # Re: IA... pour animer linuxfr ?
Posté par Ysabeau 🧶 (courriel, site web personnel, Mastodon) . Évalué à 7 (+4/-0).
L'auteur n'est jamais intervenu dans le tribune de rédaction de la dépêche comme d'autres pour signaler qu'il a ou pas pris en compte les suggestions. Je suis dubitative.
Je n’ai aucun avis sur systemd
[^] # Re: IA... pour animer linuxfr ?
Posté par orfenor . Évalué à 2 (+0/-0).
Tout un paragraphe découle d'une remurque de devnewton :
"SelfRecover vs Keycloak Recovery Codes"
[^] # Re: IA... pour animer linuxfr ?
Posté par BAud (site web personnel) . Évalué à 1 (+0/-1).
écrit comment ? car cela avait été prévu/pris en compte dans le dév' initial ? (avec une vraie étude de l'existant…)
[^] # Re: IA... pour animer linuxfr ?
Posté par Voltairine 🏳️🌈 . Évalué à 5 (+3/-0).
Il y a effectivement un humain derrière tout ceci. C'est facile à vérifier.
Le problème c'est que toutes ses interventions dans le fil de discussion et modifications dans la dépêche en cours de rédaction sont générés par IA. Pour moi cela revient à discute avec un robot.
Sur le plan technique cela ne me semble avoir peu d’intérêt et contenir quelques erreurs conceptuelles. Je doute que l'outil soit réellement déployé et utilisé en production. Cela reste un truc généré par IA, c'est clairement indiqué sur GitHub, et balancé ici en espérant un accueil favorable.
Il y a aussi sûrement une certaine lassitude vis à vis ce type de contenus envoyés en dépêches…
Je laisse imaginer à l'auteur un traité de méthode de culture du chanvre généré par IA balancé sur un forum de passionnés par cette production; et où l'auteur déléguerait toute réponse aux critiques et remarques à une IA. Ce ne serait pas forcément bien reçu…
[^] # Re: IA... pour animer linuxfr ?
Posté par farfade . Évalué à 1 (+1/-0). Dernière modification le 01 juin 2026 à 20:56.
Quand vous dites c'est facile à vérifier, c'est que vous le connaissez en vrai ?
Je me disais que je trouverais ça instructif de dire à une IA de s'inventer une vie et un projet informatique et de venir le poster sur linuxfr, en prenant soin de faire l'humain, sans répondre trop vite, en posant des questions, exprimant des doutes, etc
[^] # Re: IA... pour animer linuxfr ?
Posté par BAud (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 01 juin 2026 à 21:07.
ô_O ?! /o\
[^] # Re: IA... pour animer linuxfr ?
Posté par farfade . Évalué à -1 (+0/-1).
Oui, instructif !
Une IA peut créer un protocole et mettre en place un site qui l'implémente, alors pourquoi pas animer une discussion sur un forum et faire vivre le projet.
C'est juste déplacer ce que fait l'IA un cran au-dessus dans l'échelle de la génération supervisée finalement.
Lire ce thread au style IA assumé m'a fait penser à MJ Rathbun en meilleur.
Pierroons est probablement agriculteur en Creuse, mais un informaticien, ou un sociologue, qui superviserait un agent IA à qui on demanderait d'être agriculteur en Creuse et informaticien amateur pourrait créer à peu près le même écosystème - et ce serait une expérience instructive à mon sens.
[^] # Re: IA... pour animer linuxfr ?
Posté par BAud (site web personnel) . Évalué à 2 (+0/-0).
je te recommande de regarder la gestion d'un café par une IA, financée par une startup.
je te laisse bien sûr retrouver la référence, tente de demander à ton IA préférée ce qu'elle en pense :p
[^] # Re: IA... pour animer linuxfr ?
Posté par Sébastien B. . Évalué à 7 (+5/-0).
Peut être que certaines personnes sur ce site ne veulent pas être les cobayes d'une expérience sociale chelou qui leur faire perdre leur temps ?
[^] # Re: IA... pour animer linuxfr ?
Posté par Voltairine 🏳️🌈 . Évalué à 4 (+2/-0).
Absolument pas. Il suffit d'utiliser les liens donnés dans la dépêche pour identifier la personne qui est derrière en deux minutes.
# Oui, mais…
Posté par -mat . Évalué à 4 (+4/-1).
Peux-tu me donner une recette de banana-bread ?
[^] # Re: Oui, mais…
Posté par Amiralgaby . Évalué à -7 (+0/-8).
Absolument 😁👍🏻
https://liliebakery.fr/banana-bread-recette/
On est sur Linux FR, on sait tous que l'IA est tellement développée qu'elle est utile dans le domaine de la génération textuelle. Je comprends qu'on aime pas quand c'est IA parce qu'actuellement ça fait pas sérieux, les mœurs changeront au fur et à mesure car elle proposera de plus en plus des réponses pertinentes.
Amiralgaby#1847
[^] # Re: Oui, mais…
Posté par Ysabeau 🧶 (courriel, site web personnel, Mastodon) . Évalué à 10 (+7/-0).
En nous laissant les corvées de latrine. C'est bien l'un des problèmes, en plus d'un coût environnemental qu'on n'a pas les moyens de payer.
Je n’ai aucun avis sur systemd
[^] # Re: Oui, mais…
Posté par Philippe F (site web personnel) . Évalué à 10 (+8/-0).
Ou plutôt, les mœurs changeront quand les gens se rendront compte que lire de la prose générée par IA est mortellement ennuyant. Son ton didactique donne l'impression qu'elle parle à un débile en face d'elle. Son exhaustivité est fatigante. Et surtout, la discussion avec une IA ne présente aucun intérêt humain. Elle n'a pas sa place dans un forum de discussion comme linuxfr.
Du coup, les gens vont se rendre compte de l'inutilité de la chose et arrêter. A la place, ils vont se mettre à utiliser leur cerveau et découvrir le plaisir de la recherche, de la conversation, de l'argumentation.
On peut rêver ….
# Une solution en recherche de problème?
Posté par xryl669 . É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:
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.