By · Last updated 2026-03-17

Retour au blogTechnique

Ce que la violation de LastPass aurait dû apprendre à...

LastPass a crypté les données de ses utilisateurs. Les coffres ont tout de même été exfiltrés. Plus de 600K enregistrements Okta ont suivi.

March 17, 20268 min de lecture
LastPass breach lessonsSaaS vendor securitycloud vendor riskenterprise securityzero-knowledge architecture

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 utilise l'architecture zero-knowledge pour l'anonymisation des données personnelles. La dérivation de clé s'effectue via Argon2id dans votre navigateur ou application de bureau. Le chiffrement a lieu avant que les données quittent votre appareil. Les serveurs ne stockent que du texte chiffré qu'ils ne peuvent pas déchiffrer. En savoir plus.

Sources

Prêt à protéger vos données ?

Commencez à anonymiser les PII avec plus de 285 types d'entités dans 48 langues.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.