Discussion :

[Olivier Famien]

La sécurité du réseau de LastPass a été compromise
L’entreprise suggère plusieurs mesures dont le changement du mot de passe maitre

L’entreprise de gestion des mots de passe en ligne LastPast vient d’annoncer que son réseau a été compromis vendredi dernier. Pour plus de fidélité, voici un extrait de la communication faite par LastPass à ses clients. « Nous souhaitons informer notre communauté que vendredi, notre équipe a détecté et bloqué immédiatement une activité douteuse sur notre réseau. D’après nos investigations, nous n’avons aucune preuve que les données cryptées de nos utilisateurs ont été compromises, tout comme l’accès aux comptes des utilisateurs. Les investigations ont cependant démontré que les adresses e-mail des comptes LastPass, les indices de mots de passe, le salage, et le hachage d’authentification ont été compromis ».

Bien que la firme ne donne pas de détails sur le fait que les données volées aient pu être exploitées pour accéder aux comptes des utilisateurs, elle les incite néanmoins à suivre un certain nombre de recommandations en vue de garantir la sécurité de leurs données sur le site. « Nous demandons à tout utilisateur se connectant depuis un nouvel appareil ou depuis une nouvelle adresse IP de valider en premier lieu leur compte via leur adresse e-mail, à moins que vous n’utilisiez l’authentification multifacteur. Comme précaution supplémentaire, nous demanderons également à nos utilisateurs de changer leur mot de passe maître ».

Concernant cette dernière mesure de sécurité de changement du mot de passe maitre, une invitation a été envoyée aux utilisateurs qui sont directement affectés par le vol de ces données. Les autres utilisateurs de la plateforme n’ayant pas reçu de mail d’invitation pour changer leur mot de passe maitre ne sont pas obligés de le faire à moins de réutiliser le mot de passe maître comme mot de passe pour un autre site web. Dans ce cas, « vous devez remplacer les mots de passe de ces autres sites ».

LastPass rassure toutefois ses clients en déclarant que « nous sommes confiants en nos mesures de cryptage pour couvrir la protection de la majorité de nos utilisateurs. LastPass renforçant le hachage d’authentification par un salage aléatoire et 100,000 itérations côté serveur PBKDF2-SHA256, en plus des itérations effectuées côté client. Ce renforcement supplémentaire rend difficile une attaque des hachages volés ».

Il faut également rappeler que cette compromission du réseau de LastPass n’est pas la première du genre. Quatre ans plus tôt, et plus précisément en mai 2011, un incident similaire s’était produit sur le site. LastPass avait demandé à ses clients de changer leurs mots de passe maitre, mais cette mesure s’est avérée difficile à réaliser à cause de la ruée des personnes désirant effectuer le changement en même temps.

Comme en 2011, LastPass souligne qu’elle travaille en collaboration avec des experts en sécurité pour offrir le meilleur de la sécurité à ses clients.

Source : blog Last Pass

Et vous ?

Que pensez-vous de cette exposition des données de LastPass ?

[Voyvode]

Centraliser la gestion des mots de passe sur un serveur est une faiblesse, car cela révèle automatiquement l’emplacement de stockage.

De plus, centraliser la gestion des mots de passe peut sembler pratique, mais cela généralise les conséquences d’une compromission : compromettre la sécurité d’un individu a généralement bien moins de conséquences que compromettre un serveur contenant les informations de milliers ou de millions de clients.

Des gestionnaires comme KeePass ou 1Password me paraissent plus surs dans la mesure où ils laissent le choix de l’emplacement de stockage.

[yoyo3d]

hallucinant!!! je regardais cette semaine une petite émission (je ne sais plus sur quelle chaine...) qui expliquait comment gérer tous nos MdP. on nous vantait les mérites des site de gestion de MdP.... et je me faisais la remarque que ce passe t-il si quelqu'un décide d'attaquer directement le coffre fort...
ba voila, j'ai ma réponse.

pour ma part, c'est con, mais j'ai mon p'tit pense bête dans un coin..

[Sodium]

On vit une époque formidable, avec d'un côté la multiplication d'annonces de ce genre incitant à la parano et de l'autre une actualité dominée par les objets connectés, véhicules qui se conduisent tout seul, hardware ayant cédé sa place au Cloud...
On va droit dans le mur, avec les deux pieds sur l'accélérateur.

