Heartbleed : des cas français existent et les banques ne sont pas épargnées

Heartbleed : des cas français existent et les banques ne sont pas épargnées

C'est l'histoire d'un nuage...

Avatar de l'auteur
David Legrand

Publié dans

Internet

18/04/2014 12 minutes
26

Heartbleed : des cas français existent et les banques ne sont pas épargnées

La semaine dernière, la faille de sécurité Heartbleed était dévoilée. Touchant OpenSSL, celle-ci a concerné des milliers de services plus ou moins sensibles de par le monde. Depuis, chaque pays découvre des cas plus ou moins graves. Tous ? Non ! « Un petit village d'irréductibles Gaulois résiste encore et toujours à l'envahisseur. » C'est en tout cas ce que certains aimeraient bien nous faire croire. Nous avons néanmoins trouvé des cas concrets.

Crédit Mutuel Heartbleed

Non, la France n'a pas été épargnée. Le Crédit Mutuel a corrigé la faille le mercredi 9 avril au matin

 

La frontière française ne protège pas seulement des retombées de nuages radioactifs, elle protège aussi des failles informatiques. C'est en tout cas ce que l'on peut être amené à penser lorsque l'on regarde les différentes annonces, et le traitement médiatique autour de la faille Heartbleed. En effet, comme nous l'avons plusieurs fois évoqué, rares sont les sociétés françaises qui avouent avoir eu à faire face à ce problème, et encore plus rares sont celles qui prennent la peine de prévenir leurs clients des données concernées et des risques encourus. Pourquoi le feraient-elles d'ailleurs, puisqu'elles n'en ont pas (encore) l'obligation ?

La communication autour d'Heartbleed n'est pas mauvaise, elle est souvent inexistante

En marge de nos propres découvertes, nos confrères de Slate avaient cherché à dresser une liste des sociétés françaises touchées ou non, en se basant sur le modèle de Mashable. Comme l'on pouvait s'en douter, c'est peine perdue, puisqu'il est impossible de contacter tout le monde, que les seuls qui répondent le font pour dire qu'ils ne sont pas concernés et qu'il est très compliqué de vérifier la véracité des propos tenus. En effet, une fois le serveur mis à jour, qui pourra dire s'il a été touché ou non ?

 

Une façon de faire qui est bien loin de ce qui peut se pratiquer dans d'autres pays. Outre les nombreux services étrangers massivement utilisés qui ont rapidement communiqué de manière transparente sur le sujet, on note l'exemple de l'Agence du Revenu du Canada qui a vite indiqué qu'elle était touchée par la faille. Elle a donc décidé de couper ses services pour éviter une fuite supplémentaire, mais a néanmoins découvert que près de 900 numéros d'assurance sociale avaient été récupérés.

 

Après une période de silence pour permettre à la Gendarmerie royale du Canada d'enquêter, elle a finalement annoncé qu'elle contacterait les personnes concernées par lettre recommandée. Quelques jours plus tard on apprenait qu'un étudiant en sciences informatiques à l'Université de Western Ontario, où son père est professeur d'informatique, était soupçonné d'être à l'origine de la récupération de ces données. Arrêté à son domicile mardi, Stephen Arthuro Solis-Reyes, âgé de seulement 19 ans, comparaîtra à Ottawa le 17 juillet 2014.

Le silence souvent de mise en France, malgré des cas concrets

Et en France ? Rien. Les services de l'État qui ont clairement annoncé la couleur l'ont fait pour expliquer qu'ils n'étaient pas concernés, comme le service des impôts par exemple :

 

 

Mais c'est tout. Un cas est spécialement intéressant à analyser : celui des banques. En effet, elles multiplient aussi les annonces sur les réseaux sociaux pour évoquer le fait qu'elles n'ont pas été concernées, et parfois même via des communiqués de presse. Nos confrères du Monde ou des Echos ont ainsi évoqué leur tentative de rassurer leurs clients, alors que de nombreux cas suisses ont été relevés. Mais est-ce vraiment si rose dans la pratique ? Comme nous allons le voir, il n'en est rien.

 

