Faille Heartbleed : le danger vient de ceux qui gardent le silence

Faille Heartbleed : le danger vient de ceux qui gardent le silence

Il faut toujours se méfier du Silence © Doctor Who

Avatar de l'auteur
David Legrand

Publié dans

Internet

11/04/2014 11 minutes
91

Faille Heartbleed : le danger vient de ceux qui gardent le silence

Depuis le début de la semaine, le petit monde de la sécurité est affolé par une faille : Heartbleed. Nous vous en avions parlé en détail par ici, ou de manière plus simple par là, mais l'ampleur des dégâts ne semble pas encore être perçue de manière claire. Alors que tout le monde se focalise sur les géants du net grâce à un article de Mashable, vous devez en fait surtout vous méfier de ceux qui ne disent rien et qui constituent le gros des troupes.

La faille Heartbleed, qui touche certaines versions d'OpenSSL et a mis à disposition d'attaquants les données sensibles d'internautes depuis des mois voire des années, commence sérieusement à faire parler d'elle. Annoncée lundi soir, elle n'a eu droit à sa dépêche AFP et donc à son réel début de traitement médiatique que mercredi matin.

Heartbleed dévoile aussi une faille du traitement médiatique

Si certains sites se sont alors emparés de l'affaire à coup de guides et autres conseils, on ne peut pas dire que ce soit le fond du problème qui ait intéressé la majorité de nos confrères. Preuve en est, ce matin c'était les déclarations du développeur ayant introduit le bug, Robin Seggelmann, qui focalisait les attentions, et rien d'autres.

 

Hier, c'était Mashable qui était à l'origine d'un regain médiatique important. En effet, si vous avez lu des dizaines de sites vous dire qu'il fallait changer vos mots de passe Facebook, Google ou même OkCupid (!), c'est grâce au site américain et à ce papier. Tous disaient à peu près la même chose, la CNIL a même recommandé plusieurs fois l'article du Monde qui reprenait ces conseils, qui, s'ils ne sont pas mauvais, n'ont pas vraiment de sens dans le cas qui nous occupe.

 

Crédit Mutuel Heartbleed

Du coup, on doit changer son mot de passe au Crédit Mutuel ou pas ?

 

En effet, la faille a été découverte il y a un certain temps maintenant, et les équipes qui ont décidé de la rendre publique ont préparé le terrain. Les géants du web ont été prévenus en amont et ont ainsi pu se mettre à jour très rapidement (voir ce billet de Google). Globalement, une majorité des sites concernés par l'article de Mashable et de ses différentes reprises ont donc été très réactifs, seul le cas de Yahoo! a fait les gros titres puisque la société a laissé fuiter des identifiants et des mots de passe en clair pendant près d'une journée, avant de corriger la faille et de l'annoncer via une note technique et l'un des comptes Twitter du groupe. Et c'est tout.

 

Et c'est bien là tout le problème. Car après tout, que la presse ait tardivement ou mal traité la question, c'est une chose. Sur les sujets assez techniques, c'est même malheureusement encore trop souvent le cas, bien que dans des situations si graves, ce puisse être une vraie préoccupation dont les rédactions devraient se saisir.

Lorsque des données sont en fuite, il faut savoir prendre les bonnes décisions

Mais les sociétés concernées et touchées, elles, n'ont quasiment pas réagi. Il y avait pourtant quatre phases minimales à respecter : 

  • Couper l'accès aux serveurs touchés
  • Mettre à jour OpenSSL, redémarrer les services concernés
  • Renouveler les certificats par sécurité
  • Informer les clients

Rien que sur la première étape, certains sont allés bien trop lentement. En effet, nous avons évoqué le cas de banques et de revendeurs qui, bien qu'informés, n'ont rien coupé du tout, ont laissé la faille béante, et ont mis entre 24 heures et 48 heures pour réagir. Bref, un manque de professionnalisme certain, qui ne s'est pas arrêté là. Car le renouvellement des certificats n'est pas encore systématique, alors que la clef privée a potentiellement pu être récupérée. Un coup de poker qui sera lourd à digérer si jamais cela venait à être le cas.

 

Et dans tous les cas, une fois la mise à jour effectuée, l'information des clients potentiellement touchés n'a pas été mise en place. Qui a reçu un mail de sa banque, ou d'un revendeur, lui indiquant qu'en raison de la faille Heartbleed, des données personnelles avaient potentiellement pu être récupérées ? Au sein de l'équipe, nous avons seulement reçu deux mails de ce genre : un de la part d'IFTTT et un second de la part de Wunderlist. Rien de plus. D'autres ont choisi de communiquer via leur blog afin d'informer sur leur situation, mais les cas français sont rares.

 

IFTTT Heartbleed

Touché, IFTTT a joué la transparence et propose de répondre aux questions de ses utilisateurs

La communication de crise, c'est un métier (souvent mis de côté)

La pire constatation que nous ayons faite pendant toute cette semaine tient d'ailleurs au comportement des sociétés sur les réseaux sociaux. Si celles qui n'ont pas été touchées ont été assez promptes à réagir, ce n'est pas le cas des autres. Le Crédit Agricole a ainsi répondu assez rapidement à nos questions et à ses clients, en indiquant que « les dispositifs de sécurité mis en place par Crédit Agricole pour protéger ses serveurs web n’utilisent pas la bibliothèque open-ssl défaillante. Nos sites de banque en ligne ne sont donc pas concernés par cette faille. » Mise en cause dans un premier temps par un billet publié par Le Plus du Nouvel observateur, la Société Générale a de son côté démenti avoir été touchée.

 

 

Les exemples d'internautes interpellant leur banque sur Twitter les premiers jours sans aucune réponse de leur part, alors qu'ils souhaitaient savoir s'ils pouvaient se connecter à leur compte en ligne sont néanmoins légion. Heureusement, depuis ces dernières ont commencé à répondre au cas par cas, mais pas de manière globale, avec une alerte sur leur site par exemple.

 

On a même relevé le cas du Crédit Mutuel qui indique ne pas avoir été touché par la faille. Si cela est sans doute vrai pour le service d'accès aux comptes, ce n'est pas le cas de leur service de paiement en ligne proposé à leurs clients qui n'a été corrigé que mercredi matin. Le compte n'a d'ailleurs pas répondu à nos interrogations sur le sujet :

 

En France, personne pour mettre de l'ordre, pas même la CNIL

Mais ces incertitudes et cette cacophonie ont une raison : personne ne se charge de réguler les comportements dans ce genre de cas. Même les services de l'état n'ont pas communiqué sur la faille et ses conséquences pour ce qui les concerne. Aucune recommandation générale n'a été établie, alors que dans d'autres pays, tout se passe de manière bien plus transparente. Ces dernières heures, on a ainsi vu le Conseil du Trésor Canadien annoncer la fermeture pure et simple de tous les systèmes qui n'étaient pas à jour. Et alors que des produits aussi sensibles que des routeurs de Cisco et Juniper sont concernés, on voit la réserve fédérale américaine demander à ses banques de mettre de l'ordre le plus vite possible.

 

