Prêt à découvrir la vraie confidentialité?
Rejoignez WIGGWIGG et découvrez la sécurité à connaissance nulle par vous-même.
Votre coffre-fort, vos données d'identité et vos contacts sont chiffrés sur votre appareil avant d'atteindre nos serveurs. On n'a pas votre mot de passe ni les clés privées en clair qui ouvrent ces données. Pour les communications protégées par notre méthode actuelle, la copie stockée est scellée pour la clé de communication du compte; un petit ensemble de la bêta privée reste lisible par nos serveurs jusqu'à un processus distinct de rescellement.
Le chiffrement à connaissance nulle veut dire qu'on a une connaissance nulle de votre mot de passe et qu'on ne détient aucune clé privée en clair ouvrant votre coffre-fort, vos données d'identité ou vos contacts. Pour les communications protégées par notre méthode actuelle, on ne conserve aucune clé capable d'ouvrir la copie scellée. C'est une promesse délimitée, pas générale : un petit ensemble de communications de la bêta privée reste lisible par nos serveurs, les numéros de téléphone, la facturation et certaines options nous sont lisibles pour que le service fonctionne, et les messages photo sont vérifiés contre le matériel illégal connu avant d'être stockés.
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
On ne détient aucune clé ouvrant votre coffre-fort, vos identités ou vos contacts
Une copie des données stockées sur nos serveurs ne peut pas, à elle seule, ouvrir votre coffre-fort, vos identités ou vos contacts quand un code client légitime et non altéré les a chiffrés
Ce qu'on peut voir et ce qu'on ne peut pas voir
Votre mot de passe (en clair ou chiffré)
Vos clés privées de chiffrement en clair
Vos informations d'identité (noms, dates de naissance, adresses)
Vos justificatifs (cartes de crédit, pièces d'identité, permis)
Votre coffre-fort, vos données d'identité et vos contacts, chiffrés sur votre appareil
Tapez n'importe quoi ci-dessous. C'est chiffré sur votre appareil avec une clé que vous seul détenez. Regardez ce qui arrive vraiment à nos serveurs.
Clé dérivée ici · jamais envoyée
Tout ce qu'on reçoit
…
On n'a pas votre clé; vous l'avez. Si nos serveurs étaient piratés demain, voici tout ce qu'un attaquant trouverait de votre coffre-fort : du charabia.
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; le serveur y joint un défi de connexion à usage unique.
Votre appareil dérive une clé maîtresse de chiffrement à partir de votre mot de passe à l'aide d'Argon2id, une fonction de dérivation à coût mémoire (128 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 128 Mio de RAM par tentative, pas seulement des cycles CPU.
Pour un compte qui utilise la connexion défi-réponse, votre appareil dérive une clé de signature Ed25519 de votre clé maîtresse (HKDF) et signe le défi à usage unique envoyé par le serveur. Seule une personne qui connaît votre mot de passe peut produire cette signature.
Pour ce compte, le serveur conserve la clé publique et vérifie la signature. Si elle est valide, vous êtes connecté sans que le serveur ait vu votre mot de passe. La clé publique stockée ne peut pas être rejouée pour se connecter. Certains comptes de la bêta privée conservent encore un vérificateur de connexion statique jusqu'à une connexion réussie dans une version à jour de WIGGWIGG. Si ce vérificateur fuit, une autre personne pourrait se connecter au compte.
Les jetons de session sont stockés dans des cookies HttpOnly pour que JavaScript ne puisse pas lire directement le cookie. Ça limite le vol du jeton, sans rendre le code injecté inoffensif.
L'authentification traditionnelle envoie votre mot de passe, chiffré en transit, au serveur qui le vérifie. Avec WIGGWIGG, votre mot de passe ne voyage jamais nulle part. Pour les comptes qui utilisent la connexion défi-réponse, le serveur conserve une clé publique et reçoit des signatures à usage unique, pas du matériel de connexion rejouable. Certains comptes de la bêta privée conservent encore un vérificateur de connexion statique jusqu'à une connexion réussie dans une version à jour de WIGGWIGG. Si ce vérificateur fuit, une autre personne pourrait se connecter au compte, même si le vérificateur ne révèle ni le mot de passe ni la clé du coffre-fort. Une copie des données stockées sur nos serveurs ne peut pas, à elle seule, ouvrir votre coffre-fort, vos données d'identité, vos contacts ou les communications scellées par notre méthode actuelle quand un code client légitime et non altéré les a chiffrés. Cette protection ne couvre pas une compromission active qui modifie le code client qu'on vous livre. Un petit ensemble de communications conservées depuis la bêta privée reste lisible par nos serveurs. Le palier « Vous et WIGGWIGG », y compris les numéros de téléphone, les réglages de routage et la facturation, est aussi lisible par nos serveurs parce qu'ils en ont besoin pour faire fonctionner vos lignes.
Argon2id avec 128 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
Clé de signature Ed25519 dérivée de votre clé maîtresse (HKDF)
Défi à usage unique envoyé par le serveur, signé sur votre appareil
Pour les comptes défi-réponse, le serveur conserve la clé publique et vérifie la signature
Pour ces comptes, la clé publique stockée ne peut pas être rejouée pour se connecter
Certains comptes de la bêta privée conservent encore un vérificateur de connexion statique jusqu'à une connexion réussie dans une version à jour de WIGGWIGG. Si ce vérificateur fuit, une autre personne pourrait se connecter au compte
Chiffrement authentifié AES-256-GCM
Chiffrement côté client pour le coffre-fort, les identités et les contacts
Pour les communications protégées par notre méthode actuelle, aucune clé côté serveur n'ouvre le contenu stocké; un petit ensemble de la bêta privée reste lisible jusqu'à un processus distinct de rescellement
IV unique par opération
Votre mot de passe dérive une clé maîtresse (Argon2id)
La clé maîtresse enveloppe une clé de coffre-fort distincte, propre à votre compte
Vos données de coffre-fort, d'identité et de contacts sont chiffrées avec la clé de coffre-fort, pas la clé maîtresse
Un changement de mot de passe ne fait que ré-envelopper la clé de coffre-fort, sans rechiffrer vos données
Sous notre méthode actuelle, le contenu entrant est scellé pour la clé de communication du compte, qu'un client pris en charge ouvre après la connexion et le déverrouillage; certaines données de la bêta privée attendent encore un processus distinct de rescellement
On n'enregistre jamais vos conversations
Sous notre méthode actuelle, on détruit notre copie de la clé de scellement dès qu'un message est stocké
Pour un message scellé, on ne conserve aucune clé capable de le lire : ni au repos, ni plus tard, ni sous mandat. Les exceptions, que nos serveurs peuvent lire : la messagerie vocale quand l'écoute par téléphone est activée ou quand le compte ne possède aucune clé de communication utilisable, le numéro de l'autre partie dans un journal d'appels quand le compte n'a aucune clé utilisable ou que la recherche de clé échoue, les intros que vos appelants enregistrent, le texte des réponses automatiques, le texte et l'audio de votre message d'accueil de boîte vocale, de l'annonce qu'on vous lit au décrochage et de l'invitation que vos appelants entendent avant de s'identifier, ainsi que le numéro personnel que vous vérifiez pour le renvoi d'appel. À part cela, un message que vous envoyez passe chez nous en clair avant d'atteindre l'opérateur, et on compare les messages photo aux banques d'images illégales connues avant de les stocker, en conservant la photo en cas de correspondance
Comment on réduit les risques de détournement de session, de requêtes intersites et d'injection de code
Plusieurs mécanismes de sécurité travaillent ensemble pour protéger votre session authentifiée :
Cookies HttpOnly
Les jetons de session stockés dans des cookies HttpOnly ne peuvent pas être lus directement par JavaScript, ce qui limite le vol de cookies par du code injecté
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)
Vérification de l'origine
Chaque requête qui modifie quelque chose doit passer une vérification stricte de l'origine, en plus des cookies SameSite : un site étranger ne peut pas la forger
Expiration de la session
Une session expire après 30 jours d'inactivité et jamais plus tard que 90 jours; vous pouvez ramener ça à 1 jour dans les réglages de sécurité
Clé de coffre-fort chiffrée
Votre clé de coffre-fort (la véritable clé qui chiffre vos données) est conservée comme une référence de clé non extractible pendant la session active (gardée d'un rafraîchissement de page à l'autre, sauf si vous choisissez Sécurité maximale), puis effacée au verrouillage ou à la déconnexion. La clé maîtresse, elle, est effacée juste après avoir déballé la clé de coffre-fort à la connexion.
Du JavaScript injecté ne peut pas lire directement un cookie de session HttpOnly. Il peut quand même agir dans la page ouverte, donc HttpOnly est une couche de protection et non une protection complète contre l'injection de code.
Les attaquants ne peuvent pas faire faire à votre navigateur des requêtes authentifiées à notre API : les cookies SameSite et une vérification stricte de l'origine sur chaque requête qui modifie quelque chose 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-fort conservée comme référence de clé non extractible pendant la session active (gardée d'un rafraîchissement de page à l'autre, sauf si vous choisissez Sécurité maximale)
Chiffrement AES-256-GCM
Expiration automatique
Effacée au verrouillage ou à 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?