Ouvrez un « générateur de mot de passe en ligne », cliquez sur Générer, puis l’onglet Réseau des outils de développement — si le corps de la requête ou les paramètres affichent le mot de passe que vous venez d’obtenir, le texte en clair a déjà quitté votre appareil. Cette vérification n’exige aucune confiance dans une marque : le navigateur étale le trafic.
Garder le calcul dans le navigateur n’est pas un slogan « décentralisé ». Il s’agit de réduire la fenêtre de texte en clair à votre machine : une couche de transport en moins, un journal serveur en moins, une occasion de moins pour qu’une dump mémoire soit lue par erreur. Ci-dessous : modèle de menaces, étapes vérifiables, et limites. La pile PassAfer est bâtie sur ce principe ; cet article ne fait pas le tour du produit — il répond à une seule question : pourquoi le calcul sensible ne devrait pas, par défaut, être délégué à un serveur.
Ce que le calcul côté serveur élargit
La fenêtre de texte en clair, c’est l’ensemble des endroits où le clair (ou une clé qui le reconstitue) existe vraiment. Quand un serveur calcule à votre place, cette fenêtre n’est pas « le clic sur Envoyer » : c’est une chaîne difficile à effacer après coup.
- La session TLS jusqu’à l’origine — le processus serveur voit la requête déjà déchiffrée, pas du chiffré.
- Les échantillons de corps de requête dans reverse proxy, WAF, APM, suivi d’erreurs ; une 500 peut coller un formulaire dans un rapport de crash.
- Journaux applicatifs, requêtes lentes, query string des access logs ; mettre une clé dans
?key=, c’est l’écrire dans l’access log. - Fichiers intermédiaires sur base, object storage ou disque temporaire, plus les sauvegardes et réplicas.
- Le temps pendant lequel ops, support ou un attaquant tiennent l’une de ces copies — la fenêtre a déjà existé ; « on supprime après usage » n’y change rien.
Juridiction et sous-traitance transforment « nous ne regardons pas » en phrase peu auditable. Vous pouvez vérifier le protocole et le trafic, pas le règlement interne d’une salle machines.
Pour un générateur de mot de passe, c’est particulièrement net : vous voulez un secret qui n’a encore existé nulle part. S’il naît dans la salle machines de quelqu’un d’autre, la première copie n’est pas chez vous. Ensuite vous le collez dans une config de prod, une variable CI ou un gestionnaire — la source de fuite compte déjà un nœud que vous ne voyez pas.
Pour un audit de mot de passe, c’est la même logique : envoyer un mot de passe habituel à un service distant « pour tester la force », c’est confier votre réemploi le plus sensible à un tiers. Les requêtes sur des bases de fuites publiques peuvent s’appuyer sur des protocoles type k-anonymity ; Password Audit de PassAfer choisit une contrainte plus dure — le mot de passe testé n’est pas envoyé ; estimation de force et comparaison à une liste Top de fuites se font dans le navigateur. Ce qu’il faut vérifier n’est pas « ils disent ne pas stocker », c’est l’absence de cette chaîne dans la requête.
Pour le chiffrement de fichiers, un flux « envoi → chiffrement serveur → téléchargement » fait apparaître phrase secrète et contenu au moins en mémoire côté serveur. Un chiffrement en flux local ne laisse rien de lisible à réception : le serveur n’a même pas besoin de savoir s’il s’agit d’une photo ou d’une image disque.
HTTPS n’est pas du calcul local
TLS protège contre l’écoute sur le chemin, pas contre le serveur d’en face. Si c’est lui qui calcule, il doit lire le clair. Le calcul local vise autre chose : l’autre bout ne devrait jamais voir ce matériau.
Ce que « local » désigne vraiment
« Local » se dilue vite en slogan. Il faut le découper, sinon un cloud « visible par vous seul » passe pour du chiffrement local.
Un processus sur votre machine, pas « dans un compte cloud »
Chez PassAfer, local signifie : le calcul a lieu dans l’onglet. Les aléas viennent de crypto.getRandomValues, le chiffrement symétrique de l’API Web Crypto. Le matériau de clé vit dans des objets CryptoKey à courte durée de vie, et n’est pas envoyé comme champ d’analyse. Vous pouvez copier, exporter ou télécharger le résultat ; une fois la page fermée, le clair en mémoire suit le cycle de vie du navigateur — il ne reste pas une copie distante.
Ce n’est pas « jeter un fichier dans un drive privé ». Le serveur du drive lit en général l’objet en clair, sauf si vous l’avez déjà scellé sur votre machine. La question local-first est : le clair a-t-il existé sous une forme utilisable hors de votre appareil ?
Algorithme et plafond fichier : des faits vérifiables
En première version, le chiffrement symétrique est uniquement AES-256-GCM (chiffrement authentifié : si le chiffré est altéré, le déchiffrement échoue). La boîte fichiers traite un fichier en flux, plafond 5 Go, sortie .lock (préférée) ou .enc, pour ne pas charger une vidéo entière en mémoire. Ces chiffres sont dans le cahier des charges, pas des adjectifs marketing ; si une page propose un algorithme non livré, c’est la doc produit qui fait foi.
Local n’implique pas « tout ouvert aux visiteurs »
Lieu de calcul et droits de connexion sont deux sujets. Un visiteur non connecté peut générer, copier et exporter des caractères aléatoires et des phrases de passe ; l’audit de mot de passe, les outils de confidentialité, la création de Burn-Link, la boîte fichiers et le coffre se débloquent après connexion. Lire « local » comme « tout le monde a tous les outils » contredit la matrice de droits.
| Capacité | Sans compte | Matériau sensible envoyé par défaut ? |
|---|---|---|
| Génération aléatoire / phrase de passe | Disponible | Non envoyé ; généré dans le navigateur |
| Ajouter au coffre | Invitation à se connecter | — |
| Audit de mot de passe | Invitation à se connecter | Mot de passe testé non envoyé ; force + liste de fuites en local |
| Clean Link / masquage | Invitation à se connecter | URL et texte traités en local ; pas d’analytics sur le contenu |
| Création de Burn-Link | Invitation à se connecter | On envoie un blob chiffré, pas l’original |
| Lecture de Burn-Link | Ouverte au destinataire | Clé dans le fragment # de l’URL, non envoyée avec la requête HTTP |
| Boîte de chiffrement de fichiers | Invitation à se connecter | Fichier et phrase secrète non envoyés ; AES-256-GCM en flux sur la machine |
Burn-Link est le seul chemin qui a besoin d’un stockage temporaire côté serveur — mais ce qui est stocké est du chiffré. La clé de déchiffrement est dans le segment # : le fragment ne part pas avec la requête HTTP ; l’access log ne voit en général que le chemin. La page de lecture est ouverte au destinataire — sinon il devrait d’abord s’inscrire, et le partage ponctuel tombe. Après la première lecture, le chiffré est détruit par conception. Connaissance nulle côté serveur ne veut pas dire « on ne stocke rien », mais « même stocké, on ne peut pas déchiffrer ». Ici, il suffit d’ancrer cette convention.
Vérifier dans l’onglet Réseau qu’aucun secret n’est envoyé
Un slogan ne se prouve pas tout seul. Voici une procédure qui ne repose pas sur la confiance, avec les outils déjà dans le navigateur. L’objectif n’est pas de démontrer « aucun canal latéral nulle part », c’est de démasquer l’outil en ligne qui POST le clair au premier clic.
Commencez par le générateur, sans compte. Ouvrez la page de génération, restez déconnecté. Caractères aléatoires et phrases de passe doivent se générer tout de suite. Vous séparez ainsi « compte » et « la génération envoie-t-elle quelque chose », pour ne pas prendre une requête de connexion pour un envoi de mot de passe.
Ouvrez Réseau, cochez Conserver le journal. Chrome, Edge ou Firefox. Filtrez d’abord Fetch/XHR, puis parcourez toutes les requêtes. Conserver le journal évite qu’une navigation n’efface l’historique. Les requêtes sendBeacon et celles d’un Service Worker apparaissent aussi dans le panneau.
Générez une chaîne facile à reconnaître. Allongez un peu, copiez-la dans un bloc-notes. Dans la recherche Réseau, collez cette chaîne, ou un sous-ensemble qui n’a aucune raison d’apparaître dans le JS source.
Regardez URL, query et payload. Si aucune requête ne contient ce sous-ensemble, au moins pour ce clic « Générer », le clair n’est pas parti en HTTP. Une chaîne sans rapport dans un script statique ne compte pas ; vous cherchez celle que vous venez de créer.
Même méthode une fois connecté. Audit, confidentialité et boîte fichiers exigent une connexion. Ensuite, retestez avec un faux mot de passe ou un petit fichier. L’audit ne doit pas envoyer le mot de passe testé ; le nettoyage ne doit pas POST l’original ; la boîte ne doit pas uploader le clair en multipart.
Pour Burn-Link, regardez le chiffré et le fragment. À la création (connexion requise), ce qui part vers le serveur doit être du chiffré, pas le texte saisi. Dans le lien complet, la clé est après # ; retirez le fragment et regardez Réseau : le chemin de requête ne doit pas contenir la clé. Le destinataire ouvre la page de lecture sans compte.
Ce que cette étape prouve — et ce qu’elle ne prouve pas
Réseau montre si cette opération a mis du clair dans HTTP. Il ne voit pas un script same-origin qui lit la mémoire, une extension malveillante, ou une page déjà XSS. C’est largement suffisant pour démonter beaucoup d’« outils en ligne » ; ce n’est pas une preuve formelle.
Ce qui doit rester local, et les exceptions à nommer
Doivent rester sur la machine les matériaux irrévocables une fois partis : un mot de passe tout neuf, un ancien mot de passe à tester, un texte à masquer, le clair d’un fichier, une clé symétrique. S’ils entrent dans le journal de quelqu’un d’autre, fermer la page ne supprime pas sa copie.
Peuvent quitter l’appareil seulement ce qui est inutilisable en cryptographie pour le serveur, ou ce qui appartient au compte. Par exemple le blob chiffré d’un Burn-Link, le nom d’utilisateur et le mot de passe de connexion, et les ressources statiques sans secret. Ne mélangez pas « se connecter » et « envoyer le clair de l’outil » : la connexion est un palier de droits — sans compte, vous générez déjà un mot de passe ; audit, nettoyage, création de Burn-Link, boîte fichiers et coffre se débloquent ensuite. Les identifiants de compte ne sont pas le mot de passe que vous venez de générer.
La sortie de la boîte fichiers, c’est le .lock / .enc téléchargé sur le disque. Ensuite, drive, clé USB ou e-mail transportent du chiffré. Si vous posez ce fichier sur un drive, ce drive ne voit toujours pas la phrase secrète ni l’original — à condition que la phrase n’ait pas voyagé en clair dans le même envoi. Le chiffrement local change « l’admin du drive ouvre vos photos par défaut », pas la responsabilité physique de conservation.
Les outils de confidentialité (Clean Link et Data Redaction) gardent aussi URL et texte dans le navigateur : retrait des UTM / paramètres pub, masquage de téléphones et de pièces d’identité, résultat à relire avant envoi. L’original n’est pas transmis, ni collé dans un événement analytics. Si le nettoyage POST le ticket entier pour renvoyer une version « masquée », la fenêtre de clair s’est déjà ouverte côté serveur : le masquage n’est plus qu’une couche d’affichage.
Limites et malentendus du chiffrement dans le navigateur
Le local-first réduit l’exposition serveur et réseau, pas un PC déjà contrôlé par un malware. Écrire la limite dans l’attente vaut mieux que coller AES en pied de page.
Si la page est injectée, l’algorithme n’y peut rien
Un XSS ou un script détourné peut lire les champs. Web Crypto protège les opérations de clé dans une page honnête, pas une page déjà compromise same-origin. On s’appuie sur same-origin, CSP et l’intégrité de la chaîne front. Voir « AES-256-GCM » ne permet pas de conclure « donc le XSS est inefficace ».
Extensions, proxy d’entreprise, regard par-dessus l’épaule
Une extension et un proxy SSL d’entreprise peuvent encore voir le contenu de la page. Avec un certificat racine injecté par l’entreprise, l’onglet Réseau montre le monde après le proxy. Vol d’appareil, partage d’écran, regard par-dessus l’épaule : le calcul local n’y répond pas. Ce sont des questions de poste, distinctes de « le serveur ne doit pas détenir le clair ».
« Non transmis » n’est pas « hors ligne »
La page, les scripts et la requête de connexion partent quand même. On vérifie si des champs sensibles apparaissent dans les requêtes, on ne débranche pas le câble. PassAfer ne reporte pas non plus mot de passe testé, texte à masquer ou contenu de fichier comme événement d’analyse — l’événement ne doit pas contenir le secret lui-même.
Ne pas écrire les capacités trop large
L’algorithme de première version, c’est AES-256-GCM ; n’attendez pas un sélecteur RSA ou des options nationales non livrées. N’écrivez pas la page de lecture Burn-Link comme exigeant une connexion. Ne prétendez pas que le serveur voit aussi le clair ou la clé — c’est le contraire du produit. La formulation honnête du local-first : le calcul sensible se fait dans le navigateur ; texte en clair, clés et fichiers ne sont pas envoyés par défaut ; pour Burn-Link, le serveur ne conserve temporairement que du chiffré.
Par où commencer si vous voulez vérifier vous-même
Si vous voulez d’abord confirmer que « ce clic Générer n’envoie rien », le générateur de mot de passe est le bon point d’entrée : pas de compte, caractères aléatoires et phrases de passe se font sur la machine, copie et export aussi. Ouvrez Réseau, cherchez la chaîne que vous venez d’obtenir. C’est le coût le plus bas, et le plus clair pour se faire une intuition de « fenêtre de clair ».
Les alternatives courantes ont des limites précises. Un e-mail en clair et une messagerie instantanée laissent la clé dans l’historique des deux côtés, les archives serveur et les sauvegardes d’appareil ; un drive est lisible par défaut côté serveur, sauf chiffrement préalable sur la machine ; une clé dans les paramètres de requête finit presque toujours dans l’access log. Ce n’est pas « moins pratique » : la fenêtre de clair est dans le design.
Pour sauvegarder un fichier qui ne devrait pas aller tel quel sur un drive, connectez-vous et utilisez la boîte de chiffrement de fichiers : AES-256-GCM en flux dans le navigateur, un fichier jusqu’à 5 Go, téléchargement .lock ou .enc. Capturez le trafic du chiffrement pour confirmer que le fichier d’origine n’est pas POST. Pour envoyer une fois un court secret à un collègue, sans que la clé apparaisse dans les journaux serveur, utilisez ensuite Burn-Link : chiffrement local, clé dans le segment #, le serveur ne touche que du chiffré, le destinataire n’a pas besoin de compte. Celui-ci demande seulement de pouvoir répondre : après ce clic, le clair est-il encore dans votre onglet ?
Le slogan PassAfer est « Chiffrement local, sécurité partout ». La condition du « partout », c’est que le calcul a lieu dans l’onglet que vous regardez, et que vous pouvez le vérifier avec le panneau déjà dans le navigateur.