Chez nous ? Rien. Interrogée sur le sujet, la CNIL n'était pour le moment pas disponible pour nous répondre. Hormis quelques retweets, elle n'a d'ailleurs toujours pas communiqué sur Heartbleed, alors qu'elle est le garant de nos données personnelles. D'ailleurs en matière de fuite de données, il ne semble y avoir aucune obligation pour les services en ligne. Les seuls qui doivent communiquer auprès de la Commission en cas de problèmes sont les opérateurs et les FAI, comme ce fût le cas d'Orange il y a quelques mois. Cela est rappelé sur cette page qui précise que « L'obligation de notifier à la CNIL les violations de données à caractère personnel concerne uniquement les fournisseurs de services de communications électroniques au public, tels que définis par l'article L. 33-1 du code des postes et des communications électroniques. »

 

Espérons tout de même que la CNIL finira par se saisir de ce dossier et demandera des comptes à tous ceux qui ont laissé fuiter les données sensibles de leurs clients, sans les prévenir et sans même mettre en place de procédure d'information.

 

Heartbleed Secure.darty.com

Darty aura mis deux jours à corriger la faille, et n'a pas coupé l'accès à son service en attendant

 

Car ceux-ci sont sans doute nombreux, et ce sont pour le moment les plus silencieux. Nous avions par exemple donné le cas de Darty, dont le serveur sécurisé était concerné, laissant des identifiants et des mots de passe, entre autres, à la portée de n'importe quel attaquant pendant deux jours. Heureusement, la faille a été corrigée mercredi en fin de journée et le certificat mis à jour hier.

 

Dans un premier temps, le revendeur a cessé de nous répondre, et son service presse n'a pas répondu à nos questions sur le sujet, sur ce qui sera mis en place pour informer les clients et ce qui sera fait, notamment dans le cas où ils verraient leurs comptes piratés suite à cette fuite. Des cas qui pourraient, si rien n'est fait, terminer sur le bureau des associations de consommateurs, qui devraient elles aussi finir par se pencher sur la question. Finalement, une réponse nous a été apportée, et les clients seront contactés.

Changer ses mots de passe maintenant, ou apprendre à gérer sa sécurité ?

Reste maintenant la question des mots de passe. Devez-vous les changer, et devez-vous le faire uniquement sur des sites américains ? Contrairement à ce que conseillent plusieurs de nos confrères, il ne faut pas le faire partout, tout de suite. En effet, il faut s'assurer qu'un site ne soit pas ou plus concerné avant de changer votre mot de passe. Si jamais cela était effectué trop tôt, le nouveau mot de passe pourrait fuiter à son tour.

 

Néanmoins, à terme, vous devrez changer TOUS vos mots de passe, sur TOUS les services que vous utilisez. Il faudra néanmoins respecter quelques règles, en ayant en tête une chose : la sécurité amène forcément de la complexité. Vouloir éviter tous les problèmes en utilisant le nom du chien de la famille et la date de naissance de la petite dernière comme mot de passe, même sur des sites sensibles, ne fait que vous exposer plus à un potentiel piratage de vos comptes. Vous n'avez jamais eu de problème ? C'est aussi ce que disent ceux qui n'ont jamais fait de sauvegarde de données... jusqu'au jour où ils perdent tout. 

 

L'outil informatique impose des attitudes qui se doivent d'être saines pour vous éviter des tracas importants tels que les usurpations d'identités, l'accès frauduleux à vos comptes, etc. Vous devez donc impérativement prendre ces questions au sérieux.

 

Piratage

 

La CNIL propose déjà un guide de base pour ce qui est de choisir vos mots de passe. Mais cela n'est pas tout. N'oubliez pas d'utiliser des mots de passe différents, surtout sur les services sensibles, et si possible de les renouveler de temps en temps, sans attendre qu'une faille énorme touche une majorité de sites web. De plus, sur des sites importants comme ceux de votre banque, les réseaux sociaux, l'accès à vos emails, il existe en général des procédures de sécurité complémentaires comme l'authentification en deux étapes (2FA), le fait d'indiquer si vous êtes sur un ordinateur de confiance ou non : utilisez-les !

 

Et la prochaine fois que vous entendez parler d'une faille importante et vérifiée, pas comme dans le cas des faux bugs Facebook : faites passer le message, informez vos proches, faites dans la pédagogie, et ce, que la presse joue correctement son rôle ou non. Si les réseaux sociaux servent effectivement à partager en masse des photos de chats trop mignons, ils peuvent aussi être une arme décisive lorsqu'il s'agit de faire passer une information saine et utile.

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Heartbleed dévoile aussi une faille du traitement médiatique

Lorsque des données sont en fuite, il faut savoir prendre les bonnes décisions

La communication de crise, c'est un métier (souvent mis de côté)

En France, personne pour mettre de l'ordre, pas même la CNIL

Changer ses mots de passe maintenant, ou apprendre à gérer sa sécurité ?

Commentaires (91)


Une bonne vulgarisation de Heartbleed par XKCD

http://xkcd.com/1354/

(désolé si ça a déjà été posté)




Du coup, on doit changer son mot de passe au Crédit Mutuel ou pas ?



On change de banque ! <img data-src=" />




Il faut toujours se méfier du Silence © Doctor Who



<img data-src=" />




Et la prochaine fois que vous entendez parler d’une faille importante et vérifiée, pas comme dans le cas des faux bugs Facebook : faites passer le message, informez vos proches, faites dans la pédagogie, et ce, que la presse joue correctement son rôle ou non. Si les réseaux sociaux servent effectivement à partager en masse des photos de chats trop mignons, ils peuvent aussi être une arme décisive lorsqu’il s’agit de faire passer une information saine et utile.

Typiquement le genre d’infos que je ralie, mais que personne ne lit….<img data-src=" />




Le Crédit Agricole a ainsi répondu assez rapidement à nos questions et à ses clients, en indiquant que « les dispositifs de sécurité mis en place par Crédit Agricole pour protéger ses serveurs web n’utilisent pas la bibliothèque open-ssl défaillante. Nos sites de banque en ligne ne sont donc pas concernés par cette faille. »



J’aime ma banque <img data-src=" />


Du coup, hadopi elle en dit quoi de ce manque de sécurisation ?

(vendredi soir, mon troll est fatigué et est déjà partie en week end mentalement)




Néanmoins, à terme, vous devrez changer TOUS vos mots de passe, sur TOUS les services que vous utilisez.



Pour quelle raison liée à cette faille faudrait-il changer tous les mots de passe ?



Je serai un peu plus mesuré :




  • Changer les mots de passe des sites à qui on l’a fourni entre le moment où la faille a été divulguée et celui où le site a supprimé la faille : plein de gens ont pu récupérer votre login/ mot de passe en utilisant la faille.

  • Pour les sites vulnérables où on s’est connecté sans fournir le mot de passe (utilisation de coockie pour mémoriser la connexion), il faut invalider le cockie : déconnexion et une fois la faille corrigée reconnexion avec mot de passe. Plein de gens ont pu récupérer votre coockie.

  • si l’on considère que les mots de passes ont pu être récupéré par ce moyen avant la divulgation de la faille, changer aussi de mot de passe. Cela est quand même moins probable et peut être fait sans précipitation. Là, seuls ceux qui connaissaient cette faille avant qu’elle ne soit divulguée ont pu récupérer votre mot de passe et cela depuis un moment (2 ans) et ils ont peut-être déjà eu le temps de l’utiliser.



  • Enfin, inutile de changer de mot de passe si le site n’a jamais été vulnérable à cette faille : sites de Microsoft par exemple qui n’utilise pas openSSL.



    Bon, je sais, le discours est un peu plus complexe … que : changer tous vos mots de passe.


