Identification : le secteur bancaire, royaume de la sécurité ?

Créé le

21.01.2019

-

Mis à jour le

31.01.2019

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.

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 GnuP [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 ! 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)…

 

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.
5 https://sweet32.info/.
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.

À retrouver dans la revue
Revue Banque Nº829
Notes :
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.
5 https://sweet32.info/.
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.