N26 corrige plusieurs failles, la sécurité des « néo-banques » en question
UX is not enough
Le 29 décembre 2016 à 08h47
7 min
Internet
Internet
N26, souvent décrite comme « l’étoile montante de la FinTech », publiait récemment un billet expliquant la correction de failles de sécurité découvertes par Vincent Haupert. Celui-ci participait cette semaine à la conférence 33C3 pour en donner les détails. De quoi inciter à s'interroger sur la sécurité des « néo-banques ».
Les « néo-banques », ces nouveaux services « FinTech » entièrement tournés vers un usage mobile qui promettent de révolutionner notre relation à la gestion de notre argent passent une mauvaise fin d'année.
Outre les soucis financiers de Morning, N26 (anciennement Number26) évoquait le 14 décembre avoir été alertée par un chercheur en sécurité, Vincent Haupert, au sujet d’un problème potentiel. Pour celle qui se décrit sur son site comme « la banque la plus moderne d’Europe », cela pose souci.
Une annonce passée presque inaperçue
Les détails de la brèche n’ont pas été donnés dans l’immédiat. N26 indiquait seulement avoir travaillé main dans la main avec Haupert pour examiner le problème et le résoudre. Ce dernier s’est donc rendu dans les locaux de l’entreprise à Berlin, et la faille, quelle qu’elle soit, a été déclarée comme résolue. N26 le cite d’ailleurs, indiquant qu'il loue la réactivité de la banque sur le sujet.
Plusieurs informations importantes étaient néanmoins données. D’une part, aucun client n’avait été touché par la faille. Les comptes n’ont donc pas été en danger, et il n’y a pas eu de transferts frauduleux d’argent. D’autre part, N26 a ouvert un programme de chasse aux bugs (bug bounty), une pratique bien connue des entreprises, qui récompensent les découvreurs de failles afin de les dissuader de les vendre aux plus offrants.
Quand simple s'approche trop de simpliste
Mais on en sait désormais davantage sur ce qu'il s'est passé. Vincent Haupert participait cette semaine à la 33ème édition du Chaos Communication Congress (33C3) et intervenait sur la sécurité des banques en ligne, avant de basculer sur le cas précis de N26 pour détailler sa découverte. Il a ouvert son intervention par un avertissement sur la sécurité générale de la FinTech (Financial technology), qu’il estime souvent plus intéressée par les belles interfaces à succès que par la protection des données et, dans le cas présent, des sommes placées.
Il a commencé par rappeler quelques fondamentaux sur N26, plantant le décor du succès de l’entreprise. Fondée en 2013 et active depuis 2015, la banque annonce gérer aujourd’hui 200 000 clients en Europe. La simplification extrême du processus voulu par N26 permet au client d’ouvrir un compte en seulement 8 minutes, faisant du smartphone un « hub financier ». La conception de l’application permet de se concentrer sur le principe de simplicité.
Mais selon Haupert, « simple » ne doit pas signifier « simpliste », surtout quand on parle de sécurité. Il a commencé par redonner les quelques étapes requises pour créer un compte et commencer à transférer de l’argent. D’abord un couple adresse email et mot de passe, puis un code PIN qui servira à valider les opérations, et enfin un code d’appairage pour un appareil unique.
Ce dernier est la mesure la plus importante. Au premier démarrage, l’application génère une paire de clés RSA et envoie la clé publique sur les serveurs de N26. Chaque nouvelle transaction est confrontée au service distant, l’application déchiffrant alors la communication avec sa clé privée. C’est celle-ci qui limite évidemment l’appairage à un seul smartphone.
Une attaque par homme-du-milieu
La communication entre l’application et l’infrastructure de N26 se fait en JSON sur une connexion HTTPS, mais sans couche de chiffrement supplémentaire sur les données échangées. Vincent Haupert a donc été capable de réaliser une attaque de type « homme du milieu » (MITM) en ciblant leur protocole. Une attaque d’autant plus facilitée que le client (donc l’application) n’effectue aucune vérification spécifique (notamment via un « épinglage de certificat »).
À partir de là, le chercheur était capable de manipuler un certain nombre d’éléments. Par exemple, modifier le récipiendaire, c’est-à-dire la personne qui doit recevoir les fonds. On comprend aisément le danger d’une telle faille, tout comme le titre de son intervention (« Shut up and take my money »). Si un attaquant avait pu prendre le contrôle du DNS pour l’adresse api.tech26.de – qui sert à valider les opérations – il pouvait manipuler les transactions en temps réel.
Le détournement du DNS entraîne tout le reste
Mais parvenir avec succès à détourner le DNS ne permet pas seulement de réorienter les transactions. L’attaquant peut en effet obtenir aussi le contrôle complet du compte, à condition d’en connaître les détails. Avec une technique assez classique de phishing (choix d’un domaine très proche), on peut contacter l’utilisateur et l’inviter à changer son mot de passe. Une fois les identifiants obtenus, la version iOS de N26 peut procéder à des transferts sans même réclamer le code PIN.
Haupert s’est aussi attaqué à une affirmation de la banque : toute activité suspecte est détectée et bloquée avant même qu’elle ne survienne. 2 000 transactions d’un centime ont donc été envoyées en 30 minutes. Non seulement N26 n’a réagi qu’au bout de trois semaines pour demander des explications, mais la banque souhaitait même fermer le compte… du récipiendaire (Dominik Maier, professeur d'Haupert).
Apparaige et code PIN : pas de problème
Il était également possible d’obtenir le désappairage du smartphone principal, pour en déclarer un autre. Cette procédure est normalement très sécurisée, car il faut posséder les identifiants, la Mastercard obtenue avec le compte et la carte SIM, puisqu’un jeton de sécurité est envoyé par SMS. Mais le lien de désapparaige est renvoyé par le serveur, et l’identifiant de la Mastercard circule dans chaque transaction. Des informations que l’on peut donc récupérer quand l’attaque MITM a réussi.
Quant au code PIN, on pourrait ajouter qu’il s’agit du clou du spectacle. Tout ce qu’il faut pour le réinitialiser est en effet... l’identifiant de la Mastercard. Dès qu’il est entré, l’utilisateur peut entrer un nouveau code PIN, sans que l’application ne réclame l’ancien.
Tous les problèmes ont été résolus
De fait, la « vulnérabilité théorique » abordée par N26 consiste en une liste de problèmes dont Vincent Haupert a fait l’inventaire durant la conférence. D’un certain côté, on peut effectivement les ramener à une brèche unique, puisque l’exploitation frauduleuse des comptes et le contrôle des transactions ne peuvent être mis en place que si l’attaque MITM a fonctionné.
Cependant, et même si cette faille est corrigée, certaines pratiques élémentaires méritaient d’être révisées. On peut ainsi s'interroger sur le fait qu'un nouveau code PIN puisse être déclaré sans réclamer une information que seul l’utilisateur est censé connaître, comme son ancien code. L’identifiant de la Mastercard n’est en effet pas suffisant puisque l’information circule notamment dans les ordres de transaction.
Quoi qu’il en soit, N26 assure que le problème est résolu, et Vincent Haupert a confirmé que plus aucune des vulnérabilités signalées ne subsistait. Reste maintenant à voir si tous les autres acteurs du domaine bancaire, nouveaux venus ou non, gèrent correctement la sécurité de leurs différentes applications.
N26 corrige plusieurs failles, la sécurité des « néo-banques » en question
-
Une annonce passée presque inaperçue
-
Quand simple s'approche trop de simpliste
-
Une attaque par homme-du-milieu
-
Le détournement du DNS entraîne tout le reste
-
Apparaige et code PIN : pas de problème
-
Tous les problèmes ont été résolus
Commentaires (71)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 29/12/2016 à 10h26
Le 29/12/2016 à 10h27
Le 29/12/2016 à 10h32
Le 29/12/2016 à 10h33
Le 29/12/2016 à 10h34
Il est tout aussi légal de dire “On déchiffre tout pour notre propre sécurité et les accès aux données déchiffrées sont contrôlés suivant le cadre légal. Si vous allez sur votre site bancaire dans ces conditions, c’est votre problème.”
Dès lors que ce cadre est posé, il n’y a plus d’obligation d’exclure quoi que ce soit.
Dans la même veine, pour éviter les conflits, il est aussi légal de dire: “On déchiffre tout, et on interdit complètement les sites bancaires (et quelques autres du même genre inutiles pour votre boulot) comme ça vous ne viendrez pas vous plaindre qu’on vous espionne.”
Ce qui est important, c’est de poser officiellement les règles. Une entreprise n’a pas d’obligation légale de respecter la tolérance habituelle en termes d’utilisation personnelle de l’accès Internet en France, du moment que ses employés sont au courant des règles, et qu’elles ne sont pas discriminatoires. C’est seulement si elle choisi d’être tolérante qu’elle a intérêt d’exclure les sites bancaires, administratifs, etc., pour éviter les conflits au prud’hommes.
Le 29/12/2016 à 10h35
Certes, s’il y a une faille ça touche tout le monde mais en même temps, quand elle est corrigée, elle l’est pour tout le monde. Parce que bon, dans les faits, les failles sont plus souvent dans les protocoles ou les api quand dans le code lui-même, donc de toute façon, une faille touche un grand nombre de site.
Le 29/12/2016 à 10h35
Mais là tu parles d’une grosse boîte avec un process de développement bien défini.
Dans la vraie vie les boîtes comme N26 recrutent 10 personnes pour lancer le projet et basta, les specs sont données par des personnes qui n’y connaissent techniquement rien, la sécurité est gérée par des mecs qui ont probablement des notions mais qui ne sont pas experts, et comme toujours l’emploi du temps est très serré donc pas le temps de se former proprement.
Le 29/12/2016 à 10h38
Pour le coup ça me paraîtrait normal qu’une banque soit dans l’obligation de faire passer un audit de sécurité par un organisme indépendant à ses frais. Ca fait un peu partie des choses dont tu dois tenir compte quand tu finances ton projet et ça ne devrait pas être un problème que la banque supporte les coûts.
J’ai même envie d’aller plus loin, le produit devrait recevoir une certification type EAL4+ ou un truc similaire.
Le 29/12/2016 à 10h43
La régulation ça commence déjà par faire porter par la banque le dédommagement des pertes subies par ses clients qui prouvent qu’ils ont été fraudés (c’est partiellement implémenté). Ensuite, tu peux imposer aux banques la réalisation d’audits one shot ou réguliers >>à ses frais<< pour être autorisée à fournir certains services. Les audits sont faits par des entreprises tierces spécialisées. C’est un modèle qui marche bien et qui est utilisé dans un nombre incalculable de cas de figure aujourd’hui, pas seulement bancaires. Les points importants à surveiller sont que le coût de l’habilitation ne soit pas exorbitant au point d’empêcher l’entrée de nouveaux acteurs, et que les autorités certifiantes soient bel et bien indépendantes des intérêts économiques et financiers des entreprises à certifier.
Le 29/12/2016 à 10h44
“Pour celle qui se décrit sur son site comme « la banque la plus moderne d’Europe »”
Faudra qu’on m’explique en quoi elle est plus moderne qu’une autre banque en ligne type boursorama?
Elle est plus chère, impose un nombre limite de retraits par mois dans les distributeurs…
Le 29/12/2016 à 10h45
Le 29/12/2016 à 10h51
Le 29/12/2016 à 10h52
Le 29/12/2016 à 10h56
Le 29/12/2016 à 11h00
J’y connais pas grand chose, j’ai sorti ce nom là parce que c’est ce que j’ai vu dans un précédent boulot.
Mais la finance est la base de notre société (que l’on trouve ça bien ou pas), ça serait pas mal que cette base soit fiable.
Le 29/12/2016 à 11h14
MAis enfait il y a déjà des normes et audit/controles…
Exemple: ACPR
Un pdf Quelques infos
Le 29/12/2016 à 12h01
Le problème est que le dev doit faire son taf de dev et pas s’improviser architecte. En l’occurrence il manque sûrement ce genre de profil chez N26 (ou alors il est super mauvais) pour définir tous les aspects d’une application
Le 29/12/2016 à 12h13
Je ne prétends pas non plus décrire une solution miracle. Tous les athéistes présents seront d’accord avec moi sur le fait que, de toutes façons, les miracles ça n’existe pas. Ce n’est pas le sujet.
Mon intervention était en réponse à “je ne vois pas comment il pourrait en être autrement” (que laisser la sécurité des banques aux seules mains des banques). Et bien voilà, comme ça. Il en est autrement, comme ça. Réglementations, obligations d’audit, charge de la preuve et obligation de rembourser qui pèsent par défaut sur la banque dans certains cas, etc. Les banques ont des comptes à rendre sur leur sécurité et elles se voient partiellement dicter par des tiers comment l’implémenter. C’est tout ce que je dis.
Le 29/12/2016 à 12h43
Le 29/12/2016 à 13h08
Pas de certificate pinning sur une appli bancaire c’est un peu chaud. Après pour réussir un MITM sur du TLS il faut quand même parvenir à installer son certificat sur la machine cible, ce qui est loin d’être gagné sans accès physique.
Edit: après y’a pire, bien pire :phttps://boris.in/blog/2016/the-bank-job/
Le 29/12/2016 à 13h10
Le 29/12/2016 à 13h16
Architecte cela ne veut rien dire seul, cela peut être un architecte solution, technique généraliste, web, mobile, infra… En soit, ce n’est pas le role de l’architecte d’être un expert securité. Il y a des rôles pour cela, notamment l’officier de sécurité.
J’aimerai à penser que le secteur bancaire est suffisament reglementé pour imposer des audits de sécurités.
Le 29/12/2016 à 13h29
D’après la video, c’est surtout possible après le détournement DNS. Par contre il ne dit pas comment il fait pour avoir un certificat valide sur le domain détourné. A moins que l’app accepte les certificats self signed, ce qui serait quand même étonnant.
Le 29/12/2016 à 13h36
pour résumer les boites feraient mieux d’investir dans la sécurité digitale plutôt que dans le marketing digital.
Le 29/12/2016 à 14h03
Pour la sécurité digitale, je préconise des gants, pour éviter aux doigts de nombreux problèmes. " />
—–
Sur l’appli de ma banque, la Caisse d’Epargne, il y a un suivi des comptes (le solde par exemple) sans connexion nécessaire. (Oui, c’est bien mis à jour sans la connexion.)
J’ai bien envie d’aller écouter les requêtes, je sens que je vais être surpris. " />
Le 29/12/2016 à 14h06
Le 29/12/2016 à 14h47
Le 29/12/2016 à 14h52
Au temps pour moi, je faisais plusieurs trucs à la fois en plus de lire NextInpact, j’ai effectivement mal compris ton message " />
On est bien d’accord du coup " />
Le 29/12/2016 à 15h03
Le 29/12/2016 à 15h23
Le 29/12/2016 à 15h39
En quoi le cobol serait moins securitaire ?
Les trous de sécurité sont tous au niveau de la couche d’échange avec un éventuel traitement sur du mainframe.
Le 29/12/2016 à 16h11
A quoi ça sert de corriger des failles si le service n’est même pas utilisable ?
Le 29/12/2016 à 17h12
Le 29/12/2016 à 17h17
Le 29/12/2016 à 17h32
Ton argument sur le Cobol n’est pas vraiment valide. SI tu as regardé la vidéo de la conférence, tu peux voir qu’à aucun moment il ne s’attaque à l’application qui tourne sur les serveurs de N26. Il exploite des failles dans le protocole. Donc que ce soit codé en Cobol, C, PHP ou JS n’y change absolument rien.
Le 29/12/2016 à 17h34
De plus, bien qu’il y ait 3 tonnes de règlements (c’est effectivement le cas ‘^_^), peu de vérifications externes sont réalisées (pour ainsi dire, aucune). Et N26, disposant d’une licence bancaire, doit se conformer aux même règlements que les autres banques.
Le 29/12/2016 à 17h41
Des exemples d’exploitations de failles de sécurité on n’en a pas beaucoup car dès que la banque s’en rend compte elle prend sur ses fonds propres (ils provisionnent pour ce genre de risques), replace les sous sur les comptes clients ni vu ni connu, et l’affaire est glissée sous le tapis.
Ca fait quand même les gros titres de temps en temps :http://www.leparisien.fr/corbeil-essonnes-91100/a-corbeil-800-000-eur-detournes-…
Le 29/12/2016 à 17h52
Pas besoin d’installer son certificat sur la machine cliente. Il “suffit” de compromettre les enregistrements DNS (plusieurs méthodes, telles que le DNS cache poisonning) pour que l’adresse voulue (api.tech26.de dans le cas présent) pointe vers ton serveur, et obtenir un certificat signé par une autorité (l’exemple de let’s encrypt est utilisé dans la conférence, mais d’autres autorités ont délivrés des certificats à des pirates par le passé…).
Le 29/12/2016 à 17h59
Oui alors là, c’est de la grosse négligence interne, pas un hack depuis l’extérieur via le site d’accès client. En gros la porte était ouverte, il est entré.
Le 29/12/2016 à 18h11
J’ai mis le premier lien que j’ai trouvé, et bien que ça ne passe pas par le web-banking, ça reste dû à un manquement dans la politique de sécurité informatique interne de LBP.
Je travaille dans la sécurité informatique, j’ai eu pas mal de banques (et pas qu’en France) parmi mes clients, et je peux te garantir que les équipes en charge de rattraper la fraude ne chôme pas ;-)
Le 29/12/2016 à 19h19
Non, sérieusement ? sans dec ? ils en étaient là ? vraiment ?
Oulala… la base de la sécu même pas respectée ? la base de la monétique non considérée ? " />
Et après ça vient parler des grands groupes bancaires… j’ai un sérieux doute sur leur sérieux a eux aussi.
Effectivement, il ne faut pas confondre vitesse et précipitation " />
Le 31/12/2016 à 20h57
Le 02/01/2017 à 09h27
Oui l’entreprise le peut, d’une méthode similaire à un Man In The Middle.
C’est assez pratique en réalité : possibilité d’appliquer des règles de filtrage, possibilités d’exécuter des antivirus, QoS etc. La plus part du temps, çà ce limite à çà : aucun humain ne peut accéder au contenu de ce que l’utilisateur visite. D’ailleurs, la loi en France (Europe ?) demande à ce que les sites bancaires soient exemptés de ce “déchiffrement” à la volée.
Le proxy intercepte la requête du client, et se charge de négocier le “tunnel https”, il chiffre à nouveau la connexion entre lui et le client sur le LAN via son propre certificat.
Le 04/01/2017 à 19h24
Car l’age et le nombre de mainteneurs de cette techno, ainsi que son design non pensé pour les archi actuelles le rendent potentiellement moins sûr.
Le 29/12/2016 à 08h58
bas oui mais à pousser le salaire des devs par le bas et à se retrouver avec des chef de projets qui ont à peine 6 mois de boite ça finit à “rien foutre de la sécu, l’appli tourne c’est tout ce qu’on m’a demandé”
Le 29/12/2016 à 09h02
C’est une des possibilités.
Après t’as aussi ceux bien payé, qui se croient compétents et qui en fait ne le sotn pas.
Le 29/12/2016 à 09h05
Appli mobile comme web d’ailleurs.
Là où je travaille, notre appli web qui gère la génération des licences de ce que nous vendons n’est pas sécurisée. Pas de HTTPS, mes identifiants sont mes initiales et mot de passe… pareil avec 2 chiffres en +. Je ne peux évidemment pas le changer. Et pour couronner le tout, pas de timeout sur la session, si mon navigateur reste ouvert je suis connecté ad vitam aeternam.
J’ai signalé ces quelques trucs mais ce qu’on m’a dit c’est que “c’est bon ça craint rien” et que “pleins de gens utilisent ça donc on peut pas faire de maintenance dessus”…
Le 29/12/2016 à 09h10
Le principe d’une faille c’est justement que personne y a penser. Expérimenté, Débutant, Bien payé ou mauvais payeur. Tu peux même avoir eu un audit de sécurité qui soit passé par là et ne l’ai pas détecté.
L’important dans ce domaines c’est surtout le suivi et la réactivité.
Le 29/12/2016 à 09h11
Pareil chez nous, on a même pousser le vice jusqu’à enregistrer tout les mots de passes (y compris des manager) dans une seule et même…matrice Google Sheets.
Je suis dans une boite Multi-produits, et nos techniciens n’ont même pas séparés les disques dur des différents services, tu bosse pour une boite X t’a accès aux docs de la boite Y " />" />" />
Le 29/12/2016 à 09h12
Etre mal payé ne justifie pas de faire un boulot de merde et en principe, même débutant, tu es sensé être formé à ton métier. Du reste, s’il suffisait d’avoir des développeurs de tout premier ordre et du personnels sur payés pour éviter les failles, ça se saurait " />
Le 29/12/2016 à 09h14
Le 29/12/2016 à 09h18
Effectivement, le chef a toujours raison, quel que soit son âge : c’est lui qui décide et c’est toi qui creuse.
Le 29/12/2016 à 09h21
Article intéressant. La sécurité bancaire est trop souvent laissée à la discrétion des banques.
Le 29/12/2016 à 09h30
Le 29/12/2016 à 09h37
Lol quand on regarde les autres banques c’est loin d’être mieux. Pourquoi se focaliser sur N26 ?
J’ai assisté a une conf Credit Agricole ou le présentateur envoyait un SMS et piquait 1€ en direct a toute l’audience.
Quand on voit les inepties des banques classiques, codes a 4 chiffres, clavier “anti-keylogging” sur un smartphone, validation par SMS ou date de naissance, etc… Les failles sont partout, et N26 est loin d’être la pire.
N26, Monzo, etc. ont justement tout à prouver et sont basées sur des archi modernes, ça craint certainement moins que certaines banques utilisant des serveurs qui font tourner du Cobol depuis 30 ans.
Le 29/12/2016 à 09h42
Le 29/12/2016 à 09h44
Le 29/12/2016 à 09h49
Le 29/12/2016 à 09h52
Le 29/12/2016 à 09h54
Oui c’est légal, mais il y a des conditions. Et oui les banques sont sensée être exclus de la désencapsulation https.
Le 29/12/2016 à 09h55
Le 29/12/2016 à 09h55
Comme çà, il n’y aurait qu’une seule cible à faire tomber ?
Et qui est responsable de la sécurité entre cette solution centralisée et les différentes banques ?
Le 29/12/2016 à 09h59
L’idée n’est pas anti jeunisme. C’est juste qu’un chef de projet, sur des appli critiques, vaut mieux qu’il ai un peut de bouteille. Quant il est tout frais (moins de 6 mois comme il dit), tu prend bien plus de risque.
Après comme pour tout y a des exceptions.
Le 29/12/2016 à 10h01
Ah ok, si tu parles effectivement d’un gros problème de connaissances et communications alors je suis entièrement d’accord.
J’ai un exemple aussi: ma carte visa a été utilisé pour faire des achats en ligne (je me demande bien d’où vient la fuite…). Évidemment, j’ai fait opposition, et donc ma carte a été désactivée.
Par contre ma nouvelle carte à mis du temps à être disponible: le lot de nouvelles cartes a été perdues/volées au niveau du transporteur… mais çà je ne l’ai jamais su officiellement, çà leur à échappé oralement… c’est dingue tout de même. Même quand ce n’est pas complètement de leur faute, il ne faut pas communiquer.
Le 29/12/2016 à 10h02
Oui enfin le cahier des charges et les specs elles ne sont pas à la charge du chef de projet théoriquement… ou au moins, il doit y avoir des validations par la direction/hiérarchie.
Le 29/12/2016 à 10h02
triste époque
Le 29/12/2016 à 10h03
Ça fait seulement quelques années que je vois la sécurité venir sur le devant de la scène.
C’est ralenti aussi par le fait du “pourquoi en changer, ça marche très bien comme ça”, dans certaines boîtes où j’ai bossé, le mot de passe principal était le même car “codé en dur” dans certains binaires et trop complexes à changer partout et bien sur mot de passe en clair dans les fichiers de conf.
Donc en gros si t’as bossé pour cette boîte, tu vas chez n’importe quel de leur client, tu peux faire tout ce que tu veux car le mot de passe est le même, et vu l’appli, tu peux en tirer un bon bénéf.
C’est toujours basé sur le ratio “coût/risque” mais d’année en année le risque augmente, d’ailleurs on le voit avec la fréquence des leak de données.
Le 29/12/2016 à 10h06
Là, on a quand même des problèmes technique. Donc si c’est à la charge du chef de projet. Même s’il est pas le seul responsable.
Le 29/12/2016 à 10h08
La première des sécurités de N26, c’est surtout qu’on ne peut pas s’y inscrire à cause d’un processus de vérification d’identité calamiteux et un SAV aux oubliettes.
Le 29/12/2016 à 10h21
Il veut dire par là que l’on laisse les banques juger elles-même de la qualité de leur sécurité, sans avoir de comptes à rendre. Pour “qu’il en soit autrement,” il suffit d’introduire dans le processus un tiers régulateur et des sanctions.
Le fond du problème ici est l’externalisation du risque : ce n’est pas la banque elle-même qui souffre d’une faible sécurité. Améliorer cela réduit les revenus de la banque. Elle n’a donc aucune motivation pour corriger sa sécurité. La régulation, tellement détesté par la finance, est une façon d’écrire dans la loi que la banque a la responsabilité de la sécurité financière de ses clients, et donc qu’elle peut être sanctionnée. Du coup, le risque est réinternalisé (la banque paye pour ses manquements) et la situation s’améliore.
Le 29/12/2016 à 10h25