Je viens de contacter la Société Générale à ce sujet.

Ils m’ont rappelé pour me dire que leur site logitelnet n’était pas concerné.

Au cas où, j’ai enregistré la conversation …


Un petit logiciel du genre keepass est d’ailleurs bien pratique, mais vu que c’est libre, il y a p-e une faille <img data-src=" />



Sinon pour le Crédit Mutuel de Bretagne c’était bon (CMB, hop ça c’est fait).


ça me fait penser qu’il y a quelques mois une grande quantité de compte gmail qui se faisait pirater, coïncidence?

Personnellement, pas de problème de ce coté là, me sert pas des service liés.




Il faut toujours se méfier du Silence © Doctor Who



<img data-src=" />




Néanmoins, à terme, vous devrez changer TOUS vos mots de passe, sur TOUS les services que vous utilisez. Il faudra néanmoins respecter quelques règles, en ayant en tête une chose : la sécurité amène forcément de la complexité. Vouloir éviter tous les problèmes en utilisant le nom du chien de la famille et la date de naissance de la petite dernière comme mot de passe, même sur des sites sensibles, ne fait que vous exposer plus à un potentiel piratage de vos comptes. Vous n’avez jamais eu de problème ? C’est aussi ce que disent ceux qui n’ont jamais fait de sauvegarde de données… jusqu’au jour où ils perdent tout.





Le soucis dans ce genre de cas c’est de définir le terme. Avec les entreprises qui ne communiquent pas comment savoir si le nécéssaire a été fait ou pas pour changer les mot de passe en tout sécurité ?



N’y a t’il pas une projet de loi européen en cours obligeant les fournisseurs de services à notifier les incidents ?



Perso, j’ai pris la décision de notifier mes contacts facebook. J’ai peut être eu tord mais je leur ai conseillé de faire un changement de mot de passe sur tout les services en ligne contenant des info sensibles.








fred42 a écrit :









On ne sait pas ce qui a fuité, on ne sait pas ce qui pourra être exploité, maintenant ou plus tard. Donc oui, il vaut mieux tout changer. La potentialité d’une compromission implique de considérer que la compromission est de mise. Il y a juste une nuance, c’est celle des cas où l’on utilise des systèmes plus avancés comme le 2FA par exemple.



C’est d’autant plus le cas pour ceux qui utilisent 1 mot de passe unique pour tout ou presque et qui représentent sans doute la majorité des utilisateurs.



Après on peut accepter les risque et jouer à la roulette. Mais c’est autre chose.









David_L a écrit :









En même temps ils font comment les usagers lambda aux compétences limitées, pour gérer 50 comptes avec 50 mots de passe qu’il faut changer 50 fois dans l’année ? Utopie ?





Heartbleed est dévoile aussi



à vos souhaits <img data-src=" />








Reznor26 a écrit :



En même temps ils font comment les usagers lambda aux compétences limitées, pour gérer 50 comptes avec 50 mots de passe qu’il faut changer 50 fois dans l’année ? Utopie ?







Les gens ont qu’à être moins “limités” ou “cons” en politiquement moins correct. <img data-src=" />









Reznor26 a écrit :



En même temps ils font comment les usagers lambda aux compétences limitées, pour gérer 50 comptes avec 50 mots de passe qu’il faut changer 50 fois dans l’année ? Utopie ?





C’est pour cela qu’on a inventé les 2FA et autres. Après effectivement, on peut s’en foutre et préférer le confort du quotidien. M’enfin faut pas venir pleurer quand toute ta vie numérique part à la poubelle en 20 minutes ;)



« Nous avons évalué la vulnérabilité d’OpenSSL et avons décidé d’appliquer un patch de sécurité aux services-clés de Google, comme la recherche, Gmail, YouTube, Wallet, Play, Apps, et App Engine »



Google est concerné ou pas, je ne sais pas comment il faut l’interpréter :http://googleonlinesecurity.blogspot.com/2014/04/google-services-updated-to-addr… ?


Mouais… enfin c’est pas en traitant de cons 90% de la population qu’on arrangera le fossé de plus en plus terrible entre l’importance de la vie numérique et la légèreté de la prise en compte par la société dans son ensemble. On reste quand même dans le domaine de l’utopie.



Après c’est sûr que cet article est votre part du boulot, je parle pas pour vous.








atem18 a écrit :



Les gens ont qu’à être moins “limités” ou “cons” en politiquement moins correct. <img data-src=" />





Comment les rendre moins cons ? <img data-src=" />



J’ai fait tourner l’actu à tous mes contacts.








Winderly a écrit :



J’ai fait tourner l’actu à tous mes contacts.





<img data-src=" />



D’ailleurs comment ça se passe pour la 2FA lorsque l’on change de smartphone ou qu’on le perd, et que tout les comptes à 2FA sont présent dans une appli du smartphone ?



(Il s’agit d’une vraie question, je préfère le préciser, étant Vendredi <img data-src=" /> ).








David_L a écrit :









Au fait, vous aviez fait un dossier concernant ces problématiques-là, mots de passe, solutions etc. ? (j’en ai pas souvenir, et après recherche il semblerait que non, mais j’ai peut-être pas choisi les bons mots-clés)



Le bon côté de la faille s’il y a de réelles compromissions, c’est que ça devrait apprendre à certains à ne jamais enregistrer leurs coordonnées bancaires par fainéantise <img data-src=" />


Il y a ça aussi pour renforcer la sécurité de l’authentification :http://geekfault.org/2011/04/14/yubikey-la-petite-cle-qui-assure/


En effet niveau info on repassera… pour ma part j’ai entendu parler de cette faille par PCInpact, et un article du monde je crois. Dashlane a également envoyé une lettre avec une marche à suivre assez claire à ses usagers. Bref, la population cible n’est pas atteinte !



Avant tout il faut se dire qu’on est pas éduqués à l’informatique, au web… pour ceux qui comme moi n’ont pas fait d’études dans ce domaine, nos connaissances sont celles trouvées dans des forums, wikipédia bouquins, potes,… de l’autoformation mais ça n’intéresse pas tout le monde. Or, comprendre un minimum le fonctionnement de ces services semble nécessaire tant ils nous affectent au quotidien.








fred42 a écrit :





  • Enfin, inutile de changer de mot de passe si le site n’a jamais été vulnérable à cette faille : sites de Microsoft par exemple qui n’utilise pas openSSL.







    Ou pour les sites qui n’ont jamais utilisé une version de OpenSSL supérieure à 1.0.1 avec l’extension TLS_HEARTBEAT activée…



    On oubli qu’au delà de ceux qui ont corrigé et aurait pu être vulnérable pendant la période ou la faille était présente, il y aussi ceux qui n’ont JAMAIS été vulnérables !



Quand j’vois que la plupart des gens (qui ne sont pas super intéressés au Web) on encore du mal à savoir ce qu’est l’HADOPI ou ce genre de trucs … Je m’imagine mal leur parler d’une faille dans OpenSSL.

Et je pense que c’est en partant de ce même principe que les commerces/banques/whatever basent leur (absence de ?) communication. Du genre :



“Les gens s’en foutent d’OpenSSL et d’la sécurité. Ils savent même pas choisir un mot de pass secure et ne gueulent pas quand le site de leur banque oblige des pass composés uniquement de chiffres … Alors osef de communiquer, c’pas les trois geeks du fond qui vous nous emmerder.”



Bref. <img data-src=" /> pour le laxisme général.








David_L a écrit :



<img data-src=" />







David, je ne pense pas que tu pourras pas me répondre précisément vu ce que tu as newsé mais j’essaye quand même. ^^

Vu que les sites plus ou moins concernés n’ont pas l’air de vouloir communiquer correctement sur la situation et du coup vu qu’on ne sait pas s’ils sont touchés par la faille, tu penses qu’il faut attendre combien de temps avant de pouvoir changer nos mots de passe ?

En tout cas, merci pour toutes ces informations déjà plus claires et plus sensées que ce que j’ai essayé de chercher sur le net de mon côté. ;)