[Ymer Leahcim]

le stockage en ligne de mots de passe, une base de données de mots passe en ligne...Quelle erreur d'avoir pu croire que c'était fiable.
Cela est aussi stupide de stocker un mot de passe en ligne que de stocker des photos perso sur un smartphone/tablette/ordinateur cloudé.

il est évident que cette communication que la société fait à l'instant , est pour se prémunir des problèmes juridiques à venir.
Je n'ai pas lu les CGU de leur logiciel, mais il est à parier qu'il doit y avoir une ligne du genre :
en cas de problème de sécurité, la société lastpass ne pourra être tenu responsable....que vous utilisez ainsi notre solution en toute connaissance de cause....

[Ymer Leahcim]

Des gestionnaires comme KeePass ou 1Password me paraissent plus surs dans la mesure où ils laissent le choix de l’emplacement de stockage.

Non plus car ces deux logiciels utilisent des librairies partagées pour l'exécutable compilé.
Pour faire plus simple , toto.exe utilise jpg.dll de l'ordinateur local pour s'éxécuter. Donc si jpg.dll est compromis...toto.exe est compromis.
Idem pour une version mac ou opensource, si toto.sh utilise jpg.h par exemple, et que dans jpg.h il y a un code qui dit de rediriger les frappes claviers ou infos sur un autre canal,...bref c'est compromis.


Un soft local fiable devra être écrit à 100% sans librairie locale ni partagée.. A part en assembleur pur, je ne vois pas comment en 2015 un language de programmation peut encore faire ça...

Et encore une fois, ne serait que le nom "1password", "keepass" est déjà une faute de sécurité.
Faut vraiment être pas malin pour écrire "boite à bijoux de grandes valeurs" sur une conteneur.

Dans mes programmations et modélisations passées, j'ai toujours nommé les champs et attributs login et password différement des trops évidents login et password.
Par exemple, login est remplacé par tooltips (infobulle) et password par "version" ou "avatarJPG" .
Quand un pirate obtient l'accès à une liste d'informations sensible, il cherche les champs login-password et n'ira pas rapidement fouiller dans les autres champs qui ne contiennent pas de données sensible par nature...

[Sodium]

le stockage en ligne de mots de passe, une base de données de mots passe en ligne...Quelle erreur d'avoir pu croire que c'était fiable.
Cela est aussi stupide de stocker un mot de passe en ligne que de stocker des photos perso sur un smartphone/tablette/ordinateur cloudé.

Croire que c'est fiable à 100% non (d'ailleurs qu'est-ce qui fiable à 100% ?), mais par contre dans la vraie vie j'ai besoin de gérer des dizaines de mots de passe pour des dizaines de clients différents, j'ai besoin que mes collègues puissent y avoir accès et que tout soit synchronisé en permanence, et j'ai également besoin de pouvoir y accéder en cas d'urgence en dehors des heures de boulot.

[Ymer Leahcim]

Croire que c'est fiable à 100% non (d'ailleurs qu'est-ce qui fiable à 100% ?), mais par contre dans la vraie vie j'ai besoin de gérer des dizaines de mots de passe pour des dizaines de clients différents, j'ai besoin que mes collègues puissent y avoir accès et que tout soit synchronisé en permanence, et j'ai également besoin de pouvoir y accéder en cas d'urgence en dehors des heures de boulot.

biensûr, mais dans ce cas on ne met pas au même endroit les mots de passe et les logins.
par exemple, on a un fichier/base pour les mots de passe
et d'un autre, un fichier avec les logins
et on garde humainement (jamais écrite) le moyen de faire le lien entre un login et le mot de passe.

ou alors (solution que je tolère), on couple les logins et mot de passe dans un tableau mais chaque salarié sait qu'il faut enlever le Xeme caractère pour connaitre le vrai mot de passe ou le vrai login. Comme ça , le risque est limité qu'aux salariés et pas au vol de la liste par un externe.
Dans tous mes mots de passe perso que j'écris, je j'inverse toujours 2 caractères comme si ça je perds mon papier ou qu'on me lit derriere l'épaule ou m'espionne, alors je sais que j'ai une boué de sauvetage.