Car de notre côté, nous avons cherché à identifier des serveurs dont nous pouvons affirmer qu'ils ont été touchés et dont nous avons pu avoir connaissance des données qui auraient pu être récupérées. Suite à nos différents articles, vous avez d'ailleurs été nombreux à nous contacter via différents canaux pour nous apporter des preuves concernant différents cas que nous sommes en train d'étudier. N'hésitez pas à continuer à le faire.

Avoir des informations précises relève du parcours du combattant

Mais même avec ces informations, il est parfois compliqué d'en savoir plus et d'obtenir des réponses. Le premier cas que nous avions étudié, Darty, est un exemple du genre. Après de multiples sollicitations, la société a finalement décidé de nous répondre et d'envoyer un email d'avertissement à ses clients. Un email qui minimisait un peu le problème, puisque le serveur touché était celui gérant la connexion au service, rien de moins.

 

Heartbleed Secure.darty.com

 

Mais même dans nos communications récentes, le groupe nous indique qu'« il n’y a pas eu de circulation en clair des mots de passe sur les serveurs de Darty. Les données auraient pu éventuellement être déchiffrables entre le navigateur et le serveur. Sur le serveur lui-même le mot de passe est immédiatement chiffré dès réception avant d’être stocké (toujours de manière chiffrée) en base. »

 

Or les données récupérées le sont dans la mémoire du serveur, et peuvent donc l'être avant le chiffrement et le stockage. C'est d'ailleurs bien le cas, et dans les données pouvant être renvoyées par le serveur on pouvait bien trouver des URL contenant différents paramètres, dont l'identifiant de connexion (une adresse email) et le mot de passe associé. Un point sur lequel nous n'avons pas eu de détails supplémentaires, notre dernier échange n'ayant donné lieu à aucune réponse nouvelle.

Lorsque le flou entretient les réponses positives

Le second cas que nous avions étudié était bancaire. En effet, très rapidement, certains ont remarqué que les plateformes de paiement du groupe CIC / Crédit Mutuel étaient touchées. Mais si l'on regarde bien le compte Twitter du second, par exemple, il indique à ses clients que la banque a été épargnée. Une réponse nette, mais qui est ambiguë.

 

 

Le service principal, qui permet de se connecter pour accéder à ses comptes, a sans doute été épargné. Ce qui permet de diffuser cette affirmation. Mais quid de tous les autres services de la banque ? La question étant imprécise, la réponse se permet de l'être. Car effectivement, ces plateformes de paiement étaient touchées et laissaient fuiter des informations personnelles, mais aucune donnée bancaire semble-t-il. Il était simplement possible de savoir le montant d'un achat, de connaître des informations sur l'acheteur ou le service concerné, bref, de quoi diffuser de belles campagnes de phishing.

 

La correction de la faille aura parfois duré un certain temps, puisque nous avons pu relever que la plateforme du Crédit Mutuel n'a été mise à jour que le mercredi matin.

La banque épargnée. Et son service de coffre-fort numérique pour vos documents ?

Le dernier cas que nous avons pu confirmer nous semble néanmoins plus problématique et concerne la BNP. Celle-ci affirmait en effet aussi à ses clients être épargnée par Heartbleed. Là encore, c'était très certainement le cas pour l'accès aux comptes, mais pas pour son service Sécurité Plus.

 

 

Pour rappel, il s'agit s'un service d'assurance, proposé aux clients de la banque, mais qui contient aussi une sorte de coffre-fort numérique dans lequel vous êtes incités à stocker certains documents et même des numéros de cartes de paiements. Les conditions générales précisent bien qu'il permet « l’enregistrement, la mémorisation et la restitution à l’Assuré des numéros d’identification ». Parmi les éléments cités on retrouve les informations « des cartes bancaires et du porte-monnaie électronique Moneo [...] des numéros du Compte garanti [...] des Papiers officiels, du numéro d’identification du porte-clés de sécurité, ainsi que des données personnelles éventuelles confiées par l’Assuré »

 

Problème : le site exploitait une version d'OpenSSL touchée par Heartbleed et permettait donc de récupérer n'importe laquelle de ces données si elle venait à transiter par le serveur au moment où l'attaquant siphonnait sa mémoire.

 

Dans un premier temps, nous avons interrogé le compte Twitter de la banque pour savoir pourquoi il n'évoquait pas plus précisément les services touchés. En privé, après une vérification auprès des services techniques, il nous a confirmé le problème et sa correction, en précisant : « nous effectuons les vérifications pour savoir s'il a été réellement touché ». Et concernant l'information des clients ? Notre contact a tenu à nous rassurer en ajoutant : « en cas d'incident, les clients seront contactés par nos services. »