Adelio a écrit :









Le mieux reste de tester un site avant de s’y connecter, ou de le contacter pour avoir une information claire sur le sujet. Une fois que c’est le cas, pas de soucis à changer de mot de passe.









David_L a écrit :



<img data-src=" />









Adelio a écrit :



David, je ne pense pas que tu pourras pas me répondre précisément vu ce que tu as newsé mais j’essaye quand même. ^^

Vu que les sites plus ou moins concernés n’ont pas l’air de vouloir communiquer correctement sur la situation et du coup vu qu’on ne sait pas s’ils sont touchés par la faille, tu penses qu’il faut attendre combien de temps avant de pouvoir changer nos mots de passe ?

En tout cas, merci pour toutes ces informations déjà plus claires et plus sensées que ce que j’ai essayé de chercher sur le net de mon côté. ;)





même question



rah la réponse juste au dessus pendant que je cliquais









Nathan1138 a écrit :



J’aime ma banque <img data-src=" />



en même temps faut bien qu’ils justifient le fait de tout facturer plus cher que n’importe lequel des concurrents <img data-src=" />



La meilleur méthode reste encore à mon avis celle envoyée par dashlane.

Changer maintenant pour les sites essentiels et critiques, s’assurer que la faille est colmatée auprès du site et rechanger le mot de passe d’ici une dizaine de jours.

Et par la suite, chanter tous les mots de passe au fur et à mesure


J’vous trouve dur avec le creditmutuel : la faille a été annoncée en fin de journée, leur site a été patché le lendemain vers 8h du matin. C’est p’têt pas immédiat mais une mise en prod le lendemain à 8h du mat ne me semble pas être “en retard”…

Et sur la réponse via twitter, ils sont surtout pas clairs mais pas en tord, vous le dites vous-même, l’accès aux comptes n’était pas concerné (j’avais testé “creditmutel.fr” moi aussi le soir de l’annonce)








feridav a écrit :



J’vous trouve dur avec le creditmutuel : la faille a été annoncée en fin de journée, leur site a été patché le lendemain vers 8h du matin. C’est p’têt pas immédiat mais une mise en prod le lendemain à 8h du mat ne me semble pas être “en retard”…

Et sur la réponse via twitter, ils sont surtout pas clairs mais pas en tord, vous le dites vous-même, l’accès aux comptes n’était pas concerné (j’avais testé “creditmutel.fr” moi aussi le soir de l’annonce)





Non, annoncé le lundi soir, corrigé le mercredi matin :)



Pour la réponse Twitter ils jouent avec les mots oui. Est-ce que c’est une bonne chose dans un cas pareil ? Non.









fred42 a écrit :



Pour quelle raison liée à cette faille faudrait-il changer tous les mots de passe ?



Je serai un peu plus mesuré :

….



Bon, je sais, le discours est un peu plus complexe … que : changer tous vos mots de passe.







Juste par curiosité, comment êtes vous certains que les sites de microsoft (par exemple), n’utilisent pas openssl?

A moins de bosser pour eux et de bien connaitre l’infrastructure ou de les croire sur paroles, je ne vois pas.

Dans ce type de structures ce sont rarement les serveurs web (IIS, apache, etc…) qui sont chargés du cryptage ssl mais des appliances (cisco, f5, etc…) et bien sûr certaines ont été touchées par la faille.

Il faut aussi penser au fait que certains services non infectés ne sont pas isolés et communiquent des données avec d’autres services qui peuvent être infectés…



Changer tous ses mots de passe c’est certainement plus rapide et plus simple que d’essayer de faire des audits qui sont bien plus complexes qu’on ne pourrait le croire.

Bon on peut toujours faire exception pour les sites qui n’utilisent pas de ssl pour la connexion <img data-src=" />



Darty nous a finalement répondu et va contacter ses clients. Actualité à jour <img data-src=" />



http://www.pcinpact.com/news/87007-heartbleed-darty-va-contacter-clients-potenti…


juste un mot MERCI pour votre boulot en continue et sur ce point précis je voulais le préciser. <img data-src=" /> pas très utile comme commentaire mais ça fait toujours plaisir.








David_L a écrit :



On ne sait pas ce qui a fuité, on ne sait pas ce qui pourra être exploité, maintenant ou plus tard. Donc oui, il vaut mieux tout changer. La potentialité d’une compromission implique de considérer que la compromission est de mise. Il y a juste une nuance, c’est celle des cas où l’on utilise des systèmes plus avancés comme le 2FA par exemple.



C’est d’autant plus le cas pour ceux qui utilisent 1 mot de passe unique pour tout ou presque et qui représentent sans doute la majorité des utilisateurs.



Après on peut accepter les risque et jouer à la roulette. Mais c’est autre chose.







Mouai, si on utilise pas les mêmes mots de passes d’un site à l’autre, et parfois même pas les mêmes identifiants, ça ne sert pas a grand chose de verser dans la paranoïa, non plus.

Même si cet article est extrêmement louable, et que je pense comprendre l’intérêt d’en profiter pour sensibiliser les gens a de bonnes pratiques.

Le tout changer sur tous les site sans plus d’explication, me semble excessif, voir contre-productif (Je connais des gens, y compris dans le milieu informatique, qui sont convaincu que “le” bug de l’an 2000 était bidon :/ )

Ou alors, si c’est une recommandation qui n’est pas directement liée à heartbleed, ce n’est pas super clair dans l’article.



Et sinon, ça viens faire quoi cette histoire de “… le faire uniquement sur des sites américains ?” Un lien que je n’ai pas encore lu ?



Bon voilà, sinon…

Le serrurier passera lundi pour changer toutes les serrures de la maison.

Le code secret de ma carte bleu (que j’avais depuis 20 ans) sera également changé. Ainsi, que la puce SIM du téléphone.

Et je déménage, juste après m’être fait refaire le visage, et effacer chirurgicalement mes empreintes.

Je ne sur-réagie pas j’espère ? <img data-src=" />









ashlol a écrit :



juste un mot MERCI pour votre boulot en continue et sur ce point précis je voulais le préciser. <img data-src=" /> pas très utile comme commentaire mais ça fait toujours plaisir.





<img data-src=" />







Chocolat-du-mendiant a écrit :









Si on utilise des procédures assez sûres pour les mots de passes et que l’on est sur qu’aucun d’entre eux n’a fuité. On a effectivement rien à faire. Mais l’article se focalise sur les 99,99 % restants de la population ;)









boglob a écrit :



La meilleur méthode reste encore à mon avis celle envoyée par dashlane.

Changer maintenant pour les sites essentiels et critiques, s’assurer que la faille est colmatée auprès du site et rechanger le mot de passe d’ici une dizaine de jours.

Et par la suite, chanter tous les mots de passe au fur et à mesure





Cette typo est juste magique, je suis obligé de la faire remarquer.



