Ajouter à Chrome

Comment ça marche

Un aperçu technique destiné aux auditeurs de sécurité. Tout ici est vérifiable dans le code source — y compris ce qui nous met le moins en valeur, que nous énonçons plutôt que d'omettre.

Architecture

Il n'y a pas de backend. L'extension est une extension Chrome Manifest V3 qui génère les codes TOTP/HOTP localement avec OTPAuth. Nous n'exploitons aucun serveur, ne gérons aucun compte et n'avons aucun canal par lequel des données utilisateur pourraient nous parvenir.

Puisqu'il n'y a pas de serveur, il n'y a pas non plus de matériel de clé côté serveur, pas de séquestre de clé et aucun chemin de récupération sous notre contrôle. Si un utilisateur oublie son mot de passe et perd son code de récupération, nous ne pouvons rien pour lui — c'est voulu.

Cryptographie

La protection par mot de passe est facultative et désactivée par défaut. Lorsqu'elle est active :

Chiffrement
AES-256-GCM, IV aléatoire de 96 bits par enregistrement et par réécriture
Dérivation de clé
PBKDF2-HMAC-SHA256, 600 000 itérations, sel aléatoire de 128 bits (recommandation OWASP)
Clé maîtresse
256 bits, issue de crypto.getRandomValues, générée une seule fois ; le mot de passe ne fait que l'envelopper
Empreintes
HMAC-SHA256 sous une sous-clé dérivée par HKDF, utilisée pour fusionner les enregistrements entre appareils
Stockage de la clé déverrouillée
chrome.storage.session — en mémoire uniquement, jamais écrite sur disque, effacée à la fermeture du navigateur, inaccessible depuis un script de contenu
Verrouillage automatique
À chaque ouverture / après 5, 15 ou 60 minutes d'inactivité / jusqu'à la fermeture du navigateur
Implémentation
WebCrypto exclusivement. Aucune primitive n'est réécrite à la main et aucune bibliothèque de cryptographie n'est embarquée.

Pourquoi deux niveaux de clé

Les données ne sont jamais chiffrées directement avec une clé dérivée du mot de passe. Une clé maîtresse aléatoire chiffre les enregistrements ; la sortie de PBKDF2 ne fait qu'envelopper cette clé maîtresse. Deux conséquences en découlent, et toutes deux comptent :

  • Changer le mot de passe réécrit 32 octets au lieu de rechiffrer chaque enregistrement, chaque sauvegarde et chaque export. C'est précisément lors de ces réécritures massives que les systèmes de stockage perdent des données.
  • Un code de récupération de 160 bits peut envelopper la même clé maîtresse indépendamment : un mot de passe oublié reste donc récupérable. Le code est affiché une fois, doit être ressaisi pour confirmation et est renouvelé après chaque usage. Rien n'est écrit sur disque tant que l'utilisateur ne l'a pas confirmé.

Ce qui est chiffré, et ce qui ne l'est pas

Avec la protection par mot de passe activée, tout l'enregistrement du compte est chiffré, hormis son identifiant et son empreinte — y compris le nom du service, si bien qu'un profil volé ne révèle pas auprès de quels services l'utilisateur a des comptes. L'activation chiffre les enregistrements, les vérifie en les déchiffrant et en les comparant, et seulement ensuite supprime toute copie en clair : stockage local du navigateur, synchronisation et les sept instantanés de sauvegarde en rotation.

Dit clairement, parce que cela compte pour votre évaluation :

  • Sans protection par mot de passe, les comptes sont stockés non chiffrés et, si Chrome Sync est actif, répliqués via le compte Google de l'utilisateur. Nous ne les recevons jamais, mais Google les détient. La synchronisation peut être désactivée, ce qui supprime aussi ce qui s'y trouve déjà.
  • L'historique d'utilisation par site — quel compte est utilisé sur quel domaine — est stocké localement et n'est pas couvert par le coffre pendant sa collecte. Activer la protection par mot de passe le supprime ; il peut aussi être désactivé séparément.

Modèle de menace

Protège contre

  • Un répertoire de profil de navigateur volé ou copié
  • Un logiciel voleur d'informations qui exfiltre en masse les données du navigateur
  • Un accès physique à une machine laissée sans surveillance
  • Des enregistrements de comptes parvenant à Google via Chrome Sync
  • Un fichier de sauvegarde perdu ou volé (export protégé par mot de passe)