En cas de problème, le client sera protégé... est-ce une raison ?

Mais l'incident est-il la fuite des données ou leur éventuelle exploitation ? Les clients seront néanmoins rassurés par deux points : ce service de stockage est justement associé à une assurance contre les utilisations frauduleuses et la loi oblige dans tous les cas les services bancaires à couvrir l'utilisateur en cas de problème, que ce dernier soit issu d'une fuite ou non.

 

L'article L133-18 du Code monétaire et financier précise en effet qu'« en cas d'opération de paiement non autorisée signalée par l'utilisateur dans les conditions prévues à l'article L. 133-24, le prestataire de services de paiement du payeur rembourse immédiatement au payeur le montant de l'opération non autorisée et, le cas échéant, rétablit le compte débité dans l'état où il se serait trouvé si l'opération de paiement non autorisée n'avait pas eu lieu. Le payeur et son prestataire de services de paiement peuvent décider contractuellement d'une indemnité complémentaire. » L'article L133-24 précise effectivement les conditions dans lesquelles cela doit être effectué : 

 

« L'utilisateur de services de paiement signale, sans tarder, à son prestataire de services de paiement une opération de paiement non autorisée ou mal exécutée et au plus tard dans les treize mois suivant la date de débit sous peine de forclusion à moins que le prestataire de services de paiement ne lui ait pas fourni ou n'ait pas mis à sa disposition les informations relatives à cette opération de paiement conformément au chapitre IV du titre 1er du livre III. Sauf dans les cas où l'utilisateur est une personne physique agissant pour des besoins non professionnels, les parties peuvent convenir d'un délai distinct de celui prévu au présent article. »

 

Nous avons bien entendu demandé des détails complémentaires au service presse de la BNP, afin d'en savoir plus sur la façon dont les utilisateurs de ce service allaient être contactés et ce qui serait mis en place pour les protéger, la faille n'ayant été corrigée qu'au bout de quelques jours. Nous n'avons pour le moment pas pu en savoir plus, le service ayant simplement précisé : « Nous avons pris en compte cette alerte et  toutes les mesures de protection nécessaires ont été prises. »

Les leçons à tirer de Heartbleed et de ses conséquences

Mais au final, ces différents cas nous apprennent plusieurs choses. Tout d'abord, il faut se méfier des effets d'annonces des différents services concernant Heartbleed, et ne pas hésiter à insister, à poser des questions précises pour en savoir plus et à vérifier que les sites sur lesquels vous vous connectez ne sont plus touchés, notamment via l'outil en ligne de Qualys (voir notre émission dédiée à Heartbleed). On regrettera d'ailleurs que les services publics ne semblent pas se saisir de cette problématique, et n'incitent pas plus les sociétés potentiellement concernées à communiquer de manière transparente autour de cette faille. Cela aiderait pourtant tout le monde à y voir bien plus clair et éviterait de passer des heures à vérifier le moindre cas.

 

Ensuite, n'hésitez pas à surveiller vos comptes ces prochaines semaines et ces prochains mois, afin de pouvoir détecter tout problème et alerter votre banque au plus vite si cela était le cas. Cette recommandation peut d'ailleurs s'appliquer tout au long de l'année, comme celles concernant la gestion de vos mots de passe. Prenez aussi garde aux emails que vous recevez. Nous avons en effet déjà été alertés de plusieurs cas de phishing. Comme nous l'avions déjà évoqué, la gendarmerie a mis en ligne une page explicative avec des contacts à utiliser en cas de problème. Vous pourrez aussi effectuer un signalement via la plateforme Pharos ainsi que sur phishing initiative

 

Authenticator Blizzard

L'authentification en deux étapes lancées par Blizzard il y a quelques années

 

Enfin, utilisez les outils de sécurité mis à votre disposition par les différents services que vous utilisez. La connexion en deux étapes est ainsi largement proposée et s'avère efficace en cas de vol de vos mots de passe. Malheureusement, des technologies telles que 3D Secure seront pour leur part sans effet ou presque, puisqu'elles ne sont pas systématiquement implémentées par les revendeurs qui peuvent accepter un numéro de carte dérobé, que ce soit en France ou à l'étranger.

 