… semblerait selon Bloomberg que … la NSA était au courant de cette faille depuis au moins 2 ans et bien entendu l’exploitait en silence et aurait eu accès à environ les 23 des serveurs cryptés du web …



http://www.theverge.com/2014/4/11/5605444/the-nsa-has-exploited-heartbleed-bug-f…








nicodolivet a écrit :



Une petite aide pour créer vos mots de passe :



http://www.legorafi.fr/2014/04/11/gorafi-magazine-les-100-mots-de-passe-vraiment…





Apparemment il faut un mot de passe pour accéder à la petite aide. <img data-src=" />









boglob a écrit :



Et par la suite, chanter tous les mots de passe au fur et à mesure





“Chanter à mesure” Sans fausse note ? <img data-src=" />









kypd a écrit :



Ou pour les sites qui n’ont jamais utilisé une version de OpenSSL supérieure à 1.0.1 avec l’extension TLS_HEARTBEAT activée…



On oubli qu’au delà de ceux qui ont corrigé et aurait pu être vulnérable pendant la période ou la faille était présente, il y aussi ceux qui n’ont JAMAIS été vulnérables !





Oui, et c’est le cas (entre autres) de tous les sites qui étaient sous Debian en oldstable (pas encore passés à Debian 7), comme d’autres distribs stables encore supportées en mises à jour de sécurité (la stable était vulnérable par contre).



Quand j’ai vu ça j’ai été finalement assez content qu’on n’ait pas encore fait la migration de nos serveurs en Debian 7 (surtout qu’elle ait pris du retard, parce qu’à la base c’était prévu avant fin mars :d)









boglob a écrit :



La meilleur méthode reste encore à mon avis celle envoyée par dashlane.

Changer maintenant pour les sites essentiels et critiques, s’assurer que la faille est colmatée auprès du site et rechanger le mot de passe d’ici une dizaine de jours.

Et par la suite, chanter tous les mots de passe au fur et à mesure





Chanter les mots de passe ? Il ne faut pas d’oreilles indiscrètes à côté









David_L a écrit :



C’est pour cela qu’on a inventé les 2FA et autres. Après effectivement, on peut s’en foutre et préférer le confort du quotidien. M’enfin faut pas venir pleurer quand toute ta vie numérique part à la poubelle en 20 minutes ;)





En même temps, 90% de mes comptes me sont inutiles. Pas dans le sens où je ne les utilise pas, mais dans le sens où que je perde le mdp ou qu’on me pirate le compte, ça m’en touche une sans faire bouger l’autre…

Et je suis certainement loin d’être le sens dans ce cas, avec tous les sites/services qui exigent inutilement la création d’un compte…









Mihashi a écrit :



En même temps, 90% de mes comptes me sont inutiles. Pas dans le sens où je ne les utilise pas, mais dans le sens où que je perde le mdp ou qu’on me pirate le compte, ça m’en touche une sans faire bouger l’autre…

Et je suis certainement loin d’être le sens dans ce cas, avec tous les sites/services qui exigent inutilement la création d’un compte…





Oui mais est-ce le cas de tout le monde. Si tu te fais pirater ton compte NXi, tu t’en fous sans doute. Pas moi <img data-src=" /> Tout est relatif ;)



Donc dire : osef, on peut se faire pirater tant que les comptes GAFA sont saufs. Mais je crains que ça soit un peu court comme raisonnement généralisé :)





Espérons tout de même que la CNIL finira par se saisir de ce dossier et demandera des comptes à tous ceux qui ont laissé fuiter les données sensibles de leurs clients, sans les prévenir et sans même mettre en place de procédure d’information.





La même CNIL qui nous a demandé en début d’année de forcer les formulaires d’authentification en HTTPS. Ironiquement un serveur pur-HTTP-tout-en-clair a été pendant quelques années plus sécurisé qu’un gruyère avec openssl à jour. <img data-src=" />



Heureusement qu’on ne passe pas notre temps à mettre à jour des serveurs et que les nôtres sont encore à l’époque de lucid.


C’est bien beau tout ça, mais quand est ce qu’on fait un git blame ? qu’on le pende haut et court !








elezoic a écrit :



La même CNIL qui nous a demandé en début d’année de forcer les formulaires d’authentification en HTTPS. Ironiquement un serveur pur-HTTP-tout-en-clair a été pendant quelques années plus sécurisé qu’un gruyère avec openssl à jour. <img data-src=" />



Heureusement qu’on ne passe pas notre temps à mettre à jour des serveurs et que les nôtres sont encore à l’époque de lucid.









Euh il était certes pas exposé à cette faille votreserveur d’authentification HTTP, mais vos utilisateurs étaient exposés à d’autre types d’attaques. Dire que c’était plus sécurisé est à mon avis une erreur.



Mais peut être que tu déconnais <img data-src=" />





En tout cas je suis au crédit mutuel. J’étais entrain de leur préparer un e-mail pleines de remarques sur la sécurité de leur web banking. Je vais leur toucher un mot de cette histoire de serveur de paiement car ils n’ont absolument pas communiqué là dessus.









Patch a écrit :



en même temps faut bien qu’ils justifient le fait de tout facturer plus cher que n’importe lequel des concurrents <img data-src=" />





Par exemple ?



J’ai envoyé hier à ma banque en leur parlant d’openSSL et leur envoyant un lien vers un article qui en parle mais ils n’ont rien compris, ils me parlent de pishing. <img data-src=" />








xillibit a écrit :



J’ai envoyé hier à ma banque en leur parlant d’openSSL et leur envoyant un lien vers un article qui en parle mais ils n’ont rien compris, ils me parlent de pishing. <img data-src=" />









Les banques françaises sont vraiment à la ramasse. Au crédit mut’ j’ai un simple identifiant/mot de masse. Et le mot de passe ne peut pas dépasser 8 caractère. Il y’a une politique de blocage des comptes. Mais bon ça ne protège pas vraiment le mot de passe. En plus cette politique de blocage est pourri, mon identifiant est mon numéro de compte, si quelqu’un veut m’emmerder il fait 3 fausses tentative de connexion et je suis obligé d’aller physiquement à ma banque pour débloquer le compte.



J’en ai parlé à mon conseiller il y’a deux semaines, il m’a fait des yeux rond lol.









David_L a écrit :



Oui mais est-ce le cas de tout le monde. Si tu te fais pirater ton compte NXi, tu t’en fous sans doute. Pas moi <img data-src=" /> Tout est relatif ;)



Donc dire : osef, on peut se faire pirater tant que les comptes GAFA sont saufs. Mais je crains que ça soit un peu court comme raisonnement généralisé :)







Moi ça me ferait chier de me faire piraté mon compte NXI <img data-src=" />



Sinon je me permets de demander, vous avez discuté avec le credit mut’, il y’a t’il une adresse quelconque permettant de leur adresser les questions de secu ?



Bon ouf Blizzard n’est pas touché XD



Bon sinon, est-ce qu’il y a quelque part une liste des sites concernés ?


Il y a une liste là :http://www.lemonde.fr/technologies/article/2014/04/11/faille-heartbleed-les-site… et même qu’il cite NextInpact à la fin <img data-src=" />








Gorkk a écrit :



Oui, et c’est le cas (entre autres) de tous les sites qui étaient sous Debian en oldstable (pas encore passés à Debian 7), comme d’autres distribs stables encore supportées en mises à jour de sécurité (la stable était vulnérable par contre).



