Aeris a écrit 484 commentaires

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.

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

, 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é ».

Ça bloque 2 scénarios d’attaque :

• 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).

https://eur-lex.europa.eu/eli/dir/2015/2366/oj?locale=fr#art_97.tit_1

1. 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).

Les listes de sanction sont des obligations légales, et n’ouvrent donc pas le droit à poursuite pour discrimination.

Sauf qu’un tel truc coûte… plus que le prix d’un téléphone.

Il n’y a aucune obscurité ici. Tout est documenté et parfaitement accessible et reproductible.
Sauf que tu ne verras jamais la clef privée de signature du matériel et de l’OS reconnu par les banques.
C’est un pur problème d’autorité de confiance, et pas de soft.

Mais si, mais si, il suffit d'intégrer ça intelligemment. Genre, sur la page de validation d'une transaction par CB : rendez-vous sur votre espace client pour valider cette transaction.

Se rendre sur ton espace client n’est pas une 2FA mais une 1FA. Et est lui-même soumis à SCA.
Pour se connecter en 2FA à ton espace client il te faudra… valider la SCA sur ton mobile. Retour au point de départ.

En fait, c'est juste pareil qu'avec l'appli bancaire, mais dans un navigateur, et avec du TOTP au lieu de la biométrie ou un code appris par cœur.

Comme dit, TOTP n’est pas contextuel et ne permet donc pas de remplir les obligations légales de la SCA DSP2/3.

Pour autant, il doit bien être possible de faire du contextuel avec des API ouvertes et une implémentation libre, non ?

Non, puisque les banques doivent avoir la certitude d’une application non modifiée et non modifiable. C’est pour ça qu’elles refusent actuellement les téléphones rootés et toute modif à même d’avoir altéré le fonctionnement de la SCA.

Et le passage sur les téléphones leur permet justement un contrôle au niveau matériel.
Et les systèmes alternatifs n’arriveront jamais à se faire reconnaître « de confiance », surtout sans les moyens financiers des assurances qui vont derrière (s’il y a de la fraude à cause de ton système de certif, c’est toi qui paie la fraude, pas les banques)
https://grapheneos.org/articles/attestation-compatibility-guide

Parce que la DSP3 impose dorénavant une connexion Internet pour récupérer ce contextuel

Arguments

il y a d’autres moyens de double authentification (2FA) comme OTP, Yubikey, etc.

Qui ne respectent pas la notion de SCA contextuelle bancaire (action, montant & destinataire)

il n’y a aucune obligation égale à avoir un ordiphone,

Mais la banque a une obligation légale à fournir une SCA légale (DSP3)

dans les CGV de la banque il n’y a nulle part indiqué qu’il faut avoir un ordiphone pour en utiliser les services,

Mais la banque est concernée elle-même par une obligation légale qui est supérieure à ses CGUE

dans les mêmes CGV, il n’est indiqué nulle part qu’il faille un compte auprès d’Apple ou de Google pour utiliser les services en ligne,

Idem

Google exige des versions d’Android mises à jour pour les applis bancaires ce qui va raccourcir de facto la durée d’utilisation des ordiphones pour ces applis, la banque est-elle prête à payer des ordiphones plus récents aux clients ?

Pas le problème de la banque

la banque utilisait déjà d’autres systèmes de double authentification, pourquoi ne plus les utiliser ?

Parce que plus légales. Ne l’était déjà plus depuis longtemps pour la plupart (SMS, calculette, code fixe…). Les exigences DSP3 ont fait sauter tout le reste.

Solutions envisageables :

OTP (mot de passe à usage unique donc valable pour une seule transaction)

Non, pas contextuel

saisie d’un code fixe transmis par papier initialement nécessaire pour les transactions en ligne et qui s’ajoute aux informations de paiement et au code temporaire reçu par SMS, exemple du Securicode du CA,

Pas contextuel ou plus fiable (SMS)

une petite télécommande qui génère un code unique après flashage d’un QR-Code (CIC),

Pas contextuel, illégal

U2F (Universal Second Factor norme d’authentification ouverte qui vise à renforcer et à simplifier l’authentification à deux facteurs en utilisant des périphériques USB ou à communication en champ proche), exemple des clés USB de type Yubikey.

Pas contextuel, illégal

Instances that block mastodon.social

federated_timeline_removal (94)
followers_only (241)
reject (199)
quarantined_instances (5)

https://lunatopia.fr/blog/les-gamins-ne-savent-pas-utiliser-les-ordinateurs