Outils de sécurité : zéro connaissance

Pourquoi les outils de sécurité devraient être zéro connaissance

Les développeurs manipulent des secrets toute la journée : clés API, JWT, fichiers de configuration, données clients dans les fixtures de test. Dès que vous en collez un dans un outil web quelconque, il est sur le serveur de ce site.

La réponse classique – installer un outil CLI – a ses propres coûts : binaires spécifiques à la plateforme, risque de chaîne d'approvisionnement des paquets et friction qui fait retomber les gens dans des raccourcis non sécurisés.

Les outils web zéro connaissance comblent l'écart : ils s'exécutent dans votre navigateur avec l'API Web Crypto, gardent les données sur votre appareil et fonctionnent partout sans installation. L'exigence de confiance est simplement « la page est ce qu'elle prétend être » – ce qu'une construction reproductible, un site statique et une CSP stricte rendent vérifiable.

Ce guide cartographie la boîte à outils : ce que fait chaque catégorie, les algorithmes impliqués et les pièges à éviter.

Hachage : empreintes pour les données

Un hash cryptographique est une empreinte à sens unique : la même entrée produit toujours le même résumé, et changer un bit change tout le résumé. Le hachage n'est pas du chiffrement – rien n'est récupérable depuis un hash.

Utilisez les hash pour vérifier l'intégrité des fichiers (téléchargements, sauvegardes), pour comparer des données sans les stocker (vérification de mots de passe à l'ancienne, déduplication) et pour empreinter du contenu.

Pour l'intégrité, SHA-256 est la norme. Pour les mots de passe, n'utilisez jamais SHA brut – utilisez un hachage lent et salé comme Argon2id, scrypt ou bcrypt, conçus pour résister à la force brute.

Un outil de hachage navigateur est idéal ici : hachez un fichier localement, comparez les sommes et n'envoyez jamais le fichier – ce qui compte quand le fichier lui-même est confidentiel.

Chiffrement : confidentialité avec une clé

Le chiffrement transforme des données en texte chiffré que seuls les détenteurs de clé peuvent lire. Le défaut moderne est le chiffrement authentifié : AES-256-GCM, qui garantit à la fois confidentialité et intégrité.

Le chiffrement navigateur est pratique aujourd'hui car Web Crypto fournit nativement AES-GCM, RSA-OAEP, ECDH et PBKDF2. Un flux basé sur phrase de passe dérive la clé localement et ne l'envoie jamais.

Utilisez le chiffrement côté client pour : les fichiers et textes qui ne doivent pas atteindre un serveur, le partage de secrets hors bande et la construction de fonctionnalités zéro connaissance dans vos propres produits.

Encodage : représentation, pas sécurité

Base64, Base64URL, Hex et l'encodage URL changent la représentation des données. Ils n'offrent aucune confidentialité – n'importe qui peut les décoder – mais ils sont essentiels pour faire transiter des données binaires par des canaux texte.

La distinction qui compte pour les développeurs : Base64URL (la variante utilisée par JWT) remplace + et / par - et _, donc les valeurs encodées survivent aux URL et noms de fichiers. Choisir la mauvaise variante est un bug d'intégration classique.

Un encodeur local est pratique pour décoder un payload d'une ligne de journal ou d'un fichier de configuration sans le coller dans un service que vous ne contrôlez pas.

Débogage JWT : lisez avant de faire confiance

Les JWT apparaissent constamment dans les journaux, en-têtes et configurations. Un JWT est trois segments Base64URL – en-tête, payload, signature – et les deux premiers sont trivialement lisibles par n'importe qui, y compris le serveur dans lequel vous les collez.

Un décodeur JWT côté client vous montre les claims – exp, iat, nbf, iss, aud – sans envoyer le jeton. Cela compte car un jeton est un identifiant de type bearer dans de nombreux systèmes.

Rappelez-vous la règle : décoder n'est pas vérifier. Décoder lit les claims ; la vérification exige la clé publique de l'émetteur et contrôle la signature et tous les claims standard. Gardez les deux séparés dans votre modèle mental et dans votre code.

Génération : l'aléa fait correctement

Les mots de passe, UUID, secrets HMAC et QR codes ont tous besoin d'une source d'aléa ou d'un encodage standard. Le navigateur fournit crypto.getRandomValues pour l'aléa sécurisé, et la génération UUID v4/v7 est normalisée.

Un générateur local évite deux modes de défaillance : l'aléa fait main faible (Math.random n'est pas acceptable pour les secrets) et les générateurs tiers qui journalisent ce que vous générez.

Pour les mots de passe, générez avec l'entropie en tête – la longueur bat le théâtre de la complexité. Pour les identifiants, choisissez v4 pour l'impossibilité de deviner ou v7 pour les clés triables, et connaissez le compromis.

Comment vérifier un outil zéro connaissance

• Ouvrez le panneau réseau du navigateur et confirmez qu'aucune requête ne porte vos données – idéalement, aucune requête sortante n'a lieu quand vous utilisez l'outil
• Déconnectez-vous du réseau et confirmez que l'outil fonctionne toujours – le code côté client continue de fonctionner hors ligne
• Privilégiez les outils côté client, statiques et reproductibles plutôt qu'une boîte noire
• Consultez la page du modèle de sécurité pour une déclaration honnête de ce qui est et n'est pas protégé
• Vérifiez que la page est servie en HTTPS et depuis le domaine que vous avez l'intention d'utiliser

FAQ

Références

• API W3C Web Cryptography : https://www.w3.org/TR/WebCryptoAPI/
• NIST FIPS 180-4 – Secure Hash Standard : https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
• RFC 7519 – JSON Web Token (JWT) : https://www.rfc-editor.org/rfc/rfc7519
• Aide-mémoire OWASP sur le stockage cryptographique : https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html