Quand j’ai vu ça j’ai été finalement assez content qu’on n’ait pas encore fait la migration de nos serveurs en Debian 7 (surtout qu’elle ait pris du retard, parce qu’à la base c’était prévu avant fin mars :d)







C’est un peu pareil sur mes Gentoo en 1.0.1e qui n’avait pas l’extension “Heartbeat” de compilé (quand je connais pas un use flag j’active pas…)



Sur des Red Hat inférieures a 6.5 (dernière en date) pareil aucune vulnérabilité, et vu la lenteur des gros acteur à migrer je pense que cette version était assez peu déployée



J’ai vérifier aussi sur le DD-WRT de mon routeur, OpenSSL est en version 0.9.8, non touchée donc…



De plus au delà des serveurs HTTPS, les services SMTPS, POP3S, IMAPS, et même Secure-DNS (DNSS ?) ont pu être touchées (SSH semble hors de cause, n’autorisant pas une sessions TLS)



Dans ces cas de figure n’importe quelle type de données à pu fuiter, sur des services faisant principalement de l’authentification avant de passer la main à un autre serveur il est probable de retrouver des couples login/mot de passe, mais dans les autres cas à part une éventuelle fuite de certificat qui serait dangereuse il est tout même assez peu probable d’avoir pu obtenir des données exploitables…



Mine de rien, ce scandale heartbleed aura été l’occasion pour moi de faire le ménage dans tout mes comptes (du moins ceux dont je me rappelle l’existence).



Après en avoir supprimé, non sans mal, 30% d’entre eux, je vais en profiter pour redéfinir une stratégie de mot de passe cohérente sur l’ensemble selon leur criticité ainsi que l’adresse mail que je leur associe.



Un mal pour un bien en somme. <img data-src=" />


Couper l’accès aux serveurs concernés : A un moment faut aussi prendre en compte le ratio risque/interruption de service et chiffrer les pertes que ça peut entraîner. Si le risque est faible alors qu’une interruption de service entraîne forcément des pertes (pour un site commercial, c’est autant de ventes qui n’auront pas lieu, et donc de la perte de CA), ça ne vaut pas le coup/coût.

24 à 48h de réaction sur une correction dans un environnement de prod pour corriger une faille de sécurité révélée peu de temps avant, c’est très bien !

Il ne faut pas oublier qu’un changement en prod nécessite toujours un test de non régression préalable. On ne bricole pas comme ça des serveurs de production, c’est un coup à faire plus de conneries qu’autre chose…



Mettre à jour OpenSSL, redémarrer les services concernés : Yaka faukon, encore une fois, ça ne se fait pas en cinq minutes. Tout changement nécessite une évaluation de l’impact sur l’environnement, les services ne peuvent pas forcément être redémarrés à volonté, pour peu qu’il y ait du progiciel à la con qui a un truc bizarre embarqué ça devient vite le bordel… Ne sous estimez pas la capacité des éditeurs de progiciels à faire des trucs tordus.

Et si les serveurs sont chez un prestataire ? Genre mon site commercial est hébergé par Machin et la descente de commandes client/interro stock/etc se fait par request/reply avec mon SI.

Plus on rajoute d’intermédiaires dans la boucle, plus les délais deviennent longs…



Informer les clients : C’est le minimum à faire dans tout ce bordel. Seulement c’est aussi un risque car derrière l’image de l’entreprise peut en pâtir alors qu’elle n’est pas fautive à la base. C’est une communication difficile à faire car ça peut faire peur aux clients qui perdront confiance dans la boîte… Mais l’absence de comm’ est regrettable dans tous les cas.



Bref, on peut avoir toute la bonne volonté du monde pour répondre à un problème de sécurité le plus vite possible, mais il faut éviter de faire ça dans la précipitation et plomber plus que la faille n’aurait pu en provoquer. Je trouve ça exagéré d’accuser de manque de professionnalisme les délais de correction quand ils sont de l’ordre de 24 à 48h… J’ai limite l’impression d’entendre des managers que j’ai déjà subi…

Avis d’admin système de production.








ben5757 a écrit :



Euh il était certes pas exposé à cette faille votreserveur d’authentification HTTP, mais vos utilisateurs étaient exposés à d’autre types d’attaques. Dire que c’était plus sécurisé est à mon avis une erreur.







Entre une communication HTTP en clair où il faut pouvoir intercepter la trame IP sur le chemin, et un serveur avec une faille qui divulgue à X des données concernant Y alors que le seul point commun est de s’être adresser au même serveur, et parfois en divulguant carrément les certificats, qui est le moins vulnérable autrement dit qui est le plus sécurisé ?









Nathan1138 a écrit :



Par exemple ?



par exemple, suffit de regarder les tarifs.

quand j’étais chez eux, j’étais à plus de 5€ par mois (frais tenue de compte) + 45 de carte bancaire par an. aucune banque n’a réussi à faire aussi cher.

5 ans que j’ai changé de banque (banque en ligne maintenant), ma carte bancaire est une gold (meilleure assurance en cas de pépin), et en 5 ans j’ai dépensé 15€ au total. dont 10 par ma faute, parce que je m’étais planté trop de fois dans le code de la carte.

mes parents étaient aussi au CA, ils ont divisé par 2 toutes leurs dépenses bancaires en passant à la SG…



le CA est la banque la plus chère de France, et n’est pas prête d’être détrônée sur ce point.



C’est plutôt la SG qui est plus chère d’après les échos que j’ai, la SG c’est pas une banque en ligne


Personnellement, j’ai travaillé sur un système d’authentification à une époque où on avait pas de certificats SSL pour nos domaines publiques. Et comme j’étais déjà parano j’ai mis en place un système d’authentification à base de hash et de jetons (au départ je voulais faire du chiffrement asymétrique mais je n’ai pas trouvé de lib js pour ça) de manière à ce que le mot de passe ne transite jamais en clair. (sauf quand le JS est défaillant ou désactivé, là ça passe tout en clair)



Là je teste depuis quelques mois le Multi-factor Authentification pour les comptes à privilèges du site. D’ailleurs j’ai remarqué que sur Amazon AWS, le formulaire d’authentification avait légèrement changé depuis le début de semaine pour les comptes secondaires. Il est nécessaire de savoir que le MFA est activé sur le compte dès la première étape, alors qu’avant il y avait d’abord la vérification login-mot de passe et après une étape MFA qui apparaissait que si le compte en nécessitait une.








SebGF a écrit :



Couper l’accès aux serveurs concernés : A un moment faut aussi prendre en compte le ratio risque/interruption de service et chiffrer les pertes que ça peut entraîner. Si le risque est faible alors qu’une interruption de service entraîne forcément des pertes (pour un site commercial, c’est autant de ventes qui n’auront pas lieu, et donc de la perte de CA), ça ne vaut pas le coup/coût.

24 à 48h de réaction sur une correction dans un environnement de prod pour corriger une faille de sécurité révélée peu de temps avant, c’est très bien !

Il ne faut pas oublier qu’un changement en prod nécessite toujours un test de non régression préalable. On ne bricole pas comme ça des serveurs de production, c’est un coup à faire plus de conneries qu’autre chose…





Bah tu diras ça aux clients dont les données ont été exposées pendant 24/48h, parce que bon vaut mieux laisser la possibilité de se connecter et d’acheter plutôt que de tout couper hein. Je trouve que la problématique technique, si elle est fondée dans certains cas, a bon dos dans d’autres.