Deux amendements proposés l'année dernière visaient à la rendre obligatoire. Le premier a été rejeté, le second a été retiré. Ses opposants évoquent en effet un système mal conçu, inadapté au web et méconnu du grand public. En attendant une refonte, ou l'émergence de systèmes plus efficaces, l'utilisateur devra donc attendre que sa sécurité soit mieux assurée.

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

La communication autour d'Heartbleed n'est pas mauvaise, elle est souvent inexistante

Le silence souvent de mise en France, malgré des cas concrets

Avoir des informations précises relève du parcours du combattant

Lorsque le flou entretient les réponses positives

La banque épargnée. Et son service de coffre-fort numérique pour vos documents ?

En cas de problème, le client sera protégé... est-ce une raison ?

Les leçons à tirer de Heartbleed et de ses conséquences

Fermer

Commentaires (26)


Encore une actu que je vais balancer à tous mes contacts (qui à force vont me détester).


Ma banque n’est pas affectée (monabanq). C’est déjà ça <img data-src=" />



Mon site web non plus d’ailleurs (OVH mutualisé).


Bizarre ce tweet de la BNP. Dommage que le reste de la discussion se soit déroulée en PV.


Merde grillé par le sous-titre <img data-src=" />








Winderly a écrit :



Encore une actu que je vais balancer à tous mes contacts (qui à force vont me détester).





À moins qu’ils ne soient eux-mêmes abonnés, ils ne pourront pas la lire <img data-src=" />









Berri-UQAM a écrit :



À moins qu’ils ne soient eux-mêmes abonnés, ils ne pourront pas la lire <img data-src=" />





D’où le bouton “offrir” <img data-src=" />









FrenchPig a écrit :



D’où le bouton “offrir” <img data-src=" />





Je viens d’apprendre quelque chose aujourd’hui… Merci <img data-src=" />



Ma banque non plus n’est pas concernée. Ouff.


cherchez pas on le saura seulement dans 6 mois voir plus les banques/organismes concernés quand les premiers problèmes (affaire en justice/fraudes) vont sortir


Pour le Crédit Mutuel, je n’ai plus spécialement confiance en leur service sécurité. J’ai pu constater un peu par hasard que si le mot de passe du compte est 12345678, n’importe quel mot de passe commençant pas 12345678 fonctionnera, le site ne faisant le test que sur la longueur attendue du mot de passe… Ce qui laisse au final une infinité de mot de passe pouvant fonctionner et pouvant accéder au compte.

Après leur avoir signalé, on m’a simplement répondu qu’effectivement c’est bien comme ça que cela marche.








wizman03 a écrit :



Ce qui laisse au final une infinité de mot de passe pouvant fonctionner et pouvant accéder au compte.





Cette infinité de mots de passe étant au minimum aussi compliqués à trouver que ton mot de passe original, ça change quoi ?

Ce qui est beaucoup plus problématique, c’est que s’ils connaissent la taille de ton mot de passe, c’est qu’il y a un risque qu’il ne soit pas stocké de manière cryptée dans leurs bases ! Là, ça m’inquièterait plus…









Faith a écrit :



Cette infinité de mots de passe étant au minimum aussi compliqués à trouver que ton mot de passe original, ça change quoi ?

Ce qui est beaucoup plus problématique, c’est que s’ils connaissent la taille de ton mot de passe, c’est qu’il y a un risque qu’il ne soit pas stocké de manière cryptée dans leurs bases ! Là, ça m’inquièterait plus…





Pas forcément.



Si leur algo fait un hash sur les 8 premiers caractères quoi qu’il arrive ça marche aussi.



Faire un hash sur 12345678 ou sur les 8 premiers caractères de 1234567890 ça ne change rien au final <img data-src=" />



Et du coup il suffit juste des tester toutes les combinaisons possibles des 8 premiers caractères au lieu des 10, 12 ou 20 caractères que tu as choisi.



(J’ai juste pris l’exemple dans le cas où de leur côté ils ne regardent que les 8 premiers caractères, c’est peut-être pas exactement comme ça que ça marche)









Khalev a écrit :



Si leur algo fait un hash sur les 8 premiers caractères quoi qu’il arrive ça marche aussi.

