SésameComment Sésame protège votre coffre
Ce document décrit précisément ce que fait Sésame avec vos données, y compris lorsque vous synchronisez vos appareils ou partagez un coffre. Le code source est ouvert (licence GPL-3.0) : chacun peut le vérifier.
1. Principe : zero-knowledge et local-first
Votre coffre est chiffré et déchiffré uniquement sur vos appareils. Sans synchronisation, il n'existe que dans le stockage de votre navigateur ou de l'application (IndexedDB). Si vous activez la synchronisation, le serveur ne reçoit que le coffre déjà chiffré. Votre mot de passe maître n'est jamais écrit sur disque ni transmis, à personne.
2. Dérivation de clé
| Étape | Algorithme | Paramètres |
|---|---|---|
| Mot de passe maître → clé maître | Argon2id | 64 Mio de mémoire, 3 passes, sel aléatoire de 128 bits |
| Clé maître → clé de chiffrement de clé (KEK) | HKDF-SHA256 | Séparation de domaine sesame/kek/v1 |
| Clé du coffre (DEK) | Aléatoire | 256 bits, générée par crypto.getRandomValues |
La clé du coffre est « enveloppée » par la KEK. Changer de mot de passe maître ne ré-enveloppe que cette clé : l'opération est instantanée et sûre.
3. Chiffrement des données
Le contenu du coffre est chiffré avec AES-256-GCM, un chiffrement authentifié : toute modification du fichier chiffré est détectée et refusée. Un vecteur d'initialisation aléatoire de 96 bits est utilisé à chaque sauvegarde, et des données associées (AAD) lient chaque bloc à son rôle. Toute la cryptographie repose sur WebCrypto (implémentation native du navigateur) et sur Argon2 en WebAssembly.
4. Protection pendant l'utilisation
- Verrouillage automatique après inactivité (5 minutes par défaut, réglable).
- Effacement du presse-papiers 30 secondes après une copie.
- Clé du coffre non exportable en mémoire, tampons sensibles effacés après usage.
- Politique de sécurité du contenu (CSP) stricte : aucun script tiers, aucun
eval. - Seuls les liens
http(s)sont cliquables : pas d'injection viajavascript:.
5. Synchronisation chiffrée : ce que voit le serveur
La synchronisation est optionnelle. Le serveur est hébergé dans l'Union européenne (Paris). Il sert de boîte aux lettres pour des données qu'il ne peut pas lire.
| Le serveur voit | Le serveur ne voit jamais |
|---|---|
| Un identifiant de synchronisation aléatoire (sans nom ni e-mail) | Votre mot de passe maître ni la clé de votre coffre |
| Une empreinte SHA-256 du secret d'authentification | Le secret d'authentification lui-même |
| Le coffre chiffré, sa taille et ses dates de mise à jour | Le contenu du coffre : sites, identifiants, mots de passe, notes, codes 2FA |
| L'adresse IP de connexion (hachée pour la limitation de débit) | Le nom des éléments ou des coffres partagés |
- Appairage à deux facteurs : un nouvel appareil a besoin du code d'appairage et du mot de passe maître. Le code seul ne déchiffre rien ; le mot de passe seul ne donne pas accès au serveur.
- Résistance à un serveur malveillant : écritures en « compare-and-swap », révision authentifiée à l'intérieur des données chiffrées (un retour à une ancienne version est détecté), changement de mot de passe maître adopté seulement s'il est prouvé.
- Protection du serveur : limitation de débit, taille maximale des requêtes, validation stricte, base de données inaccessible directement.
- Maîtrise de vos données : supprimez tout à tout moment via Réglages → Synchronisation → « Désactiver et supprimer la copie du serveur ». Un compte resté 24 mois sans synchronisation est purgé automatiquement. Détails dans la politique de confidentialité.
6. Partage familial : chiffré pour chaque membre
Un coffre partagé possède sa propre clé AES-256, aléatoire. Cette clé est chiffrée séparément pour chaque membre avec ECIES sur X25519 (échange de clés éphémère, HKDF-SHA256 puis AES-256-GCM). Le serveur ne stocke que ces clés enveloppées et le contenu chiffré.
- Invitations authentifiées : l'expéditeur est authentifié cryptographiquement, et une invitation reste « en attente » tant que la personne invitée ne l'a pas acceptée explicitement.
- Numéros de sécurité : un numéro est affiché des deux côtés ; comparez-le (de vive voix, par exemple) pour écarter toute substitution de clé.
- Rôles : « lecture seule » ou « peut modifier ». Le serveur refuse les écritures d'un membre en lecture seule ; le chiffrement, lui, ne peut pas l'empêcher de lire ce qu'on lui a partagé.
- Rotation de clé : retirer un membre crée une nouvelle clé (version strictement croissante). L'ancien membre ne peut plus lire les modifications futures ; il a pu copier ce qu'il voyait auparavant, comme avec tout partage.
7. Clés d'accès (passkeys)
Sésame enregistre vos clés d'accès WebAuthn comme n'importe quel autre élément : la clé privée est stockée chiffrée dans votre coffre, synchronisée chiffrée si vous l'avez activé, et utilisée via l'extension. L'origine du site est vérifiée avant toute signature, et une passkey n'est jamais présentée à un autre domaine que celui pour lequel elle a été créée.
8. Extension de navigateur
- Remplissage uniquement sur action explicite de votre part (clic, icône ou raccourci), jamais en arrière-plan à votre insu.
- Un identifiant enregistré pour un site
httpsn'est jamais rempli sur une pagehttp; le port et le domaine exacts sont vérifiés. - Les informations de synchronisation sont conservées à l'intérieur du coffre chiffré, jamais en clair dans le stockage de l'extension.
9. Vérification des fuites (facultative)
Sésame utilise l'API Have I Been Pwned avec le k-anonymat : il calcule l'empreinte SHA-1 du mot de passe, n'envoie que ses 5 premiers caractères, puis compare localement la liste reçue. Le service ne peut pas savoir quel mot de passe a été vérifié. Les réponses sont « rembourrées » pour masquer leur taille.
10. Générateur aléatoire
Les mots de passe sont tirés avec crypto.getRandomValues et un échantillonnage par rejet, qui élimine le biais modulo. Chaque classe de caractères choisie est garantie, et l'entropie réelle est affichée. Essayez-le sur la page d'accueil.
11. Audits internes et corrections
Avant la version 2.0, cinq audits internes approfondis ont porté sur la cryptographie, les protocoles de synchronisation et de partage, le serveur, l'application et l'extension navigateur. Tous les points relevés ont été corrigés et sont couverts par des tests de non-régression, notamment :
- détection du retour en arrière d'un coffre ou d'une clé de partage imposé par un serveur malveillant ;
- invitations à accepter explicitement, avec expéditeur authentifié et numéro de sécurité ;
- horodatages bornés lors de la fusion, refus du remplissage d'une page
httpavec un identifianthttps; - quotas, validation stricte et taille plafonnée côté serveur.
Un audit externe indépendant est en préparation : le dossier destiné aux auditeurs est prêt. Son rapport sera publié ici. Le détail des revues figure dans le dépôt du projet (dossier docs).
12. Limites connues
La transparence fait partie de la sécurité. Un appareil compromis (logiciel espion, extension malveillante) pendant que le coffre est déverrouillé peut lire vos données : c'est vrai pour tout gestionnaire de mots de passe. Le serveur de synchronisation connaît des métadonnées techniques (taille du coffre, dates, adresse IP de connexion). Sans synchronisation, effacer les données du navigateur supprime le coffre local : faites des sauvegardes chiffrées régulières. Enfin, tant que l'audit externe n'a pas eu lieu, nos garanties reposent sur nos propres revues et sur le code ouvert.
13. Signaler une vulnérabilité
Merci de signaler toute faille de façon responsable, en privé, via l'onglet « Security » du dépôt GitHub du projet (signaler une vulnérabilité) ou via le formulaire de contact (sujet « Sécurité »). N'ouvrez pas de ticket public pour une faille non corrigée.
- Décrivez le problème, la version concernée et les étapes pour le reproduire.
- Laissez-nous un délai raisonnable pour corriger avant toute publication.
- N'accédez jamais aux données d'autres personnes lors de vos tests.