Chloroplaste a écrit :



Mine de rien, ce scandale heartbleed aura été l’occasion pour moi de faire le ménage dans tout mes comptes (du moins ceux dont je me rappelle l’existence).



Après en avoir supprimé, non sans mal, 30% d’entre eux, je vais en profiter pour redéfinir une stratégie de mot de passe cohérente sur l’ensemble selon leur criticité ainsi que l’adresse mail que je leur associe.



Un mal pour un bien en somme. <img data-src=" />





Oui, un peu de ménage ça ne fait jamais de mal <img data-src=" />







xillibit a écrit :



Les matériels Juniper et Cisco sont touchés :http://www.journaldunet.com/solutions/dsi/heartbleed-correctif-cisco-et-juniper-…



La FED demande aux banques de corriger au plus vite :http://www.lemonde.fr/technologies/article/2014/04/11/la-fed-demande-aux-banques…



Des hackers veulent s’amuser avec cette faille :http://www.lemondeinformatique.fr/actualites/lire-des-hackers-preparent-des-atta…





Tu as super bien lu la news, puisqu’au moins deux des trois infos que tu cites sont dedans <img data-src=" />









xillibit a écrit :



C’est plutôt la SG qui est plus chère d’après les échos que j’ai, la SG c’est pas une banque en ligne



si une banque plus chère permet de diminuer les tarifs, c’est génial <img data-src=" />









elezoic a écrit :



Entre une communication HTTP en clair où il faut pouvoir intercepter la trame IP sur le chemin, et un serveur avec une faille qui divulgue à X des données concernant Y alors que le seul point commun est de s’être adresser au même serveur, et parfois en divulguant carrément les certificats, qui est le moins vulnérable autrement dit qui est le plus sécurisé ?









Je ne disais pas qu’un cas était plus sécurisé que l’autre, les deux sont des gruyères du coup. La faille openSSL est un gruyère par erreur et l’interface HTTP est un gruyère par conception .



Avec la faille openSSL, tu ne sais pas qui l’exploiter et tu ne sais pas ce qu’elle fuite. C’est la même chose avec une authentification HTTP , tu ne sais pas sur Internet qui intercepte le trafic et qui l’analyse. Et ce n’est pas de la parano excessive. Il suffit de se connecter à un Wifi public. Une fois la faille detectée et patchée c’est ok. L’interface d’authentification HTTP par contre continuera à fuiter de l’information









elezoic a écrit :



Personnellement, j’ai travaillé sur un système d’authentification à une époque où on avait pas de certificats SSL pour nos domaines publiques. Et comme j’étais déjà parano j’ai mis en place un système d’authentification à base de hash et de jetons (au départ je voulais faire du chiffrement asymétrique mais je n’ai pas trouvé de lib js pour ça) de manière à ce que le mot de passe ne transite jamais en clair. (sauf quand le JS est défaillant ou désactivé, là ça passe tout en clair)



Là je teste depuis quelques mois le Multi-factor Authentification pour les comptes à privilèges du site. D’ailleurs j’ai remarqué que sur Amazon AWS, le formulaire d’authentification avait légèrement changé depuis le début de semaine pour les comptes secondaires. Il est nécessaire de savoir que le MFA est activé sur le compte dès la première étape, alors qu’avant il y avait d’abord la vérification login-mot de passe et après une étape MFA qui apparaissait que si le compte en nécessitait une.







Pour ton paragraphe 1 comment faisais tu du coup ? Tu essayé de forcer l’utilisation de javascript ?



Il est clair que l’authentification à multiples facteurs est une excellente solution. Je travaille pour un fournisseur de service en ligne pour professionnel et nous tentons de pousser l’authentification multiples facteurs chez nos clients. Mais c’est difficile à imposer. Certains gros clients sont carrément réticent à distribuer des token et même à gérer des numéro de téléphone. On essaie de tenir bon mais si on insiste trop on risque de perdre de gros marché.







SebGF a écrit :



Mettre à jour OpenSSL, redémarrer les services concernés : Yaka faukon, encore une fois, ça ne se fait pas en cinq minutes. Tout changement nécessite une évaluation de l’impact sur l’environnement, les services ne peuvent pas forcément être redémarrés à volonté, pour peu qu’il y ait du progiciel à la con qui a un truc bizarre embarqué ça devient vite le bordel… Ne sous estimez pas la capacité des éditeurs de progiciels à faire des trucs tordus.

Et si les serveurs sont chez un prestataire ? Genre mon site commercial est hébergé par Machin et la descente de commandes client/interro stock/etc se fait par request/reply avec mon SI.

Plus on rajoute d’intermédiaires dans la boucle, plus les délais deviennent longs…







C’est la qu’on est content d’avoir tous nos services derriere le même type de proxy. On a pu tout mettre à jour en 2h ( au mépris des tests je l’admets). Mais avec un code d’exploitation facilement disponible il était plus sage de mettre à jour et risqué une indispo de quelques minutes plutôt que de voir des robots commencer à scanner nos adresse pour récupérer de l’info.









David_L a écrit :



Bah tu diras ça aux clients dont les données ont été exposées pendant 24/48h, parce que bon vaut mieux laisser la possibilité de se connecter et d’acheter plutôt que de tout couper hein. Je trouve que la problématique technique, si elle est fondée dans certains cas, a bon dos dans d’autres.





Oui, un peu de ménage ça ne fait jamais de mal <img data-src=" />





Tu as super bien lu la news, puisqu’au moins deux des trois infos que tu cites sont dedans <img data-src=" />





Je lis juste la conclusion c’est pour ça









David_L a écrit :



Bah tu diras ça aux clients dont les données ont été exposées pendant 24/48h, parce que bon vaut mieux laisser la possibilité de se connecter et d’acheter plutôt que de tout couper hein. Je trouve que la problématique technique, si elle est fondée dans certains cas, a bon dos dans d’autres.







La faille était tellement grosse que ça fait surement pas mal de temps que tout le monde se gave avec donc c’est triste a dire mais il faut garder son sang froid on est pas a 24H prêt surtout pour un service qui perdrait potentiellement des millions en arrêtant tout sans parler de la gêne occasionné pour les clients.



En plus pour chopper des infos intéressantes et les décryptés faut y aller quand même.



Par contre ne pas renouveler les certificats est d’une bêtise sans nom…









xillibit a écrit :



C’est plutôt la SG qui est plus chère d’après les échos que j’ai, la SG c’est pas une banque en ligne









La SG ils aiment bien te faire souscrire à des services sans que tu aies rien demander … moi par exemple ils m’ont mis des frais de tenues de comptes ( genre classer mes entrées et sorties d’argent… je n’ai jamais su quel ordre, alphabétique ou par moyen de paiement, était utilisé vu que je n’avais aucune rentrée ou sortie sur ce compte … j’étais déjà parti à CA ) 2 mois pour te rétracter d’un truc qu’on t’a imposé sinon c’est comme si tu abusais de leur honnêteté….



Bref les banques c’est comme les 3 petits cochons de la téléphonie mobile avant que free ne débarque, ils ont l’air différents, leurs pubs sont différentes mais ils te prennent par derrière de la même façon ….



D’ailleurs depuis que free a débarquer y a 2 des 3 petits cochons ( vivendi et bouygues ) qui ont plus ou moins lâché l’affaire de ce marché largement moins rentable qu’avant …. étrange.