Et un bon système de login/identification devrait vous avertir des erreurs de login pour que vous soyez conscients qu'une personne a essayé votre mot de passe écrit....
C'est comme indiquer la dernière connexion : primordiale!
Je me demande pourquoi les banques n'indiquent ces infos dans les espaces de gestions de compte en ligne...
Même Amazon le fait!

[NSV]

C'est comme indiquer la dernière connexion : primordiale!
Je me demande pourquoi les banques n'indiquent ces infos dans les espaces de gestions de compte en ligne...
Même Amazon le fait!

ING Direct le fait et en plus sur le ton de la plaisanterie :
"Bien sûr, votre dernière connexion est toute récente (le 13 juin 2015 à 16h53 pour être exact), mais vous voir est toujours un plaisir. "

[Voyvode]

Non plus car ces deux logiciels utilisent des librairies partagées pour l'exécutable compilé.

Et alors ? Si une bibliothèque a une faiblesse, elle sera patchée. Si une bibliothèque est modifiée quelque part dans le monde pour exécuter du code malicieux, cette modification ne se répercutera pas partout dans le monde comme par magie.

Un soft local fiable devra être écrit à 100% sans librairie locale ni partagée.. A part en assembleur pur, je ne vois pas comment en 2015 un language de programmation peut encore faire ça...

Tu déplaces le problème. Si ton code sans bibliothèque a une faiblesse, toutes les copies que tu auras distribuées l’auront aussi. Je ne vois vraiment pas en quoi cela change quelque chose de centraliser tout le code dans l’exécutable.

Et encore une fois, ne serait que le nom "1password", "keepass" est déjà une faute de sécurité.
Faut vraiment être pas malin pour écrire "boite à bijoux de grandes valeurs" sur une conteneur.

Appelle ton gestionnaire de mots de passe « Mon Petit Poney » ou « Canard WC » si tu veux, mais ça finira par se savoir.

Dans mes programmations et modélisations passées, j'ai toujours nommé les champs et attributs login et password différement des trops évidents login et password.
Par exemple, login est remplacé par tooltips (infobulle) et password par "version" ou "avatarJPG" .
Quand un pirate obtient l'accès à une liste d'informations sensible, il cherche les champs login-password et n'ira pas rapidement fouiller dans les autres champs qui ne contiennent pas de données sensible par nature...

Ça obscurcit le code, ce n’est pas pérenne, et ça ne change pas grand-chose. En général, un pirate se moque du nom de la variable ou de la colonne au moment de l’attaque. Bien souvent, son objectif est de pénétrer un système pour faire rapidement des dumps et les étudier tranquillement chez lui.

biensûr, mais dans ce cas on ne met pas au même endroit les mots de passe et les logins.
[…]
Dans tous mes mots de passe perso que j'écris, je j'inverse toujours 2 caractères comme si ça je perds mon papier ou qu'on me lit derriere l'épaule ou m'espionne, alors je sais que j'ai une boué de sauvetage.

J’ai plus de 30 identifiants. Si j’utilise un gestionnaire de mots de passe, c’est justement pour m’épargner toutes ces opérations.

Et un bon système de login/identification devrait vous avertir des erreurs de login pour que vous soyez conscients qu'une personne a essayé votre mot de passe écrit....
C'est comme indiquer la dernière connexion : primordiale!

Là, nous sommes totalement d’accord ! J’ajouterai qu’afficher quelques informations sur la machine (secteur géographique, IP, navigateur, OS…) simplifie la reconnaissance d’une connexion suspecte.

[BufferBob]

ouai finalement faut pas tomber dans l'excès quoi... j'irais pas stocker mes mdp dans le clawèd par principe mais utiliser keepass en local ça me semble tout indiqué et plus sain que d'écrire tous mes pass sur un bout de papier, faire un password manager par moi même ou n'avoir qu'un unique mot de passe partout

la différence c'est que si on me vole ma db keepass c'est vraiment qu'on m'a ciblé et pas que je faisais partie d'une db contenant des milliers de credentials et forcément plus prompt à attirer les pirates

en sécurité c'est la différence entre "risque" et "menace" non ?

[Ymer Leahcim]

J’ai plus de 30 identifiants. Si j’utilise un gestionnaire de mots de passe, c’est justement pour m’épargner toutes ces opérations.

