Moi je comprends qu'il n'y a rien à attendre des banques sur ce sujet
C’est exactement ça. C’est pas en pleurant « ouin les banques y sont michantes, moi je veux du root sur mon téléphone et puis voilà » que ça va changer. La réponse sera « non » et pour de très très bonne raison. Parce que quelqu’un qui me dit « je veux de la sécurité » et en même temps utilise un OS rooté ou un bootloader non verrouillé n’est lui-même pas très cohérent.
Vous voulez des applis bancaires qui tournent sur vos OS ?
Vous faites comme Let's Encrypt à l’époque de son démarrage, vous montez une infra sécurisée avec des HSM dans un bunker, vous passez quelques millions d’euro en certification et vous montrez patte blanche auprès des organismes bancaires, avec une cross-certification pour commencer par Google/Apple pour pouvoir commencer à bootstraper avant d’avoir votre truc certifié en autonome.
Et en fournissant aussi des SDK côté mobile pour gérer ces trucs suffisamment facilement pour que les devs côté banque n’aient pas trop de taff à faire pour sortir de Play Integrity ou autre.
Et en foutant de côté suffisamment pour pouvoir encaisser le cas où votre SCA sera défaillante et que les banques vous demanderont de passer à la caisse en assurance pour rembourser les pertes suite à des contestations.
Ou alors vous changez la loi pour virer ça de la DSP2, mais cette législation est aussi là pour de vraies bonnes raisons pour le coup et ça ne se fera de toute façon pas en claquant des doigts.
Peut tu pointer l'article de loi et / ou réglementation ? Car de ce que j'ai vu répété ici ou là c'est l'authentification forte qui est réclamée.
C’est le même article 97. Le 97(3) pour être exact.
Eu égard au paragraphe 1, les États membres veillent à ce que les prestataires de services de paiement aient mis en place des mesures de sécurité adéquates afin de protéger la confidentialité et l’intégrité des données de sécurité personnalisées des utilisateurs de services de paiement.
C’est exactement ce § qui fait ne s’agit pas « seulement » d’une 2FA, mais d’une SCA. C’est pas uniquement du 2 facteurs, ça va bien au delà. La SCA est et nécessite une 2FA (article 97(2) « les prestataires de services de paiement appliquent l’authentification forte du client »), mais toute 2FA n’est pas une SCA puisqu’il manque le contrôle d’intégrité (97(3) « protéger la confidentialité et l’intégrité des données de sécurité »).
Toute solution sans double facteur ne peut être une SCA au sens DSP2.
Une solution seulement double facteur n’est pas une SCA DSP2. Il te manque encore justement toute la partie contrôle d’intégrité et résistance à la compromission. Ce qui fait que les SMS ne sont pas de la SCA par exemple, mais sont bien de la 2FA.
. These could include code-obfuscation, encryption, Whitebox Cryptography with an appropriate key management, device binding, and root detection (mobile devices).
La même différence entre 2FA et SCA est explicitée dans ce même document
A standard software implementation without further protection will not provide a sufficient level of trust and security. I
IDENTIFIED RISK 6: USE OF A ROOTED SMARTPHONE
Rooting is the process of allowing users of smartphones to attain privileged control (known as root access) over various Android subsystems. Rooting is often performed with the goal of overcoming limitations that carriers and hardware manufacturers put on some devices. This might in some cases lead to security breaches. For Android smartphone, safetynet can be used, or any other root detection solution to mitigate the risk
Les banques ne devraient servir que les gens "normaux" ?
Non, mais comme toute entreprise commerciale, elles n’ont strictement aucune obligation de te proposer un service pour ton cas particulier et chaque banque réfléchit à l’effort à fournir pour supporter le pouillième qui leur manque.
Sachant en plus qu’ici, c’est aussi les frais bancaires de tous les autres qui possiblement monteront pour couvrir ce faible % supplémentaire.
Et j’ajouterais que même dans le libre, on enverra assez souvent paître les gens qui ont un environnement ésotérique parce que l’effort à faire pour couvrir ça dépasse très largement la capacité du projet (typiquement j’en suis à plusieurs années d’attente juste pour voir supporter ma config dual keyboard BÉPO/QWERTY par Wayland ou ma config BÉPO gaming pour Lutris).
Ici en plus les banques n’ont juste pas le choix. C’est la législation qui leur impose des critères drastiques à respecter, et donc si tu ne colles pas à ces législations, c’est tant pis pour toi.
La DSP2 interdit les OS rootés ou alternatifs ou sans possibilité de certification de l’environnement d’exécution. Les banques ne vont donc très certainement pas dépenser des sommes importantes pour couvrir une population qui de toute façon ne permet aucun solution légale en l’état de la législation.
Encore une fois c’est comme avec les root CA : on sait que c’est foireux et qu’il existe des attaques, mais c’est bien suffisant pour assurer la sécurité globale, et au pire il y a des assurances pour prendre en charge (ou pas) les 0.00001% de cas où ça va déraper.
La question n’est pas du tout la robustesse théorique parfaite ou non, mais le coût vs le surcoût pour une banque de vouloir/pouvoir gérer ce 0.00001%.
Pourquoi s’emmerder avec la compatibilité de 0.0001% des utilisateurs quand ça te demanderait des surinvestissements massifs voire que ça te mettrait possiblement en défaut de conformité avec des millions d’euro de risque de contestation que tu devrais assumer ?
Quel intérêt pour une banque d’investir ne serait-ce que 1000€ pour contenter deux pelés d’autant plus quand investir ces 1000€ t’exposerait à des centaines de milliers d’euro de risque de contestation ?
(Et ça bizarrement à chaque fois, tous les « pro libres » les oublient totalement à chaque fois)
Les banques n'existent que pour sécuriser l'argent de leurs clients.
Ah non du tout, elles n’existent que pour sécuriser leur propre argent :D
La Cassation et cie ont au contraire dit que les banques n’ont pas à protéger les clients de la fraude : si quelqu’un fait de la merde en dépensant son argent pour des trucs débiles, c’est son problème 🤣
Ici c’est surtout qu’en cas de contestation possible de ta 2FA, c’est l’argent de la banque qu’elle est en train de jouer. Elle devrait te rembourser et sans discussion aucune tout paiement que tu contesterais, puisque la législation le lui impose.
C’est même le besoin primaire de cette 2FA : réduire la fraude monstrueuse qui existait avant et de plus en plus avec les paiements en ligne, qui coûtait un fric de dingue aux banques en contestation, et donc par voie de conséquence voyaient les banques obligées d’augmenter tes frais bancaires.
Au taff on perd des sommes dingues comme ça, où on doit rembourser les payeurs parce que la législation l’impose, mais sans avoir aucune possibilité d’aller récupérer l’argent ensuite, parce que oui forcément, les fraudeurs se sont cassés depuis longtemps et sans laisser d’adresse.
Et tu remarqueras que malgré tout y'en a qui arrivent a court-circuiter play integrity.
Le « 100% secure » n’est pas ce qui intéresse les banques, mais le « 100% assuré ». C’était comme avec x509 et les root CA, l’éco-système s’en contrefoutait d’avoir des trous béants un peu partout, tout le monde payait (cher) pour s’assurer. Et ça convenait à tout le monde.
ça coûterai que dalle aux banques de faire une appli opensource qui peut fonctionner sur tout les téléphone donnant les information nécessaire au paiement avec un lien à ouvrir vers une app, qui pourrait aussi être affiché via un qr-code sur ton écran de PC.
Ça coûterait extrêmement cher aux banques. Comme dit avec une appli opensource, la banque ne pourrait plus (plus ou moins) prouver que le montant, destinataire et action t’ont bien été affiché.
Ça implique donc… la révocabilité de la SCA, et donc… que les banques devraient te rembourser TOUS les paiements que tu ferais si tu les contestais.
Tu pourrais même pousser le vice pour demander que le qr-code soit affiché sur le site de la banque avec une adresse visible et intelligible, pas comme le sous domaine de la banque postale qui fait fuir.
Le problème n’est pas ce qr-code. Ça a même été mis en place par certaines banques à une époque. Le problème est le code qui va lire et afficher ce qr-code.
C’est nécessairement l’application de ta banque, qui doit nécessairement se défendre contre modification possible de son code, et c’est ce morceau qui interdit actuellement root et non Google sur ton téléphone.
Quand on pense qu'il y a même certains prestataires des paiement qui sont derrière Cloudflare (et donc que le numéro de CB qu'ils "collecte en SSL super-sécurisé" se balade en fait en clair sur le réseau du proxy…)
Cloudflare est PCI-DSS, donc c’est pas du tout un problème réglementaire ici, ils peuvent manipuler les données de carte en clair légalement.
D'ailleurs si l'on en revient aux fondamentaux, et même en considérant la philosophie biaisée de la DSP2 à propos de la 2FA pour les paiements en ligne, alors il y a une solution simple:
- La CB est l'objet
- L'usager associe une passphrase à sa CB auprès de sa banque.
- la banque valide valide la passphrase lors de la MFA => deux facteurs. Objet et mémoire de l'usager.
Comme expliqué déjà, les gens résument les OTP DSP2 à une 2FA standard. Ce n’est pas le cas et c’est une SCA (strong customer authentication).
Le besoin primaire de cet OTP n’est pas tant de s’assurer de l’identité du payeur mais de garantir à la banque que le payeur était bien conscient de l’action, du montant et du destinataire pour rendre incontestable et donc irrévocable la validation.
Une fois que tu as validé un OTP, tu ne peux plus contester que toi personnellement tu as bien approuvé quelque chose (cas de la 2FA classique), mais aussi et surtout le montant et le destinataire.
La SCA DSP2 est une 2FA au sens conventionnel du terme (double facteur), mais toute 2FA n’est pas une SCA.
Alors tu vas rire… mais les modalités DSP2 interdisent toute fonctionnalité d’accessibilité sur le téléphone 😅 Ben oui, la plupart du temps c’est « intrusif » sur les applications et à même justement de casser la garantie de non révocabilité de l’OTP… 😅 Au même titre que le root & cie.
Tu peux faire une extension qui s'assure que tous les paramètres sont bon.
Très très très difficile à faire en réalité. Les API pour détecter les certificats TLS ont même été révoqués des manifests Mozilla (ce qui a cassé l’extension DANE-TLSA par exemple : https://www.dnssec-validator.cz/)
Et même à ce que tu t’assures de DNS et de HTTPS, tu n’as pas de moyen de t’assurer que le contenu récupéré est le bon.
Mais bon ton appli elle peut fonctionner sur un téléphone rooté, ses certificats ont put être modifié dans l'appli, toutes les failles du téléphone n'ont pas forcément été corrigées
Justement, les banques cherchent à détecter les téléphones rootés pour empêcher l’usage de l’application dans un tel cas.
Ah oui et elle peut avoir été remplacée par une en tout point identique.
Pas « en tout point identique » sinon ça n’aurait aucun intérêt.
Et c’est justement le but de Play Integrity de garantir que le code est légitime, avec une certification via l’OS (oui, l’application ne peut pas elle-même faire cette vérification, ça n’aurait aucun sens « coucou, est-ce que tu es légitime ? » « oui » « ok, super » 🤣)
C’est pour ça qu’il y a un protocole de validation mis en place par Google et Apple qui assurent à la banque (encore une fois, ta sécu à toi n’est PAS le problème) que ton application est légitime, que ton OTP affichera bien le montant et le destinataire, et donc que ta validation 3DS est bien irrévocable et qu’elle peut en déclencher le paiement.
Si elle n’a pas la garantie de cette irrévocabilité, alors elle est en train de parier avec sa thune sur la légitimité de la transaction et qu’elle n’aura pas à te rembourser avec sa thune si tu la contestes ultérieurement.
Je pense qu'on ne pourra jamais être d'accord sur un point : tu considères que Google et Apple (et les constructeurs de mobile) sont des acteurs neutres de confiance alors que ce sont des violeurs massifs de privacités totalement sous contrôle d'une puissance étrangère hostile.
Je ne vois pas où j’ai dis ça. J’ai dit que les banques réclament actuellement des tiers de confiance, et elles ont choisi Google et Apple. Personne dans l’éco-système libre n’a été capable de proposer une alternative de toute façon.
Je répète encore : on est exactement dans la situation des root CA pré-Let's Encrypt. Un monde débile de root CA dont on a plus ou moins aucune confiance réelle (gouvernement français, chinois, russe, entités comme Google ou Apple, etc), mais qu’on a tout un éco-système qui ne permet PAS de s’en passer et la totalité du monde x509 dont HTTPS qui imposait de payer des milliers d’euro à ces CA pour avoir un bout de pseudo-certificat sans aucune assurance réelle derrière.
Il aura fallu attendre Let's Encrypt pour avoir une CA alternative « communautaire », et aucun des problèmes racines de x509 n’ont été résolu avec Let's Encrypt (au contraire, maintenant on a EN PLUS un énorme SPOF).
On en est exactement là avec le mobile et les banques. Les banques ont des obligations réglementaires, et les seuls aujourd’hui à savoir leur garantir une intégrité du logiciel, c’est actuellement Apple et Google.
Ça peut être tout ce que tu veux défaillant et unsafe, tout comme les root CA l’ont toujours été depuis le départ, c’est totalement inopérant pour justifier de remplacer un éco-système déjà existant.
Et pour le coup je suis assez contre aussi :D
Je vois bien le problème que ça pose avec les OS libres et tout, mais je vois aussi au quotidien ce que ça a permis de faire. Et c’est quand même pas mal pour une fois de protéger les plus vulnérables 😅
On pourrait certainement arriver à faire un truc libre et tout, mais on a un vrai problème de tiers de confiance à mettre en œuvre, tout comme on a galéré pendant 40 ans avant l’apparition de Let’s Encrypt dans le monde x509.
Sauf qu’il faudra que le monde du libre se bouge aussi les fesses, et n’attendent pas que ça tombe tout cru. Let’s Encrypt a du respecter les exigences du CA/B Forum, et a du passer toute la batterie de test de sécurité et de résilience qui s’impose pour devenir root CA.
Forcément que si tout le monde avait continuer à dire « bouh le CA/B il est méchant parce que je peux pas faire ma root CA à la maison reconnue par les navigateurs », ben on n’aurait toujours pas une root CA alternative 🤣
À un moment, il a fallut acheter des HSM matériel qui coûtent un rein pour les enfermer dans des bunkers qui en coûtent deux, et que non si tu voulais arriver dans un navigateur, tu pouvais pas faire ça chez toi dans ton garage.
Ça sera pareil dans le monde bancaire. Si la critique se limite à « oui mais c’est nul » sans commencer à monter les infras sécurisées (coûteuses, chiantes et pénibles à mettre en œuvre) pour avoir le droit de faire du bancaire, ben on va continuer à se prendre des murs de merde sur la gueule. On peut pas toujours attendre que ça soit l’autre qui fasse tout pour te faciliter la vie, surtout sur ce type de sujet.
Pour le coup GrapheneOS a commencé à bosser là-dessus.
Alors pour le coup, c’est totalement le contraire. Je ne sais pas d’où tu sors qu’un navigateur est bien plus sécurisé qu’une application mobile.
Parce que typiquement sur les apps mobiles, les banques peuvent contrôler absolument toute la chaîne : les IP des backend de connexion (DNS menteur impossible), les certificats TLS qui sont pin dans l’app mobile (mitm impossible), le logiciel exact qui s’exécute, etc.
Tout plein de truc qu’il est impossible de s’assurer avec un navigateur desktop.
Et typiquement actuellement il y a une vague de compromission de CMS utilisés pour payer en ligne qui font que tu vas avoir l’impression de saisir ton n° de CB sur un truc fiable… mais qu’en fait c’est un deface pirate qui va te piquer ton numéro de CB. Et c’est littéralement indétectable pour le pékin lambda. C’est impossible que ça arrive sur une appli mobile bancaire.
Donc comme pas mal de trucs en ce moment, le « oui mais c’est plus sécurisé chez moi », ben en fait… non. Y’a des cas précis et spécifiques où c’est juste absolument faux.
Oui elles ont tord mais c’est un état connu des établissements bancaires.
Certaines/beaucoup assument de ne pas respecter la législation, en sachant ne pas craindre beaucoup de sanctions derrière (pour le moment, la DSP3 arrivant).
Le régulateur est parfaitement informé aussi, et par exemple les banques étaient enjointes à ne plus utiliser les SMS en… avril 2018. https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2018_4039
C’est comme le RGPD et les cookies : la législation dit un truc parfaitement clair, mais vu que le régulateur s’en fout complètement et ne fout pas d’amende, ben tout le monde continue.
, both the amount and the payee must be clear to the payer when they authenticate a purchase. This typically means the cardholder is presented with the payee name and purchase amount.
The regulation requires that the authentication code accepted by the PSP corresponds to the original amount and payee agreed to by the payer at authentication
Ton OTP doit donc OBLIGATOIREMENT être calculé avec le montant et le destinataire, et ça doit t’être affiché. Ça dégage obligatoirement toutes les solutions offline type TOPT ou FIDO.
Non ce n’est pas une sur-interprétation de ma part, c’est dans le texte à l’article 97 de la DSP2. (Spoiler : c’est mon boulot à plein temps, je bosse chez un prestataire de service de paiement et je me fracasse à ça tous les jours.)
Non justement, puisque si c’est un margoulin qui a fait une fake application, il n’est pas en capacité de te faire recevoir des OTP par ta banque.
Il est assez peu probable qu’un drop-shipper sur un site random sur le net ait prévu 4 ans d’infiltration pour te faire installer une application de longue date sur ton téléphone que tu te sers tous les jours pour consulter tes comptes.
Tu ne pourrais même pas utiliser l’application fake au quotidien : il te faudrait valider l’authentification… avec la vraie 🤣
En tout cas ça demande un niveau de modèle de menace bien plus élevé que ce qui est visé par la DSP2.
Un PC sous Debian Stable est 42 fois plus sécurisé et l'avis du RSSI en carton de La Poste Bancale ou BoursoLALALA on s'en cogne.
La question n’a jamais été TA sécurité, mais celle de l’assurance par la banque que tu utilises son application et pas une autre. ELLE doit garantir que l’application que tu run est la bonne, que tu as bien reçu l’information du prix/destinataire/action, pour pouvoir te l’opposer en justice.
Ça n’a jamais eu pour vocation de TE protéger hein, mais de protéger les obligations juridiques de la banque en face.
Tu vas sur le site de la banque, tu te connectes, ça affiche une transaction en attente de validation, et tu cliques pour valider. C'est assez bon ça ?
Non, parce que la banque… n’a aucune garanti que c’est bien le site de ta banque que t’es en train de consulter 😅
C’est exactement pour ça qu’elles ont fait le move vers les applis android et les vérifs de « sécurité » (no-root, AOSP, Play Integrity…), et où elles font du DNS et du certificate pinning, pour s’assurer que tu ne peux pas l’utiliser dans un environnement vérolé.
Tente un mitm-proxy sur ton Android, ton application bancaire ne démarrera plus, le certificat en face ne sera pas celui attendu.
Avec deux facteurs : mot de passe et TOTP. Sans contexte, il n'y a pas de notion de contexte pour une simple connexion à l'espace de gestion de compte.
Si justement : le contexte c’est montant et destinataire ET ACTION.
L’action c’est authentification, ajout bénéficiaire, paiement en ligne, virement…
Il y a donc bien un contexte, même pour l’authentification.
dans la mesure où la connexion en question a pour seul but de valider une transaction en fournissant justement un TOTP
Justement, c’est pas le seul but. Le but de la SCA (Strong Customer Authentication, et non simplement 2FA) DSP2, c’est de garantir l’irrévocabilité du paiement/login/whatever en assurant à la banque que la personne qui valide est bien complètement consciente de ce qu’elle fait, et que ça en sera opposable en justice.
À partir du moment où tu utilises ton OTP, ça a des effets juridiques tout à fait autre que de simplement avoir valider ton paiement. Ça certifie que tu es conscient et du montant et du destinataire et de l’action et que ça en sera irrévocable et incontestable devant la banque et les tribunaux. Tu ne peux juridiquement plus dire « je ne savais pas/je me suis fait avoir/on m’a trompé ».
le gamin qui demande un OTP à un de ses parents pour un jeu, qui le lui file sans se rendre compte que c’est un paiement de 100€ et pas un de 10€ comme convenu
le gamin qui demande un OTP à un de ses parent pour un jeu, qui le lui file sans se rendre compte que c’est pas pour acheter un jeu mais pour s’authentifier à l’interface de gestion de compte
la page de phishing qui annonce un paiement à 10€ mais qu’en fait le paiement validé par l’OTP est un de 1000€
la page de phishing qui annonce un paiement à 10€ mais qu’en fait ils sont en train de s’ajouter comme bénéficiaire à ton compte
Dans les 2 cas : la banque doit avoir la certitude que la personne qui a communiqué l’OTP est bien consciente et du montant et du destinataire et de l’action (authentification, ajout du bénéficiaire, paiement, virement…), en particulier parce que le 3DS est irrévocable (donc y’a intérêt à pas avoir de litige sur le sujet ensuite)
Non puisque les données doivent être à côté du code.
L’idée est que celui qui va obtenir le code est nécessairement au courant de la finalité visée par la saisie.
Dans ton cas, la personne qui a lu le code peut possiblement le transmettre à un tiers pour la saisie sur la page web : elle n’a donc pas conscience du paiement en jeu.
C’est bien le code lui-même qui doit être intimement lié, et pas sa saisie.
La banque garantie ainsi que celui qui a pris connaissance du code avait aussi nécessairement connaissance de la véritable opération.
Ça évite aussi le MITM/phishing, avec une page web qui ment sur la finalité et t’affiche 10€ quand tu es en réalité en train d’en valider un paiement de 1000€.
Pour ça que tu dois avoir les 1000€ d’affichés sur un support totalement séparé de la fenêtre de paiement.
Ça avait déjà été débattu ici-même.
Les clefs FIDO, TOTP et autres ne sont pas légaux selon les exigences de la DSP2 qui imposent une authentification contextuelle (article 97).
En ce qui concerne l’initiation des opérations de paiement électronique visée au paragraphe 1, point b), les États membres veillent à ce que, pour les opérations de paiement électronique à distance, les prestataires de services de paiement appliquent l’authentification forte du client comprenant des éléments qui établissent un lien dynamique entre l’opération, le montant et le bénéficiaire donnés.
Ben dans ce cas du logiciel propriétaire quoi…
Tu ne peux décemment pas imposer aux banques de faire du libre (ce qui est en plus totalement et légalement impossible dans le cas bancaire justement, puisque t’aurais a minima pas le droit d’exécuter une version modifiée).
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 1 (+0/-0). Dernière modification le 03 mai 2026 à 21:59.
C’est exactement ça. C’est pas en pleurant « ouin les banques y sont michantes, moi je veux du root sur mon téléphone et puis voilà » que ça va changer. La réponse sera « non » et pour de très très bonne raison. Parce que quelqu’un qui me dit « je veux de la sécurité » et en même temps utilise un OS rooté ou un bootloader non verrouillé n’est lui-même pas très cohérent.
Vous voulez des applis bancaires qui tournent sur vos OS ?
Vous faites comme Let's Encrypt à l’époque de son démarrage, vous montez une infra sécurisée avec des HSM dans un bunker, vous passez quelques millions d’euro en certification et vous montrez patte blanche auprès des organismes bancaires, avec une cross-certification pour commencer par Google/Apple pour pouvoir commencer à bootstraper avant d’avoir votre truc certifié en autonome.
Et en fournissant aussi des SDK côté mobile pour gérer ces trucs suffisamment facilement pour que les devs côté banque n’aient pas trop de taff à faire pour sortir de Play Integrity ou autre.
Et en foutant de côté suffisamment pour pouvoir encaisser le cas où votre SCA sera défaillante et que les banques vous demanderont de passer à la caisse en assurance pour rembourser les pertes suite à des contestations.
Ou alors vous changez la loi pour virer ça de la DSP2, mais cette législation est aussi là pour de vraies bonnes raisons pour le coup et ça ne se fera de toute façon pas en claquant des doigts.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 1 (+0/-0). Dernière modification le 03 mai 2026 à 21:51.
C’est le même article 97. Le 97(3) pour être exact.
C’est exactement ce § qui fait ne s’agit pas « seulement » d’une 2FA, mais d’une SCA. C’est pas uniquement du 2 facteurs, ça va bien au delà. La SCA est et nécessite une 2FA (article 97(2) « les prestataires de services de paiement appliquent l’authentification forte du client »), mais toute 2FA n’est pas une SCA puisqu’il manque le contrôle d’intégrité (97(3) « protéger la confidentialité et l’intégrité des données de sécurité »).
Toute solution sans double facteur ne peut être une SCA au sens DSP2.
Une solution seulement double facteur n’est pas une SCA DSP2. Il te manque encore justement toute la partie contrôle d’intégrité et résistance à la compromission. Ce qui fait que les SMS ne sont pas de la SCA par exemple, mais sont bien de la 2FA.
Après il faut aller voir les RTS et cie de l’ABE, par exemple https://www.eba.europa.eu/eba-response/306
La même différence entre 2FA et SCA est explicitée dans ce même document
Ou encore https://ec.europa.eu/newsroom/repository/document/2023-22/eu_reportonexistingremoteonboardingsolutionsinthebankingsectordecember2019_en_1_oZR71XL7ECUe3Gw9VgwldMoWpyM_96148.pdf
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 1 (+0/-0).
Non, mais comme toute entreprise commerciale, elles n’ont strictement aucune obligation de te proposer un service pour ton cas particulier et chaque banque réfléchit à l’effort à fournir pour supporter le pouillième qui leur manque.
Sachant en plus qu’ici, c’est aussi les frais bancaires de tous les autres qui possiblement monteront pour couvrir ce faible % supplémentaire.
Et j’ajouterais que même dans le libre, on enverra assez souvent paître les gens qui ont un environnement ésotérique parce que l’effort à faire pour couvrir ça dépasse très largement la capacité du projet (typiquement j’en suis à plusieurs années d’attente juste pour voir supporter ma config dual keyboard BÉPO/QWERTY par Wayland ou ma config BÉPO gaming pour Lutris).
Ici en plus les banques n’ont juste pas le choix. C’est la législation qui leur impose des critères drastiques à respecter, et donc si tu ne colles pas à ces législations, c’est tant pis pour toi.
La DSP2 interdit les OS rootés ou alternatifs ou sans possibilité de certification de l’environnement d’exécution. Les banques ne vont donc très certainement pas dépenser des sommes importantes pour couvrir une population qui de toute façon ne permet aucun solution légale en l’état de la législation.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 0 (+0/-1).
Et ça les banques en ont : rien à foutre
Encore une fois c’est comme avec les root CA : on sait que c’est foireux et qu’il existe des attaques, mais c’est bien suffisant pour assurer la sécurité globale, et au pire il y a des assurances pour prendre en charge (ou pas) les 0.00001% de cas où ça va déraper.
La question n’est pas du tout la robustesse théorique parfaite ou non, mais le coût vs le surcoût pour une banque de vouloir/pouvoir gérer ce 0.00001%.
Pourquoi s’emmerder avec la compatibilité de 0.0001% des utilisateurs quand ça te demanderait des surinvestissements massifs voire que ça te mettrait possiblement en défaut de conformité avec des millions d’euro de risque de contestation que tu devrais assumer ?
Quel intérêt pour une banque d’investir ne serait-ce que 1000€ pour contenter deux pelés d’autant plus quand investir ces 1000€ t’exposerait à des centaines de milliers d’euro de risque de contestation ?
(Et ça bizarrement à chaque fois, tous les « pro libres » les oublient totalement à chaque fois)
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 0 (+0/-1).
Ah non du tout, elles n’existent que pour sécuriser leur propre argent :D
La Cassation et cie ont au contraire dit que les banques n’ont pas à protéger les clients de la fraude : si quelqu’un fait de la merde en dépensant son argent pour des trucs débiles, c’est son problème 🤣
Ici c’est surtout qu’en cas de contestation possible de ta 2FA, c’est l’argent de la banque qu’elle est en train de jouer. Elle devrait te rembourser et sans discussion aucune tout paiement que tu contesterais, puisque la législation le lui impose.
C’est même le besoin primaire de cette 2FA : réduire la fraude monstrueuse qui existait avant et de plus en plus avec les paiements en ligne, qui coûtait un fric de dingue aux banques en contestation, et donc par voie de conséquence voyaient les banques obligées d’augmenter tes frais bancaires.
Au taff on perd des sommes dingues comme ça, où on doit rembourser les payeurs parce que la législation l’impose, mais sans avoir aucune possibilité d’aller récupérer l’argent ensuite, parce que oui forcément, les fraudeurs se sont cassés depuis longtemps et sans laisser d’adresse.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 0 (+0/-1).
Le « 100% secure » n’est pas ce qui intéresse les banques, mais le « 100% assuré ». C’était comme avec x509 et les root CA, l’éco-système s’en contrefoutait d’avoir des trous béants un peu partout, tout le monde payait (cher) pour s’assurer. Et ça convenait à tout le monde.
Ça coûterait extrêmement cher aux banques. Comme dit avec une appli opensource, la banque ne pourrait plus (plus ou moins) prouver que le montant, destinataire et action t’ont bien été affiché.
Ça implique donc… la révocabilité de la SCA, et donc… que les banques devraient te rembourser TOUS les paiements que tu ferais si tu les contestais.
Le problème n’est pas ce qr-code. Ça a même été mis en place par certaines banques à une époque. Le problème est le code qui va lire et afficher ce qr-code.
C’est nécessairement l’application de ta banque, qui doit nécessairement se défendre contre modification possible de son code, et c’est ce morceau qui interdit actuellement root et non Google sur ton téléphone.
[^] # Re: bonne initiative
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 0 (+0/-1).
Cloudflare est PCI-DSS, donc c’est pas du tout un problème réglementaire ici, ils peuvent manipuler les données de carte en clair légalement.
https://www.cloudflare.com/trust-hub/compliance-resources/pci-dss/
[^] # Re: bonne initiative
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 0 (+0/-1).
Comme expliqué déjà, les gens résument les OTP DSP2 à une 2FA standard. Ce n’est pas le cas et c’est une SCA (strong customer authentication).
Le besoin primaire de cet OTP n’est pas tant de s’assurer de l’identité du payeur mais de garantir à la banque que le payeur était bien conscient de l’action, du montant et du destinataire pour rendre incontestable et donc irrévocable la validation.
Une fois que tu as validé un OTP, tu ne peux plus contester que toi personnellement tu as bien approuvé quelque chose (cas de la 2FA classique), mais aussi et surtout le montant et le destinataire.
La SCA DSP2 est une 2FA au sens conventionnel du terme (double facteur), mais toute 2FA n’est pas une SCA.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 1 (+1/-1).
Alors tu vas rire… mais les modalités DSP2 interdisent toute fonctionnalité d’accessibilité sur le téléphone 😅 Ben oui, la plupart du temps c’est « intrusif » sur les applications et à même justement de casser la garantie de non révocabilité de l’OTP… 😅 Au même titre que le root & cie.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 0 (+1/-2).
Très très très difficile à faire en réalité. Les API pour détecter les certificats TLS ont même été révoqués des manifests Mozilla (ce qui a cassé l’extension DANE-TLSA par exemple : https://www.dnssec-validator.cz/)
Et même à ce que tu t’assures de DNS et de HTTPS, tu n’as pas de moyen de t’assurer que le contenu récupéré est le bon.
Justement, les banques cherchent à détecter les téléphones rootés pour empêcher l’usage de l’application dans un tel cas.
Pas « en tout point identique » sinon ça n’aurait aucun intérêt.
Et c’est justement le but de Play Integrity de garantir que le code est légitime, avec une certification via l’OS (oui, l’application ne peut pas elle-même faire cette vérification, ça n’aurait aucun sens « coucou, est-ce que tu es légitime ? » « oui » « ok, super » 🤣)
C’est pour ça qu’il y a un protocole de validation mis en place par Google et Apple qui assurent à la banque (encore une fois, ta sécu à toi n’est PAS le problème) que ton application est légitime, que ton OTP affichera bien le montant et le destinataire, et donc que ta validation 3DS est bien irrévocable et qu’elle peut en déclencher le paiement.
Si elle n’a pas la garantie de cette irrévocabilité, alors elle est en train de parier avec sa thune sur la légitimité de la transaction et qu’elle n’aura pas à te rembourser avec sa thune si tu la contestes ultérieurement.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 1 (+1/-1). Dernière modification le 02 mai 2026 à 19:37.
Je ne vois pas où j’ai dis ça. J’ai dit que les banques réclament actuellement des tiers de confiance, et elles ont choisi Google et Apple. Personne dans l’éco-système libre n’a été capable de proposer une alternative de toute façon.
Je répète encore : on est exactement dans la situation des root CA pré-Let's Encrypt. Un monde débile de root CA dont on a plus ou moins aucune confiance réelle (gouvernement français, chinois, russe, entités comme Google ou Apple, etc), mais qu’on a tout un éco-système qui ne permet PAS de s’en passer et la totalité du monde x509 dont HTTPS qui imposait de payer des milliers d’euro à ces CA pour avoir un bout de pseudo-certificat sans aucune assurance réelle derrière.
Il aura fallu attendre Let's Encrypt pour avoir une CA alternative « communautaire », et aucun des problèmes racines de x509 n’ont été résolu avec Let's Encrypt (au contraire, maintenant on a EN PLUS un énorme SPOF).
On en est exactement là avec le mobile et les banques. Les banques ont des obligations réglementaires, et les seuls aujourd’hui à savoir leur garantir une intégrité du logiciel, c’est actuellement Apple et Google.
Ça peut être tout ce que tu veux défaillant et unsafe, tout comme les root CA l’ont toujours été depuis le départ, c’est totalement inopérant pour justifier de remplacer un éco-système déjà existant.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 2 (+3/-2). Dernière modification le 30 avril 2026 à 23:49.
Et pour le coup je suis assez contre aussi :D
Je vois bien le problème que ça pose avec les OS libres et tout, mais je vois aussi au quotidien ce que ça a permis de faire. Et c’est quand même pas mal pour une fois de protéger les plus vulnérables 😅
On pourrait certainement arriver à faire un truc libre et tout, mais on a un vrai problème de tiers de confiance à mettre en œuvre, tout comme on a galéré pendant 40 ans avant l’apparition de Let’s Encrypt dans le monde x509.
Sauf qu’il faudra que le monde du libre se bouge aussi les fesses, et n’attendent pas que ça tombe tout cru. Let’s Encrypt a du respecter les exigences du CA/B Forum, et a du passer toute la batterie de test de sécurité et de résilience qui s’impose pour devenir root CA.
Forcément que si tout le monde avait continuer à dire « bouh le CA/B il est méchant parce que je peux pas faire ma root CA à la maison reconnue par les navigateurs », ben on n’aurait toujours pas une root CA alternative 🤣
À un moment, il a fallut acheter des HSM matériel qui coûtent un rein pour les enfermer dans des bunkers qui en coûtent deux, et que non si tu voulais arriver dans un navigateur, tu pouvais pas faire ça chez toi dans ton garage.
Ça sera pareil dans le monde bancaire. Si la critique se limite à « oui mais c’est nul » sans commencer à monter les infras sécurisées (coûteuses, chiantes et pénibles à mettre en œuvre) pour avoir le droit de faire du bancaire, ben on va continuer à se prendre des murs de merde sur la gueule. On peut pas toujours attendre que ça soit l’autre qui fasse tout pour te faciliter la vie, surtout sur ce type de sujet.
Pour le coup GrapheneOS a commencé à bosser là-dessus.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 0 (+2/-3).
Alors pour le coup, c’est totalement le contraire. Je ne sais pas d’où tu sors qu’un navigateur est bien plus sécurisé qu’une application mobile.
Parce que typiquement sur les apps mobiles, les banques peuvent contrôler absolument toute la chaîne : les IP des backend de connexion (DNS menteur impossible), les certificats TLS qui sont pin dans l’app mobile (mitm impossible), le logiciel exact qui s’exécute, etc.
Tout plein de truc qu’il est impossible de s’assurer avec un navigateur desktop.
Et typiquement actuellement il y a une vague de compromission de CMS utilisés pour payer en ligne qui font que tu vas avoir l’impression de saisir ton n° de CB sur un truc fiable… mais qu’en fait c’est un deface pirate qui va te piquer ton numéro de CB. Et c’est littéralement indétectable pour le pékin lambda. C’est impossible que ça arrive sur une appli mobile bancaire.
Donc comme pas mal de trucs en ce moment, le « oui mais c’est plus sécurisé chez moi », ben en fait… non. Y’a des cas précis et spécifiques où c’est juste absolument faux.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 0 (+0/-1).
Oui elles ont tord mais c’est un état connu des établissements bancaires.
Certaines/beaucoup assument de ne pas respecter la législation, en sachant ne pas craindre beaucoup de sanctions derrière (pour le moment, la DSP3 arrivant).
Le régulateur est parfaitement informé aussi, et par exemple les banques étaient enjointes à ne plus utiliser les SMS en… avril 2018.
https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2018_4039
C’est comme le RGPD et les cookies : la législation dit un truc parfaitement clair, mais vu que le régulateur s’en fout complètement et ne fout pas d’amende, ben tout le monde continue.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 2 (+4/-3). Dernière modification le 30 avril 2026 à 16:29.
La norme EMV sur le sujet, page 25
https://www.visa.fr/content/dam/VCOM/regional/ve/france/PDF/SCA/fr-visa-psd2-sca-implementation-guide-v4-0-28-02-23.pdf
Ton OTP doit donc OBLIGATOIREMENT être calculé avec le montant et le destinataire, et ça doit t’être affiché. Ça dégage obligatoirement toutes les solutions offline type TOPT ou FIDO.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 1 (+3/-3). Dernière modification le 30 avril 2026 à 16:19.
Non ce n’est pas une sur-interprétation de ma part, c’est dans le texte à l’article 97 de la DSP2. (Spoiler : c’est mon boulot à plein temps, je bosse chez un prestataire de service de paiement et je me fracasse à ça tous les jours.)
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à -1 (+1/-3). Dernière modification le 30 avril 2026 à 16:18.
Non justement, puisque si c’est un margoulin qui a fait une fake application, il n’est pas en capacité de te faire recevoir des OTP par ta banque.
Il est assez peu probable qu’un drop-shipper sur un site random sur le net ait prévu 4 ans d’infiltration pour te faire installer une application de longue date sur ton téléphone que tu te sers tous les jours pour consulter tes comptes.
Tu ne pourrais même pas utiliser l’application fake au quotidien : il te faudrait valider l’authentification… avec la vraie 🤣
En tout cas ça demande un niveau de modèle de menace bien plus élevé que ce qui est visé par la DSP2.
La question n’a jamais été TA sécurité, mais celle de l’assurance par la banque que tu utilises son application et pas une autre.
ELLE doit garantir que l’application que tu run est la bonne, que tu as bien reçu l’information du prix/destinataire/action, pour pouvoir te l’opposer en justice.
Ça n’a jamais eu pour vocation de TE protéger hein, mais de protéger les obligations juridiques de la banque en face.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 0 (+1/-2). Dernière modification le 29 avril 2026 à 23:16.
Non, parce que la banque… n’a aucune garanti que c’est bien le site de ta banque que t’es en train de consulter 😅
C’est exactement pour ça qu’elles ont fait le move vers les applis android et les vérifs de « sécurité » (no-root, AOSP, Play Integrity…), et où elles font du DNS et du certificate pinning, pour s’assurer que tu ne peux pas l’utiliser dans un environnement vérolé.
Tente un mitm-proxy sur ton Android, ton application bancaire ne démarrera plus, le certificat en face ne sera pas celui attendu.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 1 (+1/-1).
Si justement : le contexte c’est montant et destinataire ET ACTION.
L’action c’est authentification, ajout bénéficiaire, paiement en ligne, virement…
Il y a donc bien un contexte, même pour l’authentification.
Justement, c’est pas le seul but. Le but de la SCA (Strong Customer Authentication, et non simplement 2FA) DSP2, c’est de garantir l’irrévocabilité du paiement/login/whatever en assurant à la banque que la personne qui valide est bien complètement consciente de ce qu’elle fait, et que ça en sera opposable en justice.
À partir du moment où tu utilises ton OTP, ça a des effets juridiques tout à fait autre que de simplement avoir valider ton paiement. Ça certifie que tu es conscient et du montant et du destinataire et de l’action et que ça en sera irrévocable et incontestable devant la banque et les tribunaux. Tu ne peux juridiquement plus dire « je ne savais pas/je me suis fait avoir/on m’a trompé ».
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 0 (+1/-2).
Ça bloque 2 scénarios d’attaque :
Dans les 2 cas : la banque doit avoir la certitude que la personne qui a communiqué l’OTP est bien consciente et du montant et du destinataire et de l’action (authentification, ajout du bénéficiaire, paiement, virement…), en particulier parce que le 3DS est irrévocable (donc y’a intérêt à pas avoir de litige sur le sujet ensuite)
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 2 (+3/-2). Dernière modification le 29 avril 2026 à 14:37.
Non puisque les données doivent être à côté du code.
L’idée est que celui qui va obtenir le code est nécessairement au courant de la finalité visée par la saisie.
Dans ton cas, la personne qui a lu le code peut possiblement le transmettre à un tiers pour la saisie sur la page web : elle n’a donc pas conscience du paiement en jeu.
C’est bien le code lui-même qui doit être intimement lié, et pas sa saisie.
La banque garantie ainsi que celui qui a pris connaissance du code avait aussi nécessairement connaissance de la véritable opération.
Ça évite aussi le MITM/phishing, avec une page web qui ment sur la finalité et t’affiche 10€ quand tu es en réalité en train d’en valider un paiement de 1000€.
Pour ça que tu dois avoir les 1000€ d’affichés sur un support totalement séparé de la fenêtre de paiement.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . En réponse à la dépêche Banques en ligne : l’authentification forte doit-elle imposer Android ou iPhone ?. Évalué à 0 (+1/-2). Dernière modification le 29 avril 2026 à 12:14.
Ça avait déjà été débattu ici-même.
Les clefs FIDO, TOTP et autres ne sont pas légaux selon les exigences de la DSP2 qui imposent une authentification contextuelle (article 97).
https://eur-lex.europa.eu/eli/dir/2015/2366/oj?locale=fr#art_97.tit_1
[^] # Re: Résumé des arguments à utiliser (quelle que soit la banque d'ailleurs) et des solutions possibles
Posté par Aeris (site web personnel) . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à -1 (+2/-4).
Ben dans ce cas du logiciel propriétaire quoi…
Tu ne peux décemment pas imposer aux banques de faire du libre (ce qui est en plus totalement et légalement impossible dans le cas bancaire justement, puisque t’aurais a minima pas le droit d’exécuter une version modifiée).
[^] # Re: Résumé des arguments à utiliser (quelle que soit la banque d'ailleurs) et des solutions possibles
Posté par Aeris (site web personnel) . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à 0 (+0/-1).
Les listes de sanction sont des obligations légales, et n’ouvrent donc pas le droit à poursuite pour discrimination.
[^] # Re: Résumé des arguments à utiliser (quelle que soit la banque d'ailleurs) et des solutions possibles
Posté par Aeris (site web personnel) . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à -1 (+2/-4).
Sauf qu’un tel truc coûte… plus que le prix d’un téléphone.