ben5757 a écrit :



Les banques françaises sont vraiment à la ramasse. Au crédit mut’ j’ai un simple identifiant/mot de masse. Et le mot de passe ne peut pas dépasser 8 caractère. Il y’a une politique de blocage des comptes. Mais bon ça ne protège pas vraiment le mot de passe. En plus cette politique de blocage est pourri, mon identifiant est mon numéro de compte, si quelqu’un veut m’emmerder il fait 3 fausses tentative de connexion et je suis obligé d’aller physiquement à ma banque pour débloquer le compte.



J’en ai parlé à mon conseiller il y’a deux semaines, il m’a fait des yeux rond lol.





Je suis d’accord, le CM devrait autoriser les mdp bien plus longs. Concernant le login, avant, c’était le n° de compte, désormais ce n’est plus le cas si tu ouvres un compte avec suivi en ligne (défaut de sécurité). Mais effectivement, le CM aurait dû demander à ses clients de changer le login.



Ceci dit, c’est pas pire que chez SFR qui stocke en local dans le profil du navigateur les n° de la CB pour le formulaire de paiement en ligne pour l’ADSL, alors qu’un simple autocomplete=off aurait suffi. <img data-src=" />



À lire ici, un article de Numerama qui fait le lien (indirect, de principe) entre le vote par internet et l’enseignement de la faille Heartbleed. Intéressant.


Article intéressant de CloudFare sur le respect des révocations de certificats SSL:

https://blog.cloudflare.com/certificate-revocation-and-heartbleed



Chrome reçoit un carton rouge.








David_L a écrit :



Bah tu diras ça aux clients dont les données ont été exposées pendant 24/48h 2 ans, parce que bon vaut mieux laisser la possibilité de se connecter et d’acheter plutôt que de tout couper hein. Je trouve que la problématique technique, si elle est fondée dans certains cas, a bon dos dans d’autres.





<img data-src=" />









Naunaud a écrit :



Article intéressant de CloudFare sur le respect des révocations de certificats SSL:

https://blog.cloudflare.com/certificate-revocation-and-heartbleed



Chrome reçoit un carton rouge.





Même après activation de la révocation des certificats dans les paramètres avancés,

j’accède toujours au site du challenge avec Chrome. <img data-src=" />









Patch a écrit :



par exemple, suffit de regarder les tarifs.

quand j’étais chez eux, j’étais à plus de 5€ par mois (frais tenue de compte) + 45 de carte bancaire par an. aucune banque n’a réussi à faire aussi cher.

5 ans que j’ai changé de banque (banque en ligne maintenant), ma carte bancaire est une gold (meilleure assurance en cas de pépin), et en 5 ans j’ai dépensé 15€ au total. dont 10 par ma faute, parce que je m’étais planté trop de fois dans le code de la carte.

mes parents étaient aussi au CA, ils ont divisé par 2 toutes leurs dépenses bancaires en passant à la SG…



le CA est la banque la plus chère de France, et n’est pas prête d’être détrônée sur ce point.





105 euros par an juste pour avoir une CB ? Soit t’étais pas dans la même caisse régionale que moi, soit t’es pas capable de négocier un truc intéressant ;)



La société générale, c’est la banque qui perd 5 milliards sans s’en rendre compte, c’est ça ?



Pas sûr que je lui donnerais mes sous, moi :)









xillibit a écrit :



Comment les rendre moins cons ? <img data-src=" />







En les éduquant.









Nathan1138 a écrit :



La société générale, c’est la banque qui perd 5 milliards sans s’en rendre compte, c’est ça ?







T’as rien compris, c’est tout la faute du méchant trader/hacker.<img data-src=" />









psn00ps a écrit :



24/48h 2 ans







Dison que depuis quelques jours seulement, le risque est beaucoup plus important.









dam1605 a écrit :



Disons que depuis quelques jours seulement, le risque est beaucoup plus important.





NSA disapproves <img data-src=" />



Impossible d’accéder au site AppleID ce soir pour changer mon mdp.



Le site est HS.




Néanmoins, à terme, vous devrez changer TOUS vos mots de passe, sur TOUS les services que vous utilisez. Il faudra néanmoins respecter quelques règles, en ayant en tête une chose : la sécurité amène forcément de la complexité.





Tout dépend de ce qu’on appelle “utiliser”. Il fut un temps où l’on n’avait pas besoin de s’inscrire sur un forum pour exploiter la fonction de recherche interne, ou pour faire un petit commentaire sur un site…



Mais les bots sont passés par là, les services se sont multipliés, etc. Et aujourd’hui j’ai très exactement 133 enregistrements dans mon fichier Keepass, et cela n’inclut pas ceux que j’ai omis d’insérer (probablement une 30aine)… Je dois avoir une bonne 40aines de logins différents pour le tout (certains sites n’offrent pas le choix que d’utiliser l’e-mail comme login…), mais la presque totalité des mots de passe ne sont pas identiques entre eux. Il y a des exceptions notamment quand il est impossible d’enregistrer le pass en local (Starcraft, Eve Online…) et donc me forçant à le taper ce qui oblige à une simplification du dit pass…



…mais donc changer tout cela, aucune chance. Je ne le ferai que sur les services critiques.








TheKillerOfComputer a écrit :



Il y a des exceptions notamment quand il est impossible d’enregistrer le pass en local (Starcraft, Eve Online…) et donc me forçant à le taper ce qui oblige à une simplification du dit pass…





Le launcher de Blizzard enregistre le mdp, ce qui t’autorise à ne pas le taper à chaque fois.









Nathan1138 a écrit :



Le launcher de Blizzard enregistre le mdp, ce qui t’autorise à ne pas le taper à chaque fois.







Sauf que je ne m’en sers pas encore, faut dire que je n’ai QUE SC2 donc… Or SC2 de base n’enregistre que le login, pas le pass.









TheKillerOfComputer a écrit :



Sauf que je ne m’en sers pas encore, faut dire que je n’ai QUE SC2 donc… Or SC2 de base n’enregistre que le login, pas le pass.





Wé, moi aussi j’ai que SC2, mais j’utilise quand même le launcher qui, en plus d’enregistrer le mdp, fait les MAJ automatiquement (et pas uniquement pile quand t’as envie de jouer, parce que tu lancer le soft…).









Nathan1138 a écrit :



Wé, moi aussi j’ai que SC2, mais j’utilise quand même le launcher qui, en plus d’enregistrer le mdp, fait les MAJ automatiquement (et pas uniquement pile quand t’as envie de jouer, parce que tu lancer le soft…).







Il me semble qu’il n’enregistre pas le mot de passe mais un token d’identification. Ce qu’il fait que quand il expire (tous les mois dans mon cas), je dois le ressaisir. Après je peux me tromper…









XMalek a écrit :



Il me semble qu’il n’enregistre pas le mot de passe mais un token d’identification. Ce qu’il fait que quand il expire (tous les mois dans mon cas), je dois le ressaisir. Après je peux me tromper…





Bizarre, ça fait depuis la bêta que j’utilise le launcher, et je ne crois pas qu’il m’ait déjà redemandé mon mot de passe… Ou alors je l’entre de façon tellement automatique que je ne m’en rends même plus compte ;)



Pour info s’il y en a que ça intéresse, à ma demande, la Banque Populaire m’a indiqué que la faille a été corrigée sur leur service Cyberplus le 9 avril.