La violation qui a changé les hypothèses de sécurité des entreprises dans le cloud
La violation de LastPass en 2022 n'est pas principalement une histoire de gestionnaires de mots de passe. C'est une histoire de ce qui se passe lorsque les entreprises font confiance aux fournisseurs de cloud avec leurs données les plus sensibles et que cette confiance est violée — non pas par imprudence mais par des faiblesses d'implémentation qui étaient invisibles de l'extérieur.
LastPass a commercialisé une architecture à connaissance nulle. L'architecture n'était pas à connaissance nulle dans la pratique. 25 millions d'utilisateurs ont vu leurs coffres cryptés exfiltrés. La violation a été d'abord révélée en août 2022 et mise à jour plusieurs fois jusqu'à la fin de 2022 à mesure que l'ampleur s'est élargie.
Pour les entreprises dans les secteurs de la santé, des finances et des services juridiques — des secteurs où l'exposition des données crée une responsabilité réglementaire — la violation de LastPass n'était pas un incident isolé à observer de loin. C'était un aperçu d'un problème systémique.
Les détails d'implémentation qui comptaient
L'analyse post-violation a révélé deux faiblesses d'implémentation critiques :
Déficit de nombre d'itérations : LastPass a utilisé PBKDF2 pour la dérivation de clés. Pour les nouveaux comptes, ils ont utilisé 100 100 itérations — en dessous de la recommandation de l'industrie de 600 000. Pour les anciens comptes (avant 2018 dans certains cas), le nombre d'itérations était aussi bas que 1 itération. Des nombres d'itérations plus bas rendent les attaques par force brute sur les coffres cryptés computationnellement réalisables. Les attaquants qui obtenaient des coffres pouvaient tenter systématiquement de craquer les mots de passe maîtres.
Exposition des métadonnées : Bien que le contenu des coffres soit crypté, les métadonnées ne l'étaient pas. Les URL stockées dans le gestionnaire de mots de passe, les noms d'utilisateur et les noms de services étaient visibles dans les données exfiltrées. Les attaquants pouvaient identifier avec quels services les utilisateurs avaient des comptes, permettant un phishing ciblé et un remplissage de crédentiels même sans craquer le cryptage du coffre.
Pour les équipes d'approvisionnement évaluant les fournisseurs de sécurité cloud, le cas de LastPass démontre que deux questions doivent être posées séparément : "L'architecture est-elle à connaissance nulle ?" et "L'implémentation est-elle correcte ?"
La violation d'Okta : le même mois, un mécanisme différent
En octobre 2023, Okta a révélé qu'un acteur malveillant avait utilisé un crédentiel volé pour accéder au système de support client d'Okta. La violation a exposé plus de 600 000 enregistrements de support client, y compris des fichiers téléchargés par des clients lors d'interactions de support.
Okta est une plateforme de sécurité d'identité. La violation n'était pas un échec fondamental de l'architecture — c'était un échec de contrôle d'accès de la chaîne d'approvisionnement. Le crédentiel d'un ingénieur de support a été compromis, et l'attaquant a utilisé un accès légitime pour atteindre des données sensibles.
La combinaison de LastPass et d'Okta illustre les deux modes de défaillance auxquels les fournisseurs de cloud d'entreprise sont confrontés :
- Défaillances d'architecture : les revendications de connaissance nulle non réellement mises en œuvre
- Défaillances de contrôle d'accès : des crédentiels légitimes menant à un accès non autorisé aux données
L'architecture à connaissance nulle aborde le premier mode de défaillance. Elle ne protège pas contre un attaquant déterminé qui obtient des crédentiels légitimes pour les systèmes de support des fournisseurs. Mais elle garantit que même un tel attaquant ne peut pas accéder aux données en clair des clients — car les systèmes de support du fournisseur n'ont jamais accès à des données décryptables.
Les incidents de sécurité SaaS ont augmenté de 300 % entre 2022 et 2024
La recherche d'AppOmni et de la Cloud Security Alliance suivant les incidents de violation SaaS de 2022 à 2024 a trouvé une augmentation de 300 % des incidents de sécurité affectant les plateformes SaaS pendant cette période.
Le chiffre de 300 % ne représente pas une augmentation de 300 % de la sophistication des attaquants. Il représente la croissance de l'adoption des SaaS combinée à l'adaptation des attaquants : à mesure que plus de données d'entreprise se déplaçaient vers des plateformes cloud, les attaquants ont déplacé des ressources pour cibler ces plateformes. Le retour sur investissement de la compromission d'un fournisseur SaaS — obtenir l'accès aux données de dizaines ou de centaines de clients d'entreprise simultanément — est considérablement plus élevé que de cibler des entreprises individuelles.
Pour les entreprises qui ont construit leurs processus d'évaluation de la sécurité des fournisseurs autour de l'hypothèse que les fournisseurs cloud sont des cibles sécurisées, les données de 2022-2024 nécessitent une recalibration. L'hypothèse est erronée. Les fournisseurs SaaS sont des cibles prioritaires.
La liste de contrôle d'audit après LastPass
Pour les entreprises réévaluant la sécurité des fournisseurs cloud suite aux incidents de LastPass et d'Okta, une liste de contrôle pratique :
Implémentation du cryptage :
- Demander l'algorithme de dérivation de clé, le nombre d'itérations et les paramètres de mémoire
- Confirmer que les nombres d'itérations respectent les recommandations actuelles de l'OWASP (600 000 PBKDF2-SHA256 minimum, ou paramètres équivalents Argon2id)
- Vérifier que la dérivation de clé se fait côté client, et non sur les serveurs du fournisseur
Protection des métadonnées :
- Demander spécifiquement quelles métadonnées sont stockées en clair aux côtés du contenu crypté
- Demander le modèle de données montrant quels champs sont cryptés et lesquels sont accessibles dans des scénarios de violation
Contrôles d'accès au système de support :
- Demander la documentation sur l'accès des ingénieurs de support aux données des clients
- Confirmer que les systèmes de support ne peuvent pas accéder aux données en clair des clients
Historique des notifications de violation :
- Demander la divulgation de tous les incidents de sécurité précédents, y compris ceux n'atteignant pas les seuils de divulgation publique
- Évaluer la transparence et l'exhaustivité des divulgations antérieures
La violation de LastPass était en partie un échec d'implémentation et en partie un échec de transparence sur l'implémentation. Les entreprises qui posent des questions détaillées avant la sélection des fournisseurs reçoivent des réponses qui permettent une évaluation des risques éclairée. Les entreprises qui acceptent des revendications de haut niveau — "nous cryptons vos données" — héritent du risque de découvrir des détails d'implémentation après une violation.
Sources :