Vos données sont chiffrées sur votre appareil avant d'atteindre nos serveurs. On n'a aucune connaissance de votre mot de passe, de vos clés de chiffrement ni de vos informations personnelles. Même nous, on ne peut pas déchiffrer vos données.
Le chiffrement à connaissance nulle, ça veut dire qu'on a littéralement aucune connaissance de votre mot de passe, de vos clés de chiffrement ou de vos données déchiffrées. Tout est chiffré côté client avant d'atteindre nos serveurs.
Au lieu d'envoyer votre mot de passe, vous utilisez des signatures cryptographiques pour prouver que vous le connaissez sans le révéler. Imaginez que vous prouvez avoir une clé sans la montrer.
Le mot de passe reste toujours sur votre appareil
Données chiffrées côté client avant le téléversement
Même nous, on ne peut pas accéder à vos données chiffrées
Une fuite des serveurs ne peut pas exposer vos informations
Ce qu'on peut voir et ce qu'on ne peut pas voir
Votre mot de passe (en clair ou chiffré)
Vos clés de chiffrement
Vos informations d'identité (noms, dates de naissance, adresses)
Vos justificatifs (cartes de crédit, pièces d'identité, permis)
Aucune donnée déchiffrée : tout est chiffré côté client
Un processus cryptographique qui prouve votre identité sans révéler votre mot de passe
Le client demande votre sel unique (octets aléatoires) nécessaire pour dériver les clés de chiffrement à partir de votre mot de passe.
Votre appareil dérive une clé de chiffrement principale à partir de votre mot de passe à l'aide d'Argon2id, une fonction de dérivation à coût mémoire (64 Mio de mémoire de travail, 3 itérations). Le coût mémoire est ce qui bloque les attaques par GPU et ASIC : forcer un seul mot de passe demande des gigaoctets de RAM par tentative, pas seulement des cycles CPU.
Votre appareil crée une preuve cryptographique avec HMAC-SHA256 et votre clé dérivée. Cette preuve ne peut être générée que par quelqu'un qui connaît votre mot de passe.
Le serveur compare le hachage de votre preuve au hachage stocké à l'inscription. S'ils correspondent, l'authentification réussit, sans voir votre mot de passe.
Les cookies de session sont stockés sous forme de cookies HttpOnly, ce qui bloque l'accès JavaScript et les attaques XSS.
L'authentification traditionnelle envoie votre mot de passe (chiffré en transit) au serveur, qui le vérifie. Si le serveur est compromis pendant la transmission ou le stockage, les mots de passe sont à risque. Avec la connaissance nulle, votre mot de passe ne voyage jamais nulle part. Un attaquant qui intercepte le trafic réseau ou compromet nos serveurs n'obtient rien d'utile : seulement des hachages de preuves cryptographiques qui ne peuvent pas être inversés pour révéler votre mot de passe.
Argon2id avec 64 Mio de coût mémoire et 3 itérations
Sel unique de 32 octets par utilisateur
Clés séparées pour l'authentification et le chiffrement
La conception à coût mémoire défait les attaques par GPU et ASIC
Génération de preuve cryptographique HMAC-SHA256
Vérification de preuve à connaissance nulle
Stockage de preuve hachée SHA-256
Protection contre les attaques temporelles
Chiffrement authentifié AES-256-GCM
Chiffrement côté client uniquement
Aucune connaissance du texte clair côté serveur
IV unique par opération
Votre mot de passe dérive une clé principale (Argon2id)
La clé principale enveloppe une clé de coffre distincte, propre à votre compte
Toutes vos données sont chiffrées avec la clé de coffre, pas la clé principale
Un changement de mot de passe ne fait que ré-envelopper la clé de coffre, sans rechiffrer vos données
SMS, MMS, appels et messagerie vocale entrants utilisent l'agrément de clé X25519 sur courbe elliptique
Chaque message génère une nouvelle paire de clés éphémère côté expéditeur
La clé privée éphémère est effacée immédiatement après le scellement
Compromettre votre clé privée demain ne déchiffre pas les messages d'hier
Comment on empêche le détournement de session et les attaques XSS
Plusieurs mécanismes de sécurité travaillent ensemble pour protéger votre session authentifiée :
Cookies HttpOnly
Les cookies de session stockés dans des cookies HttpOnly ne sont pas accessibles à JavaScript, ce qui bloque le vol par XSS
Politique SameSite
SameSite=Lax empêche l'envoi des cookies dans les requêtes intersites, ce qui bloque les attaques CSRF
Indicateur Secure
Les cookies ne sont transmis qu'en HTTPS, ce qui empêche l'interception par un intercepteur (man-in-the-middle)
Jetons CSRF
Les opérations qui modifient l'état nécessitent des jetons CSRF que les attaquants ne peuvent pas falsifier
Expiration de la session
Les sessions expirent automatiquement après 24 heures, ce qui limite la fenêtre de compromission
Clé de coffre chiffrée
Votre clé de coffre en mémoire (la véritable clé qui chiffre vos données) est conservée comme une référence non extractible et effacée à la déconnexion. La clé principale, elle, est effacée juste après avoir déballé la clé de coffre à la connexion.
Même si un attaquant injecte du JavaScript malveillant dans votre navigateur, il ne peut pas accéder à vos cookies de session, parce que les cookies HttpOnly ne sont pas exposés à JavaScript.
Les attaquants ne peuvent pas faire faire à votre navigateur des requêtes authentifiées à notre API : les cookies SameSite et les jetons CSRF bloquent les requêtes intersites.
Plusieurs couches de protection : si un mécanisme de sécurité échoue, d'autres sont toujours en place pour protéger votre session.
L'indicateur HttpOnly bloque l'accès JavaScript
L'indicateur Secure impose le HTTPS
SameSite=Lax bloque les requêtes intersites
Portée de domaine explicite
Clé de coffre conservée comme référence WebCrypto non extractible en mémoire
Chiffrement AES-256-GCM
Expiration automatique
Nettoyage sécurisé de la mémoire à la déconnexion
Rejoignez WIGGWIGG et découvrez la sécurité à connaissance nulle par vous-même.
Comment fonctionne la vérification de mot de passe à connaissance nulle?