(…)

(J’ai juste pris l’exemple dans le cas où de leur côté ils ne regardent que les 8 premiers caractères, c’est peut-être pas exactement comme ça que ça marche)





Si c’est ça, c’est effectivement super-pourri !



Et si ce n’est pas ça, il faut qu’ils aient stocké la taille de chaque mot de passe quelque part =&gt; grosse information pour le pirate de la base.

De toutes les façons, ça semble effectivement être une drole d’idée !



A noter: on utilise souvent la taille comme premier critère pour différencier des fichiers avant de calculer leur MD5 (ou autre). Ca permet d’optimiser nettement le temps de traitement, mais pour un mot de passe, c’est une anerie.



Il est interdit de parler de taille avec un avatar comme le tien…








wizman03 a écrit :



Pour le Crédit Mutuel, je n’ai plus spécialement confiance en leur service sécurité. J’ai pu constater un peu par hasard que si le mot de passe du compte est 12345678, n’importe quel mot de passe commençant pas 12345678 fonctionnera, le site ne faisant le test que sur la longueur attendue du mot de passe… Ce qui laisse au final une infinité de mot de passe pouvant fonctionner et pouvant accéder au compte.

Après leur avoir signalé, on m’a simplement répondu qu’effectivement c’est bien comme ça que cela marche.





<img data-src=" /><img data-src=" /><img data-src=" />



Comme d’hab, le danger vient de ceux qui n’en parlent pas. <img data-src=" />


Autre exemple de traitement de la sécurité par les banques : les 4 ou 5 réseaux bancaires français vendent et font de la publicité pour le paiement sans contact (puce RFID) <img data-src=" /> En déclarant que la sécurité est garantie par la “technologie carte à puce”…



Ne vous inquiétez pas, les banques assurent, mais en cas de pépin, il faudra négocier, sacrément négocier pour un dédommagement remboursement et surtout ne pas compter sur des excuses.








Khalev a écrit :



Pas forcément.



Si leur algo fait un hash sur les 8 premiers caractères quoi qu’il arrive ça marche aussi.



Faire un hash sur 12345678 ou sur les 8 premiers caractères de 1234567890 ça ne change rien au final <img data-src=" />



Et du coup il suffit juste des tester toutes les combinaisons possibles des 8 premiers caractères au lieu des 10, 12 ou 20 caractères que tu as choisi.



(J’ai juste pris l’exemple dans le cas où de leur côté ils ne regardent que les 8 premiers caractères, c’est peut-être pas exactement comme ça que ça marche)





Ça reste moins pire que les 3 banques auxquelles j’ai à faire: LCL, Banque Postale et ING Direct qui n’utilisent même pas de mot de passe mais seulement un code PIN à 6 chiffres sur un clavier virtuel sensé protéger contre les keyloggers (comme si les keyloggers ne savaient pas faire de capture d’écran). <img data-src=" />



Édit: chez ING pour éviter les captures d’écrans et les yeux indiscrets, seuls trois caractères différents à chaque fois et au hasard sont demandés, pas sûr que ça change grand chose.



Chez boursorama banque aussi il faut entrer un code PIN à six chiffres sur un clavier virtuel dans un cyber-café ou dans un open space cela le fait moyen









wizman03 a écrit :



Pour le Crédit Mutuel, je n’ai plus spécialement confiance en leur service sécurité. J’ai pu constater un peu par hasard que si le mot de passe du compte est 12345678, n’importe quel mot de passe commençant pas 12345678 fonctionnera, le site ne faisant le test que sur la longueur attendue du mot de passe… Ce qui laisse au final une infinité de mot de passe pouvant fonctionner et pouvant accéder au compte.

Après leur avoir signalé, on m’a simplement répondu qu’effectivement c’est bien comme ça que cela marche.







Un bémol quand même. Au bout de 3 essais infructeux ton compte est bloqué.



Je ne défend pas le système de sécurité du CC hein je peste toute l’année.



Mais sincèrement le mot de passe à fait son temps. Il est temps que les banques française passent aux deux facteurs. Sur ma banque belge on ne m’a pas laissé le choix. L’authentification se fait grâce à une signature électronique faite via la carte de crédit et un boitier non relié au PC. C’est très efficace.









