La violation qui a transformé la sécurité cloud
Mis à jour pour 2026
La violation de LastPass en 2022 n'est pas principalement une histoire de gestionnaires de mots de passe. C'est une histoire de confiance. Des entreprises ont confié des données sensibles à un fournisseur cloud. Cette confiance a été trahie — non par négligence, mais par des failles cachées.
LastPass vendait une architecture zero-knowledge. En pratique, ce n'était pas du vrai zero-knowledge. 25 millions d'utilisateurs ont eu leurs coffres chiffrés volés. La violation a été divulguée pour la première fois en août 2022. LastPass a mis à jour ses déclarations plusieurs fois jusqu'à fin 2022 au fur et à mesure que l'ampleur devenait claire.
Pour les entreprises de santé, de finance et de droit, ce n'était pas une nouvelle lointaine. Ces secteurs font face à une responsabilité directe en cas de fuite de données. Le cas LastPass était un avertissement clair d'un problème plus large.
Deux failles qui ont rendu la violation possible
L'analyse post-violation a identifié deux faiblesses clés.
Dérivation de clé insuffisante. LastPass utilisait PBKDF2 pour la dérivation de clé. Les comptes récents avaient 100 100 itérations. L'OWASP en recommande 600 000. Pour les anciens comptes — certains d'avant 2018 — le nombre était aussi bas qu'1 itération. Moins d'itérations rendent les attaques par force brute rapides et peu coûteuses. Les attaquants avec les fichiers de coffre pouvaient tester des mots de passe maîtres à grande vitesse.
Métadonnées en clair. Le contenu des coffres était chiffré. Mais les métadonnées ne l'étaient pas. Les URLs, noms d'utilisateur et noms de services étaient visibles dans les données volées. Les attaquants pouvaient voir quels services chaque utilisateur utilisait. Cela permettait du phishing ciblé et du credential stuffing — sans avoir besoin de craquer le chiffrement.
Ce cas montre pourquoi deux questions doivent être posées séparément. "La conception est-elle zero-knowledge ?" est une question. "La mise en œuvre est-elle correcte ?" en est une autre.
Okta en 2023 : un chemin différent, le même résultat
En octobre 2023, Okta a signalé une violation. Un identifiant volé a donné à un attaquant accès à son système de support client. La violation a exposé 600 000+ enregistrements de support. Ces données incluaient des fichiers téléchargés par des clients lors de sessions de support.
Okta est une plateforme de sécurité d'identité. Le problème n'était pas une faille de conception. C'était un échec de contrôle d'accès. L'identifiant d'un ingénieur de support a été volé. L'attaquant a utilisé cette connexion valide pour accéder à des données sensibles.
LastPass et Okta illustrent les deux chemins principaux vers une violation de fournisseur :
- Défauts de conception — des promesses zero-knowledge mal implémentées
- Défauts de contrôle d'accès — des identifiants valides utilisés pour accéder à des données non autorisées
L'architecture zero-knowledge prévient le premier type. Elle n'arrête pas un attaquant avec de vrais identifiants de support. Mais elle l'empêche de lire les données clients en clair. Le fournisseur ne détient jamais de contenu déchiffrable. Consultez notre aperçu sécurité et conformité pour plus de détails.
Les incidents SaaS ont augmenté de 300 % en deux ans
Obsidian Security a constaté une augmentation de 300 % des incidents de sécurité SaaS de 2022 à 2024.
Ce n'est pas une hausse de 300 % des compétences des attaquants. Deux forces l'ont propulsée. L'adoption du SaaS a crû rapidement. Les attaquants ont suivi les données. Une seule violation de fournisseur peut exposer les données de dizaines de clients d'entreprise à la fois. Ce rapport coût-bénéfice favorise les attaques sur les fournisseurs plutôt que sur les entreprises individuelles.
Les entreprises qui considéraient les plateformes cloud comme sûres doivent mettre à jour ce point de vue. Les fournisseurs SaaS sont désormais des cibles prioritaires.
Questions à poser à tout fournisseur cloud
Cette liste couvre les domaines essentiels.
Chiffrement :
- Demandez l'algorithme de dérivation de clé, le nombre d'itérations et les paramètres mémoire.
- Confirmez que le nombre d'itérations respecte les minimums OWASP : 600 000 PBKDF2-SHA256 ou équivalent Argon2id.
- Vérifiez que la dérivation de clé s'effectue sur votre appareil, pas sur les serveurs du fournisseur.
Exposition des métadonnées :
- Demandez quelles métadonnées sont stockées en clair à côté du contenu chiffré.
- Demandez un modèle de données montrant quels champs sont chiffrés et lesquels seraient visibles en cas de violation.
Accès du support :
- Demandez si les agents de support peuvent accéder aux données clients.
- Confirmez que les systèmes de support ne peuvent pas accéder au contenu client en clair.
Historique des incidents :
- Demandez tous les incidents de sécurité antérieurs, y compris ceux en dessous du seuil de divulgation publique.
- Évaluez la complétude et la transparence des divulgations passées.
La violation de LastPass était un échec d'implémentation et un manque de transparence. Les fournisseurs avec des réponses précises permettent une vraie évaluation des risques. Ceux qui font des affirmations vagues cachent des risques. Ces risques se révèlent souvent après une violation. Consultez notre aperçu conformité pour l'évaluation des fournisseurs.
anonym.legal applique le zero-knowledge à la connexion : la dérivation de clé s'effectue via Argon2id dans votre navigateur ou application de bureau, de sorte que votre mot de passe ne quitte jamais votre appareil. Le texte envoyé pour anonymisation est traité par notre API hébergée dans l'UE (Hetzner, Falkenstein). Les clés de chiffrement enregistrées sont stockées chiffrées sur nos serveurs, mais ne sont pas en zéro connaissance. En savoir plus.