si tes 30mdp sont perso, dans ce cas tu utilises un moyen memoperso pour facilement les retenir :
site+pseudo+info chiffrée (date naissance)
pour ton login ou mdp cdsiscount :cdiscountVoïvode12011977
pour ton gmail : gmailVoïvode12011977
..etc
comme ça tu n'en a qu'un seul à retenir c'est la ptiote méthode. Et ta méthode tu la gardes pour toi , même pas en parler à ta femme! pour elle, tu lui en trouves une autre : pointure de chaussure + site+ nom de son amour

Et alors ? Si une bibliothèque a une faiblesse, elle sera patchée. Si une bibliothèque est modifiée quelque part dans le monde pour exécuter du code malicieux, cette modification ne se répercutera pas partout dans le monde comme par magie.

si une bibliothèque a une faiblesse, l'éditeur se déresponsabilise en cas d'attaque/piratage par se biais et ne sera pas tenu de corriger cette faille. c'est comme installer une alarme en laissant la porte ouverte...

Tu déplaces le problème. Si ton code sans bibliothèque a une faiblesse, toutes les copies que tu auras distribuées l’auront aussi. Je ne vois vraiment pas en quoi cela change quelque chose de centraliser tout le code dans l’exécutable.

si une une partie de keepass par exemple utilises une dll local (vb6.dll par exemple), alors le pirates peut changer cette dll et poser la sienne. Dans son code source, le pirate aura pris soin de brouiller/rediriger les messages pour intervenir dans keepass , et ça tout en laissant le code original de la dll vb6.dll. Une dll est si facilement décompilable que c'est fréquent maintenant. C'est comme s'inscrire dans un partie politique en étant qu'une autre étiquette pour observer et proposer ses idées.... C'est pas le cheval de troie mais plutôt la technique du rootkit.

Ça obscurcit le code, ce n’est pas pérenne, et ça ne change pas grand-chose. En général, un pirate se moque du nom de la variable ou de la colonne au moment de l’attaque. Bien souvent, son objectif est de pénétrer un système pour faire rapidement des dumps et les étudier tranquillement chez lui.

biensur que non car ce changement est inscrit dans les specs, cahier des cahrges et les développeur le savent et en prennent compte.
Ayant déjà travaillé avec Thales (haut niveau de sécurité), là chaque champs en base de données n'est pas nommé mais remplacé par un acronyme du genre field12345, field4567489, field646464
Et dans l'outil de développement il ya tous le nécessaire pour remplacer et programmer avec les champs d'origine.
Ainsi, bon courage et de rétro-analyse à celui qui obtiendra un dump de la base de données ou du code source.

[Voyvode]

si tes 30mdp sont perso, dans ce cas tu utilises un moyen memoperso pour facilement les retenir :
site+pseudo+info chiffrée (date naissance)
pour ton login ou mdp cdsiscount :cdiscountVoïvode12011977
pour ton gmail : gmailVoïvode12011977
..etc
comme ça tu n'en a qu'un seul à retenir c'est la ptiote méthode. Et ta méthode tu la gardes pour toi , même pas en parler à ta femme! pour elle, tu lui en trouves une autre : pointure de chaussure + site+ nom de son amour

Cette technique génère des mots de passe assez longs mais à entropie faible. De plus, un mot de passe ne devrait pas contenir d’information relative à l’utilisateur.

si une bibliothèque a une faiblesse, l'éditeur se déresponsabilise en cas d'attaque/piratage par se biais et ne sera pas tenu de corriger cette faille. c'est comme installer une alarme en laissant la porte ouverte...

Si une bibliothèque a une faiblesse, il est effectivement de la responsabilité de son créateur de la corriger. Si aucune correction n’est faite, l’éditeur devra changer de bibliothèque. Si l’éditeur ne répercute pas rapidement cette correction, il est plus que temps pour le client d’aller voir ailleurs.

si une une partie de keepass par exemple utilises une dll local (vb6.dll par exemple), alors le pirates peut changer cette dll et poser la sienne. Dans son code source, le pirate aura pris soin de brouiller/rediriger les messages pour intervenir dans keepass , et ça tout en laissant le code original de la dll vb6.dll. Une dll est si facilement décompilable que c'est fréquent maintenant. C'est comme s'inscrire dans un partie politique en étant qu'une autre étiquette pour observer et proposer ses idées.... C'est pas le cheval de troie mais plutôt la technique du rootkit.