ben5757 a écrit :



Mais sincèrement le mot de passe à fait son temps. Il est temps que les banques française passent aux deux facteurs. Sur ma banque belge on ne m’a pas laissé le choix. L’authentification se fait grâce à une signature électronique faite via la carte de crédit et un boitier non relié au PC. C’est très efficace.





En général elles se défendent en arguant du fait qu’elles utilisent déjà le 2FA par SMS pour certaines actions, notamment les virements. Pendant un temps le LCL le faisait via un certificat et du Java, j’imagine comment ils expliquaient le truc à Mme Michu <img data-src=" />



M’enfin effectivement, les procédures utilisées pour les accès aux comptes sont dramatiquement nazes.



L’authentification en 2 temps est loin d’être la panacée je trouve. J’utilise très peu mon portable, souvent je ne l’ai pas sur moi, et franchement quand je suis pas chez moi ça me casse les pieds d’avoir besoin d’autre chose que d’un ordinateur pour accéder à mes comptes (bancaires ou non).



Je ne donne mes mots de passe à personne, je ne les partage pas entre les sites sensibles, je ne télécharge pas de virus et je ne rentre pas mes mots de passe n’importe où non plus. Si un site n’est pas capable de sécuriser l’accès avec seulement mon mot de passe (ou impose des limites débiles dessus), ce n’est pas ma responsabilité mais la sienne.



Je n’ai pas envie d’avoir à me trimbaler partout mon portable et/ou un boîtier pour chaque compte qui utilise l’authentification en 2 temps. A la limite une petite carte contenant plein de clés demandées aléatoirement comme fait ma banque avant de vouloir m’obliger à utiliser mon portable. Mais sinon, imaginez que ça se généralise, va vous falloir une brouette pour tout transporter.



Je ne connais pas la solution miracle, mais clairement pour moi ce n’est pas celle-ci.








ben5757 a écrit :



L’authentification se fait grâce à une signature électronique faite via la carte de crédit et un boitier non relié au PC. C’est très efficace.





Ce système d’authentification est certes plus fiable, mais il est aussi beaucoup plus chiant pour le client.

Quand ma banque a mis ça en place, elle a enregistré une baisse de 60% du nombre de connexions… Et nous avons tous pesté contre cette cochonnerie.



La banque a fait demi-tour tellement les clients étaient mécontents. Aujourd’hui: consultation via connexion normale et actes sensibles via authentification plus forte. C’est nettement préférable, et largement assez sécurisé.










Inodemus a écrit :



Je ne donne mes mots de passe à personne, je ne les partage pas entre les sites sensibles, je ne télécharge pas de virus et je ne rentre pas mes mots de passe n’importe où non plus. Si un site n’est pas capable de sécuriser l’accès avec seulement mon mot de passe (ou impose des limites débiles dessus), ce n’est pas ma responsabilité mais la sienne.









Je ne vois pas trop comment on peut renforcer plus la sécurité en utilisant le mot de passe + politique des mots de passe. Ca ne permet pas de se protéger contre le vol de mot de passe via un virus sur le poste client. Mise à part le 2FA, il y’a pas tellement de solution pour se prévenir du vol de mot de passe par une application malveillante. Tu en as ?



Tu aurais pas le syndrome de l’utilisateur invincible ? Le prend pas mal, mais des gens qui ont ce discours ne sont pas les derniers à êtres victime d’incident de sécurité généralement. Quoiqu’il en soit, ta position implique qu’il faut faire confiance au bon sens de l’utilisateur. C’est en parti vrai, mais penser que cela suffit n’est pas vraiment réaliste.







Faith a écrit :



Ce système d’authentification est certes plus fiable, mais il est aussi beaucoup plus chiant pour le client.

Quand ma banque a mis ça en place, elle a enregistré une baisse de 60% du nombre de connexions… Et nous avons tous pesté contre cette cochonnerie.



La banque a fait demi-tour tellement les clients étaient mécontents. Aujourd’hui: consultation via connexion normale et actes sensibles via authentification plus forte. C’est nettement préférable, et largement assez sécurisé.







