Quand l'ami Aeris publie une critique de la sécurité informatique mise en œuvre par les banques dans la revue lue par tous les Directeurs des Systèmes d'Information (DSI) du monde de la banque et de l'assurance… Rien de nouveau pour nous, une petite baffe pour eux. Bien joué. \o/
Ce papier, publié dans une revue sérieuse, a aussi le mérite de contredire le discours de tout DSI lorsque l'on évoque la possibilité d'améliorer la sécurité informatique de l'organisme pour lequel on bosse "tsss tsss tsss les banques font comme nous, c'est que ça doit pas être aussi mal que tu le prétends, boucle-la". Hé bah non, les banques ne sont pas un exemple à suivre.
La meilleure illustration de ça, c'est quand même le site web de cette revue (lue par tous les DSI du secteur bancaire, je le rappelle) qui ne propose pas le chiffrement de la communication. Pour créer un compte, il faut saisir une adresse emails, un mot de passe, une civilité, un prénom, un nom et une adresse postale complète. Tout cela circule donc sans chiffrement entre le client et le serveur. De même, les infos collectées ne servent à rien pour mener à bien l'achat d'un exemplaire numérique. Leur collecte est donc contraire au principe de collecte minimale du RGPD. On parle bien de la revue de référence du milieu bancaire.
Spécialiste de la sécurité informatique et cofondateur du festival Pas Sage en Seine, Nicolas Vinot s’était penché, lors de l’édition 2017, sur la sécurité des applications et des sites bancaires*. En ce début 2019, son constat reste très mitigé.
Les banques sont souvent perçues comme des chambres fortes inviolables, et étant donné la criticité du secteur, ses clients s’attendent à ce qu’elles le soient. Mais qu’en est-il en pratique ? Il s’avère qu’en réalité, ce monde n’a que peu évolué depuis son passage à Internet… Les espaces « sécurisés » en ligne demandent généralement à l’utilisateur d’utiliser un clavier virtuel pour saisir son mot de passe à la souris sur un clavier dont la position des chiffres change à chaque connexion. Les banques espèrent ainsi que si l’ordinateur est infecté par un logiciel malveillant, le clavier virtuel empêche de lire le code secret. En pratique, c’est dorénavant le collègue de bureau ou l’enfant, attaquants bien plus probables qu’un malware, qui peut noter sur l’écran la composition de votre code… D’autant plus que les malwares, eux, ont suivi l’évolution des techniques de protection des banques et ne sont guère plus gênés par un clavier virtuel.
Des mots de passe dignes des années 1970
La sécurité minimale d’un mot de passe donnée par l’ANSSI [1] est de 78 bits et celle recommandée, de 128 bits. Alors que la plupart des banques imposent un mot de passe uniquement composé de 5 à 8 chiffres, soit 16 à 26 bits de sécurité… Ce qui se casse en quelques millisecondes seulement avec du matériel informatique classique [2] !
Les banques justifient ce choix par le fait qu’après quelques tentatives, le compte est verrouillé. Il empêcherait donc un attaquant de s’infiltrer. Mais cette protection n’existe pas si la base de données de la banque finit dans la nature à la suite d’une fuite de données ou d’un piratage, comme c’est malheureusement aujourd’hui la norme. L’attaquant aura tout loisir de casser le mot de passe sans cette limitation pour ensuite se connecter en une seule tentative sur l’espace sécurisé…
Pour garantir la sécurité de leurs clients, les banques devraient imposer des mots de passe robustes et autoriser en tout cas l’usage d’un gestionnaire de mots de passe pour leurs clients qui le souhaitent réellement. Elles mettraient aussi en œuvre la double authentification, comme a pu le faire le Crédit Coopératif avec son boîtier Sésame (malheureusement abandonné depuis), ou avec des solutions basées sur un téléphone mobile ou une clef USB.
Il me semble que la plupart des banques valident les transactions par la saisie d'un code reçu par SMS voire généré par un boîtier qui avale la carte bancaire.
Un suivi de l’état de l’art inexistant
Alors qu’il existe des solutions accessibles à tous pour protéger son courrier électronique et s’assurer que seul le destinataire véritable aura accès au contenu, les banques préfèrent souvent communiquer par des mails avec un avertissement « En cas de mauvaise distribution, merci de ne rien lire et de détruire ce message », et mettent le contenu réel du message sur l’espace messagerie « sécurisé » (souvent inaccessible ou en maintenance). Par exemple, l’usage de GnuPG [3] permettrait de mettre fin au phishing, l’utilisateur pouvant avoir la certitude qu’un message provient bien de son conseiller et non d’un pirate usurpant son identité. Fini le pifomètre à la recherche de fautes d’orthographe ou d’URL inhabituelles !
Ouais, alors OpenPGP (GnuPG n'est qu'une implémentation parmi d'autres)… C'est compliqué pour les administrateurs de systèmes GNU/Linux dotés de 5-10 ans d'expérience, alors pour le novice, c'est totalement inacessible (j'ai essayé, et ça ne prend pas)… La configuration par défaut est trop permissive. La signature de la clé de ton conseillier bancaire (afin d'indiquer à GnuPG que tu fais confiance à tout ce qui est signé par elle) sera une plaie, surtout avec le turn-over qu'il y a dans ce milieu-là…
Les banques ne mettent pas non plus en œuvre les mécanismes requis par l’état actuel des connaissances [4]. À titre d’exemple, en août 2016 a été publiée la faille Sweet32 [5] mettant en cause le protocole HTTPS. En mars 2017, sur 35 banques testées, six seulement avaient pris les mesures nécessaires pour s’en prémunir. Le protocole TLS v1.0 a été interdit en juin 2018 [6] par la norme bancaire PCI-DSS, car faillible à des attaques comme POODLE [7] ou BEAST [8] ; sur 73 banques testées en janvier 2019, 43 le supportent encore. Pire, sept banques ne supportent encore que ce seul protocole…
Les banques ne sont pas les seules responsables
L’état problématique de la sécurité des banques n’est pas à mettre à leur seul crédit, mais aussi indirectement à celui de leurs clients. La résistance au changement est en effet extrêmement forte dans le domaine de la sécurité. Les intérêts à court terme sont difficiles à percevoir (risques incertains et nébuleux, « rien à cacher »…) alors que les inconvénients, eux, sont immédiatement visibles (nécessité d’un gestionnaire de mots de passe ou d’un périphérique d’authentification, difficulté de connexion en situation de mobilité…). Et de manière générale, l’utilisateur final n’est que peu informé, le sujet étant technique et l’état de l’art très mouvant. Les banques n’ont finalement fait que suivre le mouvement, se limitant à une sensibilisation simpliste (vérifier la présence d’un cadenas et d’une barre verte dans la fenêtre du navigateur) et dans l’impossibilité de suivre les préconisations techniques sans accompagnement des utilisateurs qui risquent d’être récalcitrants (mise à jour des navigateurs, support)…
J'aurais plutôt conclu sur l'éternelle friction entre le Responsable de la Sécurité des Systèmes d'Informations (RSSI) et le Directeur Administratif et Financier (DAF). Quand le RSSI souhaite retirer telle version du protocole SSL ou TLS, qu'il expose à la direction que cela va exclure les 3 % de clients qui utilisent encore IE 6 (ce chiffre date de 4-5 ans), donc augmenter le coût du support téléphonique aux clients, et que cette évaluation sommaire ne prend pas en compte l'impact que ce changement produira sur les API qui permettent le paiement déporté (TPE, redirection vers le site web de la banque depuis un site web marchand, etc.), le DAF se met à hurler "nope nope nope, argent d'abord, argent d'abord, nope nope nope" et la direction de la banque se range derrière l'avis de ce dernier. Comment espérer un autre comportement dans un monde où la course aux bénéfices est plus importante que tout ?
[1] Agence nationale de la sécurité des systèmes d’information : https://www.ssi.gouv.fr/administration/precautions-elementaires/calculer-la-force-dun-mot-de-passe/.
[2] https://howsecureismypassword.net/.
[3] https://www.gnupg.org/ ; logiciel open source transmettant des messages électroniques signés et chiffrés, garantissant ainsi leurs authenticité, intégrité et confidentialité, ndlr.
[4] Cf étude réalisée par Nicolas Vinot : https://imirhil.fr/tls/banks.html.
[6] https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls.
[7] https://www.imperialviolet.org/2014/12/08/poodleagain.html.
[8] https://bug665814.bmoattachments.org/attachment.cgi?id=540839.
Nicolas Vinot
Co-fondateur festival Pas Sage en Seine
Spécialiste de la sécurité informatique* Cf étude réalisée par Nicolas Vinot : https://imirhil.fr/tls/banks.html. L’étude consiste à répertorier sur les sites les outils de sécurisation employés, en fonction de leur efficacité évaluée à partir des bonnes pratiques prônées des organismes officiels tels que l’IETF (Internet Engineeering Task Force), l’ANSSI en France (https://www.ssi.gouv.fr/uploads/2016/09/guide_tls_v1.1.pdf) et en fonction de l’état de l’art concernant les failles de sécurité connues des différents protocoles.