Si un pirate peut modifier une DLL locale, c’est qu’il a réussi à obtenir un accès administrateur. Dans ce cas, il a tous les pouvoirs sur ta machine, peut modifier n’importe quel fichier, te keylogger et lire tes caches comme il veut. Ni un gestionnaire de mot de passe ni ta seule mémoire ne pourront te sauver : la sécurité du système est à revoir.

biensur que non car ce changement est inscrit dans les specs, cahier des cahrges et les développeur le savent et en prennent compte.
Ayant déjà travaillé avec Thales (haut niveau de sécurité), là chaque champs en base de données n'est pas nommé mais remplacé par un acronyme du genre field12345, field4567489, field646464
Et dans l'outil de développement il ya tous le nécessaire pour remplacer et programmer avec les champs d'origine.
Ainsi, bon courage et de rétro-analyse à celui qui obtiendra un dump de la base de données ou du code source.

Ta manière de présenter les choses laissait penser que tu faisais ce travail manuellement.
C’est bien de faire de l’obfuscation, pourtant c’est loin d’être suffisant face à quelqu’un de déterminé.

[Ymer Leahcim]

j'en parlais plus haut, quand une application si super qu'elle soit, fait appelle à des bibliothèque externe, ou que ces dernières aient les clés d'intéractivités avec toutes les applis, alors elles sont aussi la défaillance de l'application super !

voilà l'exemple sur mac :

http://www.clubic.com/antivirus-secu...aire-mots.html

[Voyvode]

J’ai regardé sur Ars Technica et AppleInsider, et rien ne dit qu’une bibliothèque en particulier est la cause de ces failles. C’est la mise en œuvre du sandboxing par Apple qui pose problème ici.

[Ymer Leahcim]

J’ai regardé sur Ars Technica et AppleInsider, et rien ne dit qu’une bibliothèque en particulier est la cause de ces failles. C’est la mise en œuvre du sandboxing par Apple qui pose problème ici.

je vois bien que tu aimes avoir le dernier mot, mais je ne comprends pas que tu ne comprennes pas, c'est pourtant clair en anglais :

The consequences are dire," they wrote in a research paper titled Unauthorized Cross-App Resource Access on MAC OS X and iOS. "For example, on the latest Mac OS X 10.10.3, our sandboxed app successfully retrieved from the system's keychain the passwords and secret tokens of iCloud, email and all kinds of social networks stored there by the system app Internet Accounts, and bank and Gmail passwords from Google Chrome." Referring to interprocess communication, which is the tightly controlled and Apple-approved mechanism for one app to interact with another and the Bundle ID token used to enforce sandbox policies,

[Voyvode]

je vois bien que tu aimes avoir le dernier mot

Tu fais un procès d’intention.
Je prends la peine d’argumenter point par point. Argumenter, c’est expliquer pourquoi on pense avoir raison, mais cela permet aussi à un contradicteur de réfuter le raisonnement. Quelqu’un qui veut avoir le dernier mot pour le plaisir ne se risque pas à cela et, au contraire, préfère prendre le dessus par des procédés sophistiques.

mais je ne comprends pas que tu ne comprennes pas, c'est pourtant clair en anglais :

The consequences are dire," they wrote in a research paper titled Unauthorized Cross-App Resource Access on MAC OS X and iOS. "For example, on the latest Mac OS X 10.10.3, our sandboxed app successfully retrieved from the system's keychain the passwords and secret tokens of iCloud, email and all kinds of social networks stored there by the system app Internet Accounts, and bank and Gmail passwords from Google Chrome." Referring to interprocess communication, which is the tightly controlled and Apple-approved mechanism for one app to interact with another and the Bundle ID token used to enforce sandbox policies,

En quoi cet extrait montre que le système des bibliothèques est à l’origine de ce problème ?
Par ailleurs, un appel à un autre programme ne posent pas les mêmes problèmes de sécurité qu’un appel à une bibliothèque. C’est pour cela que le sandboxing existe.
Enfin, ces failles ne sont exploitables qu’en obtenant un accès au compte de l’utilisateur et ne permettent même pas d’obtenir les mots de passe déjà stockés dans 1Password.

[Édition : AgileBits a publié un billet intéressant sur ces failles.]