Ta banque a eu raison de faire demi tour, car les clients se seraient dirigé vers une banque moins regardante sur la sécu. Elle a choisi de ne pas prendre le risque de perdre des clients (risque faible à mon sens mais je suis pas expert). Mais au fond je pense qu’il ne faut pas tenir compte des clients râleurs. Si les banques se mettaient d’accord ( ou si on leur imposait) un standard de double authentification les clients qui veulent du web banking n’auraient pas le choix.



Je ne suis pas d’accord sur le fait de protéger certaines opérations. De mon point de vue de client, l’accès au solde de compte et aux historiques de transactions est tout aussi sensible que la possibilité de faire des virements. Elle doit donc être protégé de la même façon.










ben5757 a écrit :



Mise à part le 2FA, il y’a pas tellement de solution pour se prévenir du vol de mot de passe par une application malveillante. Tu en as ?



J’essaie de ne pas taper mon mot de passe à un endroit où il pourrait y avoir des virus. J’ai justement dit que je n’avais pas d’autre solution pour sécuriser l’accès que l’authentification en 2 temps, mais ça ne veut pas dire que cette solution soit bonne. J’espère que quelqu’un trouvera le moyen de la rendre plus pratique, ou trouvera une solution différente.



A ma banque, avant il y avait la double authentification avec une carte imprimée avec un tableau de numéros, et un choisi au hasard à chaque fois. C’était une très bonne solution je trouve, la carte est facile à garder dans son portefeuille. Maintenant il ont ajouté en plus le téléphone portable, ça fait triple authentification et c’est bien lourd, il faut vraiment en arriver là ? Ailleurs il faut se trimbaler des boîtiers et c’est aussi lourd.









ben5757 a écrit :



Tu aurais pas le syndrome de l’utilisateur invincible ? Le prend pas mal, mais des gens qui ont ce discours ne sont pas les derniers à êtres victime d’incident de sécurité généralement. Quoiqu’il en soit, ta position implique qu’il faut faire confiance au bon sens de l’utilisateur. C’est en parti vrai, mais penser que cela suffit n’est pas vraiment réaliste.



Personne n’est invincible, et je n’ai rien à dire pour ma défense parce qu’on pourra toujours me dire que j’ai eu de la chance jusqu’à maintenant, mais l’utilisateur est à mon avis bien souvent le maillon faible. Je ne suis pas expert (ni même bon) en sécurité, mais je doute que la majorité des mots de passes soient volés par des virus (qu’il faut encore se choper), mais plutôt par une faute de l’utilisateur (qui est aussi le plus souvent à l’origine de l’installation du virus s’il y a lieu). De bonnes pratiques réduisent quand même très fortement les risques. Quelqu’un de mieux renseigné que moi pourrait-t-il commenter ça ?



Après je comprends ta problématique d’éducation de tous les utilisateurs, et je n’ai pas de solution pour ça. Mais je pense que c’est clairement ça la cause du problème, il est impossible de s’assurer des bonnes pratiques de la totalité des utilisateurs. J’imaginais qu’avec le temps ça allait changer positivement, mais ce n’est à priori pas ce qui s’est passé.









ben5757 a écrit :



De mon point de vue de client, l’accès au solde de compte et aux historiques de transactions est tout aussi sensible que la possibilité de faire des virements.



Question de point de vue, moi je ne trouve pas que les 2 soient aussi sensible. Mais même si tu le penses, je doute que ceux qui essaient de voler des mot de passe partage cet avis, et je pense que personne ne va s’amuser à mettre en place une stratégie de vol de mot de passe s’il sait qu’il ne pourra que regarder des relevés de compte.









ben5757 a écrit :



Je ne suis pas d’accord sur le fait de protéger certaines opérations. De mon point de vue de client, l’accès au solde de compte et aux historiques de transactions est tout aussi sensible que la possibilité de faire des virements. Elle doit donc être protégé de la même façon.





Ca n’a pas de sens de mettre ces deux choses sur le même plan.

D’un coté tu as un risque financier fort et de l’autre, tu as une vague possibilité de risquer de recevoir un spam…



Surtout que l’historique de tes transactions et toutes tes infos personnelles sont déjà à la libre disposition de très nombreuses personnes… y compris les scans de toutes tes pièces d’identité, impôts et autre.



Tu mettais en garde Inodemus contre un syndrome, je vais donc me permettre de te mettre en garde contre un autre syndrome: celui du paranoïaque qui laisse sa fenêtre ouverte ;)