Ne protège pas contre

  • Un logiciel malveillant s'exécutant sous l'identité de l'utilisateur alors que le coffre est déverrouillé
  • Un enregistreur de frappe capturant le mot de passe à la saisie
  • Un navigateur ou un système d'exploitation compromis
  • La compromission des services tiers auxquels les codes sont destinés

En résumé : cela protège les données au repos. Cela ne défend pas, et ne peut pas défendre, un appareil déjà sous le contrôle d'un attaquant pendant son utilisation.

Permissions

Le manifeste déclare exactement deux permissions et aucune permission d'hôte :

storage
Comptes et réglages dans le stockage local, clé déverrouillée dans le stockage de session, et la copie de synchronisation facultative
activeTab
Lit le nom d'hôte de l'onglet actif pour mettre en avant le compte correspondant, et capture l'onglet lorsque l'utilisateur scanne un QR code à l'écran

Il n'y a aucun script de contenu, aucune permission tabs, cookies ou webRequest, et aucune ressource accessible au web. L'extension ne peut ni lire ni modifier le contenu d'une page, quelle qu'elle soit.

Caméra

Le scan de QR code par la caméra s'exécute sur une page d'extension ouverte dans un onglet, pas dans la popup — une popup est détruite dès qu'elle perd le focus, ce que fait précisément une demande de permission. Cela ne nécessite aucune permission dans le manifeste : c'est la demande d'accès caméra standard du navigateur, accordée par origine d'extension et révocable dans les paramètres du site, et elle n'apparaît jamais avant que l'utilisateur n'ouvre le scanner. La vidéo est décodée localement, jamais transmise ni stockée.

Trafic sortant

L'extension n'émet aucune requête automatique en usage normal, et Manifest V3 interdit le code distant. Toutes les connexions qu'elle peut établir :

HôteQuandTransporte des données utilisateur ?
worldtimeapi.org
timeapi.io
Vérification de dérive d'horloge, mise en cache, échoue silencieusement. TOTP casse si l'horloge dérive.Non
authenticator.shPage de bienvenue à l'installation ; page de retour à la désinstallation ou lors d'une note.Non (journaux de serveur web ordinaires)

Aucune police, aucun script, aucun style ni aucune image n'est chargé depuis un hôte tiers. Tout ce qui est nécessaire au rendu de l'interface est livré dans le paquet.

Vérifier ce que nous publions

Vous n'avez à croire aucun des points ci-dessus sur parole. L'extension est open source et chaque version est reproductible :

  1. Téléchargez le .crx publié depuis le Chrome Web Store et décompressez-le
  2. Basculez sur le tag git correspondant
  3. Lancez npm ci && npm run build avec Node 20 LTS
  4. Comparez le dist/ obtenu avec le paquet décompressé

Un SHA-256 pour chaque fichier du dist/ produit est publié à chaque version GitHub sous la forme SHA256SUMS-v<version>.txt, au format sha256sum : l'étape 4 se réduit donc à un seul appel à sha256sum -c. Les différences doivent se limiter à l'ordre des fichiers dans les archives et aux espaces dans la sortie minifiée d'une version corrective de Node à l'autre.

Les dépendances d'exécution sont délibérément peu nombreuses — OTPAuth, React, jsQR, Zustand, Framer Motion et Lucide — figées par un fichier de verrouillage versionné. Un SBOM CycloneDX est disponible sur demande.

Consulter le code source

Ce que nous n'avons pas

Nous sommes un petit éditeur indépendant. Si l'un des points suivants est une exigence stricte de votre processus, mieux vaut le savoir maintenant qu'au bout de trois semaines d'évaluation :

  • Pas de certification SOC 2, ISO 27001 ou équivalente
  • Aucun test d'intrusion externe commandé à ce jour
  • Pas de programme de bug bounty rémunéré

Ce que nous offrons à la place : une transparence totale du code source, un build vérifiable, une surface de permissions minimale et aucune infrastructure serveur susceptible de détenir vos données.

Nous écrire

Rapports de vulnérabilité et questions de sécurité : security@authenticator.sh. Notre politique de divulgation, son périmètre, nos délais de réponse et les conditions de safe harbour figurent sur la page politique de sécurité ; ce qui est stocké et ce qui quitte l'appareil est exposé dans la politique de confidentialité.

Nous répondons volontiers à un questionnaire écrit d'évaluation fournisseur ou parcourons le code avec une équipe sécurité.

Pour tout ce qui ne relève pas de la sécurité — installation, récupération de compte, questions de facturation liées à un déploiement — voir le support. Merci de ne pas y envoyer de rapports de vulnérabilité : cette boîte n'est pas traitée comme confidentielle.