Le mois dernier, Lastpass avertissait d’une brèche de sécurité. Avec la publication d'une mise à jour vendredi soir, on en sait désormais plus.
Selon le PDG Karim Toubba, le pirate qui s’est introduit a pu accéder aux systèmes internes pendant quatre jours. C’est ce qui ressort de l’enquête interne menée en partenariat avec Mandiant.
Il se veut cependant rassurant : « Bien que l’acteur malveillant ait pu accéder à l’environnement de développement, la conception de notre système et nos contrôles l’ont empêché d’accéder aux données des clients ou aux mots de passe chiffrés ». Il n’y a pas non plus de preuves d’une quelconque injection de code malveillant.
Comment le pirate s’y est-il pris ? Il s’agit, comme on s’en doute, d’une erreur humaine. L’un des développeurs a pu être berné. L’explication manque de détails, mais on sait que le pirate a pu passer l’authentification à facteurs multiples. Un cas faisant écho à ce que nous indiquions récemment sur ce type de défense, certes important, mais pas absolu.
Le pirate a pu voler une partie du code source, ainsi que certaines informations techniques propriétaires. Il n’a cependant rien pu en faire, car seule l’équipe de production est habilitée à publier du code binaire pour la clientèle, après contrôle.
L’entreprise indique avoir déployé des contrôles supplémentaires, notamment sur la sécurité endpoint et une surveillance renforcée. Il est probable qu’il s’agisse notamment d’un accès conditionnel plus strict.
Commentaires (47)
#1
Confier ses mots de passe à un prestataire, je trouve cela fort risqué. On fait le pari risqué que les données du prestataire ne seront pas piratées et que l’entreprise sera pérenne des années durant. Mes mots de passe sont sur un tableur OpenOffice, puis en PDF. Avec le mot de passe mais pas le nom d’utilisateur. Le tout est sur carte SD. Rien sur ordinateur. J’imprime de temps en temps une version papier qui reste à mon domicile. Une soixantaine de pages. En voyage, je trimbale une carte SD avec le PDF protégé par mot de passe. Celui-ci peut sans doute être cassé si la carte était volée, mais ce PDF sur la carte est mêlé à d’autres éléments anodins (photos, documents administratifs, etc.) et les données ne sont pas directement utilisables car incomplètes. Et la double authentification est bien sûr activée partout où c’est possible. Fastidieux tout cela, mais fiable.
#1.1
Ptdr quoi
#1.2
Oui sauf que tout le monde n’est pas un utilisateur expert et près à faire tout ça. Il faut arrêter de se regarder le nombril entre informaticiens.
Il y a un monde entre ce que tu fais et “Madame Michu” qui met le prénom de son fils sur chaque site. Une solution comme Lastpass, Dashlane ou 1password relativement simple et bien intégrée dans les nav et les smartphones est quand même largement préférable même si pas encore fiable à 100%.
Et au moins, ce type de solution amène la problématique chez les utilisateurs non experts et ensuite, libre ceux qui le veulent d’aller plus loin.
#1.3
Sinon il y a Keepass pour garder la main sur la base de données.
#1.4
Si j’en crois la page Wiki en anglais, c’est simplement de l’AES256. Il n’y a aucun mention sur cipher block ni sur la dérivation de clé. Au vu des performances d’un JTR sur l’AES, ça donne pas très confiance sauf si un vrai mot de passe est utilisé où s’il y a plus derrière du coté du lecteur.
Perso, quand je dois me trimballer avec des données sensibles pour le travail (ou même perso), je prends une clé usb que je remplis aléatoirement de données, ensuite je crée une partition standard et une partition “caché” LUKS. Comme il n’y a pas de header à proprement parlé, cette partition reste quasi-invisible. Dedans je mets mes données sensibles. L’avantage est que ça passe sur tout les OS (modulo le filesystem) et que je suis le seul à savoir son existence et sa clé de déchiffrement (via pass phrase).
Ainsi si je perds où je me fais voler la clé, mis à part les services secrets; je doute que même une entreprise concurrente va se faire chier à essayer d’aller extraire les données aux niveaux des blocs , puis identifier le début de la partition LUKS et ensuite essayer de casser le chiffrement.
Et en plus, ça permet de faire du denial encryption (si tu es prêt à prendre le risque).
Évidemment, j’ai bien plus confiance en LUKS que BitLocker
#1.5
Pour le chiffrement des PDF, je n’y ai que modérément confiance. Un notaire m’a fait parvenir récemment un document PDF en lecture seule et j’ai voulu le déchiffrer pour le modifier. Un service en ligne a cassé le code en quelques minutes. Le mot de passe était sans doute trop simple.
Sinon, mon système rudimentaire me suffit parce que je n’ai pas de données sensibles à protéger. J’utilise aussi les services “mots de passe” des navigateurs, mais pas pour les sites sensibles. Ces services sont d’ailleurs fort dangereux : ils peuvent mémoriser mots de passe ou codes bancaires quasiment à notre insu !
#1.6
Alors.
KeePass est en tout point plus sécurisé qu’un pdf ou xslx protégé avec un mot de passe. Mon dieu quelle vie compliquée pour finir par une solution moins sécurisée qu’un simple fichier kdbx à trimballer de poste en poste sur clé USB (dans ton cas ce serait le mieux). En plus tu laisserais les arbres tranquilles.
Un fichier kdbx non-ouvert est inviolable si la master key est suffisamment compliquée. Les seuls vecteurs d’attaques connus sont avec bdd ouverte (et c’est pas accessible au premier venu). La seule chose à éviter est de laisser trainer le fichier sur le web pour se prémunir de nouveaux types d’attaques avec les futurs hardwares mais globalement en 2022, un Keepass avec dérivation argon2 longue de 1 seconde et une clé maître aussi simple que “DagueLutesseOrion#4ROP” ne craint absolument rien. Si mon kdbx partait en ligne dans un groupe Facebook je mettrais 3 ans sans aucun stress à mettre à jour mes passwords tranquillement sur mes 600+ entrées.
#1.7
J’ai rarement lu autant de bêtises dans un seul commentaire…
#2
#3
Nan mais chez Lastpass et tous les concurrents, les mots de passe sont chiffrés. Lastpass ne les voit jamais en clair, jamais. Le chiffrement est assuré par l’appli installée chez l’utilisateur. Donc les pirates pourraient récupérer toute la base de données Lastpass, ça ne représenterait aucun risque pour les usagers (et c’est justement pour ça que c’est chiffré, pas pour autre chose). A moins qu’on n’arrive à casser les méthodes de chiffrement utilisées, mais si ça arrive on aura des soucis encore plus graves…
Pirater l’appli desktop/mobile/extension navigateur pour espionner les mots de passe en clair, là ça serait autre chose, mais apparemment ça n’est pas ça qui s’est passé, donc tout va bien.
#3.1
C’est plus ou moins ce que j’aurais répondu à JnnT, chiffrement du coffre + double authentification pour le déverrouiller, on est quand même sur un autre niveau que le PDF planqué sur une carte SD (non chiffrée si j’ai bien compris).
Pour ma part, on partage un serveur à plusieurs qui tourne avec Yunohost et donc une instance Bitwarden.
Y a du pour et du contre, d’un côté ça permet de “décentraliser” le stockage des coffres mais de l’autre, certains avancent une sécurité potentiellement plus faible que les moyens engagés par les entreprises spécialisées comme Lastpass, 1password, Dashlane etc. (hypothèse donc remise en cause dans cet article il faut le souligner)
A ce stade, je n’ai encore rien lu comme signalement problématique vis à vis de Yunohost, qui pour rappel est basé sur Debian.
#4
Merci 😅😅😅 mais pour garder la main sur ses données sans avoir une gestion très lourde Et extrêmement chronophage, il suffit de prendre Keepass XC. La base de données est chiffrée (bien mieux que votre pdf).
#5
Probablement pas. Le chiffrement d’un PDF n’a pas de raison objective d’être moins bon que celui d’un gestionnaire de mots de passe.
Par contre, c’est tout le reste autour qui risque d’être mieux contrôlé : un gestionnaire de mots de passe, par exemple, va conserver en mémoire (flaggée explicitement comme “ne pas copier dans le fichier de mémoire virtuelle”) le mdp en clair juste le temps de l’exploiter, et garder tous les autres chiffrés. Un PDF sera probablement déchiffré d’un coup et gardé intégralement en mémoire pendant tout le processus d’affichage, avec un risque non négligeable que le texte clair se retrouve dans le fichier de mémoire virtuelle.
#6
60 pages de mots de passe ???
#7
Hmmmm Moui. Si j’en crois Kaspersky,
https://www.kaspersky.com/blog/36c3-pdf-encryption/33827/
Il y a moyen de véroler un pdf pour exfiltrer les informations, encore faut-il convaincre la victime d’ouvrir le fichier vérolé. Encore une fois, ce n’est pas le chiffrement lui-même qui est attaqué, mais tout ce qui tourne autour et qui n’est pas maîtrisé : une fois que le texte est déchiffré en mémoire, un attaquant y a accès par des moyens détournés en injectant du code.
Mais rien ne montre qu’il y a moyen de casser le chiffrement AES lui-même si tout ce dont tu disposes est le pdf chiffré (avec un mot de passe raisonnable, évidemment, pas
).
password01#8
En Comic Sans. Un éventuel attaquant devient malade à la page 3 et vomit sur le reste des pages, les rendant illisibles
#9
Moi j’imprime tous mes mots de passe en code barre, mais en passant dans un filtre captcha pour éviter que ce soit lu trop facilement… :)
#10
J’avoue avoir un peu de mal à comprendre le principe d’un PDF en lecture seule protégé par un mdp (*). Si tu peux le lire, il est donc en clair, et tu peux toujours copier son contenu dans un autre document, même sans connaître le mdp… À mon sens, c’est simplement cette copie du clair dans un autre document initialement vierge que le service en ligne a faite…
(*) Je comprends par contre la notion de signature électronique, qui garantit que le document n’a pas été modifié après qu’il a été signé, mais c’est une toute autre histoire. Et là aussi ça ne t’interdit pas de copier le texte dans un autre document, ça t’interdit juste de te faire passer pour le signataire d’origine.
#11
Y a systématiquement un pop-up qui donne le choix entre enregistrer ou pas l’information en question.
Maintenant je suis d’accord que l’enregistrement de ces données dans la navigateur n’est pas conseillée. Éventuellement sur Firefox, il vaut mieux dans ce cas activer le mot de passe maitre qui pose un obstacle au déchiffrement du coffre si le mot de passe en question est suffisamment robuste.
Je ne sais pas ce qui est possible de ce côté en option native pour les navigateurs basés sur Chromium
#12
Je ne comprends pas du tout ces besoins de stockage de mdp pour un particulier, des sites importants, j’en ai 5 et je les connais par coeur, le reste c’est un mdp générique.
#12.1
Le mdp générique, c’est bien ce qu’il ne faut pas faire, même si tu protèges les plus importants par un mdp spécifique. un site qui a sa base de mpd qui fuite et tous tes sites sauf 5 sont potentiellement compromis.
#12.2
Pour mon boulot, je dois avoir une centaine de mot de passe.
Une partie est “critique” et il y a des règles particulières pour la gestion de ceux ci (renouvellement auto tous les X mois, nombres de caractères, …).
Pour la partie perso, j’en ai encore plus même si une grande partie n’est pas “critique”.
#13
Je te remercie pour le lien, mais je n’étais pas dans ce cas de figure. Je parlais juste de la résistance d’AES256 sur un pdf en assumant que tout le reste était ok.
C’est justement ce point que je voulais mettre en avant. Comme tu le dis ton AES256 ne sert à rien avec un mot de passe faible. Mais un mot de passe faible qui se fait dériver ensuite est bien plus robuste. Pour info, avec hashcat sur une Gefore RTX 2060 de laptop j’arrive à ~ 16 MH/s pour un pdf (PDF 1.4 - 1.6 [Acrobat 5-8]) contre ~ 139 kH/s pour PBKDF2-HMAC-SHA1 + AES-256-CBC (donc avec dérivation de clé).
Dans le premier cas, je suis obligé de sortir le gros gros mot de passe (et donc de me le trimballer physiquement ou en dans ma mémoires). Tandis que dans le second, même password1 [à condition d’avoir une simple brute-force en face] peut tenir un peu plus longtemps.
Après, n’étant pas utilisatrice d’Acrobat je ne sais pas si les versions 5-8 sont récentes ou pas où si il y a eu des améliorations.
Si ton pdf vaut quelque chose (et un pdf chiffré est rarement “innocent” à priori), ça peut valoir le coût de mener une attaque.
#13.1
J’suis bien conscient de tout ça, mais y a-t-il encore quelqu’un qui ose faire de la crypto sans utiliser un hachage lent pour dériver la clé ?
Mais de fait je n’arrive pas à obtenir une spec à jour de l’algo de chiffrement (j’ai trouvé celui de PDF 1.3, c’est à pleurer - mais bon il était limité à 40 bits par les lois de l’époque). Après, quand je lis “MD5 et RC4 appliqué plusieurs fois” et autres “algorithmes gardés secrets pour plus de sécurité”, je continue à frémir.
Bon, bref, OTAN pour moi, le chiffrement des PDF semble bel et bien daubesque.
#14
Le mot de passe maître chiffre uniquement en local, non ? J’ai toujours compris que c’est une fonctionnalité utile si tu partages ton PC avec d’autres personnes physiques, il y a les documentations de Mozilla, Google et Microsoft concernant la sécurité du stockage des mots de passes dans le navigateur, maintenant j’ai pas tout en tête.
#14.1
Voici ce que je peux te dire à ce sujet sur la base de mon expérience perso et de la doc de Mozilla à ce sujet.
De base, Firefox (desktop/mobile) chiffre les identifiants enregistrés dans celui-ci.
Le simple démarrage de Firefox lance la procédure de déchiffrement pour permettre à l’utilisatrice ou l’utilisateur d’exploiter son coffre.
L’activation du mot de passe maitre va venir ajouter une couche de sécurité supplémentaire, le chiffrement du coffre sera cette fois basé sur ce mot de passe , évidemment le déchiffrement à l’ouverture de Firefox se fera uniquement avec la validation de ce même mot de passe.
Concernant Firefox Sync, le coffre est de nouveau chiffré sur la base du mot de passe du compte Firefox cette fois ci avant d’être envoyé vers les serveurs de Mozilla (on attend toujours la finalisation du portage de Firefox Sync en Rust pour l’auto hébergement).
Précisons que si un mot de passe maitre est paramétré, Firefox Sync ne peut accéder aux données du compte Firefox tant que le mot de passe n’est pas validé.
Sur Firefox mobile : pas de mot passe maitre, le logiciel a recours au mécanisme de verrouillage défini par la personne et propre à l’OS mobile (ex : empreinte digitale)
#15
Pfff tant de problèmes alors qu’il suffit de rien noter nulle part et de cliquer sur “j’ai oublié mon mot de passe”.
#16
Meilleur méthode, mêttre 1234 partout et c’est bon, rien besoin de stocker et tu l’as toujours en tête, facile et besoin de faire confiance à personne, t’es safe
#17
ça c’est parce que vous ne vous relisez jamais
Sinon il a raison , confier ses identifiants, password en externe c’est plus que risqué.
#18
Au tout début, j’avais un petit répertoire sur lequel je notais l’adresse du site, le login et mot de passe mais c’est très vite devenu fastidieux au fil du temps et j’ai cherché une solution viable et depuis j’utilise aussi keepass.
#19
#19.1
Pour Google, je ne me prononce pas car je n’utilise pas ses navigateurs, je ne sais pas si il existe un système de mot de passe maitre.
A noter tout de même que stocker ses mots de passe via un compte Google est déjà une forme de synchronisation.
A ce titre, je conseille vivement d’activer la double authentification sur le compte Google.
Parce-que ?
#20
Il me semble que oui, je l’ai déjà lu, mais comme je m’en sers pas quel que soit le navigateur que j’utilise, faudrait que je regarde la procédure, globalement, j’utilise Edge sur W11, Chrome sur Android et Firefox sur Fedora Workstation, j’aimerais que Google ajoute à Chrome une bascule pour désactiver JIT et que je puisse créer plusieurs instances du navigateur, c’est très facile à faire avec la version desktop.
C’est vrai tu as raison, j’utilise le 2FA (ainsi que pour mon compte Microsoft), d’ailleurs, j’ai la possibilité d’utiliser la clé privée de mon Pixel (basé sur Titan M) pour déverrouiller mon compte, c’est l’approche la plus sécurisée que j’ai actuellement en ma possession, le problème, c’est que ma connexion Bluetooth (oui je sais les problèmes avec le Bluetooth) a tendance à planter une fois sur deux, donc parfois, c’est fastidieux et ça m’énerve, c’est le seul défaut.
#21
Une copie du clair, ou alors une impression avec une imprimante PDF du document ouvert par un lecteur PDF. Dans les deux cas ce n’est plus le même document, mais une reproduction.
Sinon j’ai déjà vu des utilitaires qui permettent de casser la protection d’un fichier XLS par exemple, mais grâce à une collision, et donc sans retrouver le mot de passe d’origine. Il y a peut-être la même méthode pour les PDF.
#22
Et sinon un fichier texte dans un 7zip chiffré ?
#23
En vrai, go faire un club de sécurité niveau Snowden pour protéger ses mots de passes de la CIA. x)
Je plaisante mais si une bonne partie prend la sécurité numérique un peu trop à la légère, ici, on a tendance à la prendre trop à l’extrême.
(je précise que tout mon propos est pour un usage personnel, pas professionnel en environnement sensible)
Pour la confiance envers un autre service, on est bien obligé de faire confiance à quelqu’un pour notre système d’exploitation, nos logiciels, notre matériel ou encore notre opérateur internet. Faire confiance à un acteur de plus, même si c’est pour ses mots de passe (donc un peu plus sérieux), c’est pas un risque nécessairement plus élevé.
Pareil pour le risque de piratage, le plus gros risque n’est pas de se faire voler la copie du fichier chiffré mais plus d’avoir un logiciel sur l’ordinateur qui récupèrerait directement le mot de passe maître et ce qui va avec. Et même là, la plupart des cas de piratage passeront davantage par du hameçonnage ou de la contrefaçon d’interface de connexion. Quand c’est pas le site directement qui est piraté..
Peut-être qu’on se prend un peu trop la tête par rapport au risque, existant mais faible, d’être visé par une organisation avec des moyens plus importants que la moyenne. (et pour les environnements sensibles, on a des moyens supplémentaires qui mériterait d’être davantage abordé)
#24
Merci pour le rire x)
#24.1
La police s’appelle Comic Sans, pas Comic : donc, non, il ne faut pas rire !
#25
C’est ce que je fais depuis 1000 ans
#26
Hyper dangereux. Tu peux te retrouver avec une copie de ton fichier en clair dans un répertoire temporaire.
#26.1
Ouai mais après il chiffre le fichier sur le disque avant de l’effacer comme ça no-risk.
#26.2
Je pense aussi à l’indexation des fichiers qui peut aussi poser problème dans ce cas de figure.
#26.3
Exact lui je l’efface depuis 999 ans
#27
Tiens, j’y ai réfléchi un peu est si je devais créer ma propre solution:
Pour reconstituer le suffixe :
Si je donne un mauvais mot de passe maître, le hash sera incorrect, mais le déchiffrement ne ratera pas. L’algorithme me proposera donc un mot de passe, mais il sera incorrect. Un attaquant ne peut pas savoir si le mot de passe est correct ou non sans essayer de se logger avec (et il doit en plus connaître mon préfixe). Il ne peut donc pas simplement bruteforcer le fichier en local, il doit essayer le mot de passe sur le site, et il se fera probablement bloquer après x tentatives.
Avis ?
#28
Ou cacher le fichier dans une image parmi d’autres images. Par exemple avec StegHide. Je n’ai pas encore essayé mais l’astuce m’a semblé bonne.
#29
Brèche Lastpass : des données exposées quatre jours, mais pas de mots de passe selon l’entreprise
là
#29.1
Tout à fait pas les mots de passe, c’est quand même le principal dans cette histoire.
Et honnêtement, je n’ai pas encore vu passer d’article qui parle de fuites de mot de passe suite à la compromission des mécanismes de sécurité en place quelque soit le fournisseur de service.
Et quand je dis “fuite de mots de passe”, j’entends bien sûr “mots de passe en clair”.
Si une information de ce type a vu le jour par le passé, je souhaiterais en prendre connaissance.