Et c’est une FAQ ou une charte , qui n’engage donc… pas grand monde.
Et c’est marqué « dans la mesure du possible ». Y’a pas de solution légale alternative en l’état. Donc bon 😅
Spoiler : il n’y a que la DSP3 qui impose(ra?) dorénavant a priori un système alternatif, mais qui doit être équivalent en terme de sécurité à la version smartphone
Mais le texte n’est pas encore définitif, pour le moment ce n’est qu’une note d’intérêt
L’analyse d’impact présente un ensemble d’options privilégiées visant à atteindre les objectifs spécifiques (la liste ci-dessous comprend à la fois les mesures contenues dans la présente directive et celles figurant dans le règlement qui l’accompagne):
–en ce qui concerne l’objectif spécifique nº 1: des améliorations dans la mise en œuvre de l’authentification forte du client, l’obligation pour les prestataires de services de paiement d’améliorer l’accessibilité de l’authentification forte du client pour les utilisateurs handicapés, les personnes âgées et les autres personnes rencontrant des difficultés dans l’utilisation de l’authentification forte du client;
J'ajouterai en plus que la rom d'origine étant une xiaomi, remplacée par une android nue, la différence de sécurité est notable, même si elle est loin d'être parfaite, elle est similaire aux PCs que j'utilise tous les jours.
La différence de sécurité est plus que notable oui, mais pas dans le sens que tu penses.
C’est plus que documenté qu’un téléphone rooté avec le bootloader non verrouillé est AUTREMENT plus unsafe que même le xiaomi le plus pourrave rempli de merde en tout genre (qui resteront bien gentiment sandboxées parce que justement sans root).
Ton système pas à jour avec des vulnérabilité connue, exploitable a distance n'est absolument pas sécurisé. Le système à jour, lui, a besoin d'une faille jusque là inconnue pour que quelqu'un puisse rentrer.
Et c’est bien pour ça que les banques imposent généralement une version minimale et à jour de ton OS. Et c’est encore pire pour les SoftPOS bancaires.
Du coup tu préfères Android avec surcouche Xiaomi de Tata Michu avec 628 applis malwares ou Debian Stable sur le PC de Tonton Barbu avec libreboot et que des applis libres ?
Sauf que le choix n’est pas celui-là, et que tu te places encore une fois du côté DE L’UTILISATEUR, sauf que j’ai répété 42.000× que c’est celui DES BANQUES qui compte.
C’est ELLES qui encaissent le risque de contestation et donc d’avoir à te rembourser SUR SA THUNE les paiements frauduleux.
Elle en a rien à carrer de ce que toi tu penses mieux sur ton PC, c’est sa thune qu’elle est en train de jouer là.
C’est donc pas « Android avec surcouche Xiaomi de Tata Michu avec 628 applis malwares » puisque SafetyNet sur un tel téléphone garanti toujours que l’application banque est safe (et encaissera la fauche s’ils ont faussement attesté le truc et que c’est démontré par la banque) vs « Debian Stable sur le PC de Tonton Barbu avec libreboot et que des applis libres » que la banque se contrefiche parce qu’elle n’a aucune garantie (justement parce que c’est libre) que t’as pas bricolé son app bancaire et donc que sa SCA n’est plus conforme et que tu pourrais la contester en cas de fraude.
C’est « Android avec surcouche Xiaomi de Tata Michu avec 628 applis malwares que de toute façon SafetyNet sur un tel téléphone garanti toujours que l’application banque est safe (et encaissera la fauche s’ils ont faussement attesté le truc et que c’est démontré par la banque) et que la banque fait 2-3 vérifs en plus que t’as pas des merdes root ou screen reader actif » vs « un téléphone rooté que la banque sait de base que tu peux bypass SafetyNet et qu’elle ne peut pas avoir confiance en ton machin parce qu’elle ne sait pas ce que tu fais de la SCA et donc que ça sera contestable en cas de fraude ».
Encore une fois, place-toi du côté de la banque QUI A DES OBLIGATIONS LÉGALES SUR LA TRONCHE À RESPECTER.
Ben… si l'appli en est à vérifier l'intégrité du téléphone au delà de safety net, alors quel est l'intérêt du safety net qui est fermé comparé à un système open source?
J’ai déjà expliqué 42.000×.
Ton appli open source N’A PASSÉ AUCUNE CERTIFICATION ET NE PROPOSE AUCUNE ASSURANCE EN CAS DE RATÉ aux banques.
Fait ta solution opensource, présente-là à l’EBA, fait en sorte que l’EBA accepte ta solution, finance tes infras pour gérer tout ça, passe la certification bancaire obligatoire et souscrit à des assurances que les banques vont te demander.
Voilà.
C’est ce qu’a fait Let's Encrypt pour réussir à rentrer dans le monde des root CA reconnus par les navigateurs.
Juste beugler « oui mais le libre c’est mieux », c’est omettre 99.9999% de la chaîne et t’as absolument 0 chance de passer la moindre étape pour intégrer la chaîne de confiance.
Ton safety net doit s'assurer que ton device est à jour (bon un système troué pourra prétendre l'être)
Ah ? Première nouvelle.
Le Safety Net est juste là pour dire « moi je garanti que je fais tourner un OS en version machin ». C’est au développeur ensuite de dire « ok, moi je fais tourner un jeu mobile, donc ta version pérave, je m’en cogne, tient voilà mon application » quand une banque dira « hum, c’est un peu tout pourri et t’as plus de maj de sécu, donc je te jette » et qu’une application SoftPOS PSP dira « attend, t’as 2 versions mineures de retard et tu comptes vraiment faire transiter des données PCI-DSS là-dessus ???? ».
C’est pas Safety Net qui prend la décision encore une fois, Safety Net ne fait que remonter l’état de ton système au développeur, qui prend ensuite la décision d’accepter ou non le risque. À chaque modèle de menace et risques sa réponse.
Safety Net doit uniquement et exclusivement garantir que les infos qu’il remonte sont fiables et qu’il est relativement robuste à des attaques diverses et variés (donc oui, signature de l’OS, clef crypto en TPM qui est effacé au moindre flash d’une ROM alternative, etc, etc, etc).
C’est aussi pour ça que les banques cherchent les applis root ou autre : pour s’assurer que la réponse Safety Net est légitime et pas un truc forgé par Magisk ou autre. Si doute, alors le téléphone n’est plus considéré comme légitime et safe et l’éditeur rejettera l’exécution.
Va tu prétendre que je suis moins sécurisé maintenant?
Non, mais je ne prétendrais pas que tu es sécurisé non plus (probablement : bootloader déverrouillé, téléphone rooté, ROM de source douteuse, etc).
Tu utilises un téléphone rooté sans verrouillage du bootloader ? Tu as une sécurité très certainement aussi peu enviable que de conserver un téléphone avec un OS sans security fix depuis 2 ans.
Faire un classement de qui est le moins pourri entre deux systèmes manifestement totalement défaillants en terme de sécurité, c’est assez peu ma came.
sinon le Safety Net aurait dit que mon téléphone n'était pas sécurisé.
Le SafetyNet a fait justement son taff, ou plus exactement permet aux banques de faire le leur : interdire l’usage de leurs applications sur un téléphone qu’elles jugent non sécurisé.
Ce n’est pas SafetyNet qui prend la décision, mais les banques.
Tu peux, mais en attendant la loi est comme ça et le régulateur a (malheureusement ou pas, la question n’est pas là) reconnu que passer par Google était plus sécurisé qu’avoir un téléphone rooté.
Et factuellement toute personne qui fait de la vraie sécurité sera forcée de reconnaître qu’un téléphone rooté (et pire, sans bootloader verrouillé) est un véritable risque énorme en terme de sécurité.
Donc entre SafetyNet et un téléphone rooté, j’aurais aucun problème à reconnaître que le 1er est TRÈS LARGEMENT meilleur en terme de sécu que le 2nd. Et donc bien du mal à en critiquer la position du régulateur.
Encore une fois, il faudra aussi que le libre se bouge sur le sujet pour proposer des alternatives réellement crédibles pour répondre à un vrai besoin réel de garantie d’intégrité au moment de l’exécution.
Et pas que pour les banques d’ailleurs, les développeurs (et non les utilisateurs) ont de plus en plus besoin de s’assurer de l’intégrité de l’application réellement exécutée, et sur ce terrain il n’y a que Google et Apple qui ont apportés des solutions.
GrapheneOS a commencé le taff, mais personne ne les suit. https://grapheneos.org/articles/attestation-compatibility-guide
Et encore une fois tu dis absolument n’importe quoi.
Le passage de la DSP2 impose la garantie d’intégrité
L’EBA a étudié cette obligation et en a déduit l’obligation de s’assurer du non jailbrake ou root des téléphones.
L’EBA n’est malheureusement pas un législateur mais « seulement » un régulateur, et ne peut donc pas imposer d’obligation législative en tant que telle (droit souple = interdit d’interdire ou interdit d’autoriser), par contre elle peut émettre des recommandations… dont elle est elle-même le régulateur.
C’est un peu comme si t’allais dire que tu pouvais chier sur les recommandations de l’ANSSI, de la CNIL ou de l’ACPR au motif que c’est juste des recommandations et pas une législation. 🙄
Et autant ils ont pas de pouvoir législatif, autant ils sont doté de pouvoir de sanction (en tout cas CNIL et ACPR). Et autant te dire que te sanctionner sur la seule base de leur recommadation, ils sauront faire.
En l’espèce, la formation restreinte relève que, dans le cadre de ses écritures, le rapporteur s’attache notamment à caractériser la commission par la société d’un manquement aux obligations prévues à l’article 32 du RGPD, telles qu’éclairées par de nombreuses recommandations de la CNIL et de l’ANSSI, qui sont publiques et antérieures aux faits reprochés.
La formation restreinte rappelle que, si les recommandations de la Commission et de l’ANSSI n’ont certes pas de caractère impératif, elles précisent et illustrent les dispositions législatives et réglementaires applicables et éclairent les acteurs sur les mesures concrètes et conformes à l’état de l’art à mettre en œuvre.
À bon entendeur…
Concernant le supposé contrôle par Google, la banque non seulement s’en fout, mais en plus LE SOUHAITE. Google leur CERTIFIE que l’application bancaire ne sera pas modifié, et c’est ce que la banque souhaite, et que Google est même prêt à la payer si jamais Safetynet conduisait à de la fraude (ils ont des assurances pour ça de toute façon).
Ils sont dans tous les cas qualifiés et certifiés en ce sens par les autorités bancaires, et donc la banque s’en contrefiche totalement du reste, elle a son papier qui lui dit qu’elle respecte les obligations réglementaires et les recommandations de l’EBA en la matière.
Et donc c’est pas que la DPS2 interdit le rootage des téléphones, c’est que la DSP2 impose aux banques qu’elles cherchent à détecter si ton téléphone est rooté ou non et à t’interdire d’y utiliser son application mobile si c’est le cas, parce qu’elle n’a plus l’assurance que le matériel cryptographique de calcul de la 2FA ou le contexte d’exécution et donc d’affichage correspond bien à ses obligations légales.
SG also recommends considering corrupted devices (for instance a device under jailbreak or root access) as a complement to the risks set forth in paragraph 45.
Bref, tu ne sembles manifestement pas du tout maîtriser le sujet.
La DSP2 impose le contrôle de l’intégrité du téléphone PAR LA BANQUE (article 97(3))
Les directives EBA qui en dérivent nécessitent la détection du root du téléphone. J’ai cité les liens qui vont bien plus haut. Tu pourras trouver les RTS qui vont bien aussi je suppose, en fouillant bien les Internet.
On the other hand, when mobile features are involved and particularly when mobile payment instruments are used it seems relevant to ensure that no “jailbreak” / “root” procedure has taken place on the used device, as such manipulation of factory settings could render the device more prone to the installation of malware and the compromise of security features.
Je te l’ai déjà expliqué, mais tu persistes à dire que je racontes n’importe quoi, sachant que c’est littéralement mon boulot au quotidien, alors que tu t’obstines à balancer des poncifs totalement faux sans savoir manifestement de quoi tu parles.
Non, c’est bien aussi la confidentialité, ce qui implique les traitements sur ces données pour en empêcher la duplication, transmission, compromission et j’en passe.
Bref, manifestement tu n’as pas étudié la DSP2 et tu ne sais pas de quoi tu parles.
Et tu proposes quoi en attendant ? On a attendu 40 ans pour Let's Encrypt hein… Et on n’avait pas de solution alternative, et on a toujours pas de solution alternative sans matos type HSM propriétaire hein.
C’est la transposition en directive EBA de la législation DSP2. Mais la législation est claire que tu dois t’assurer de l’intégrité du système. Et ça, le libre ne sait pas le faire. Tu sais éventuellement l’assurer à l’utilisateur, mais là on parle de devoir l’assurer au développeur (la banque).
Mais c’est autre chose que juste des recommandations au sens commun du terme. Si tu te fais contrôler, tu te prendras une prune pour ne pas avoir respecter la législation puisque l’autorité en charge de la faire appliquer et donc de te sanctionner dira bien entendu qu’elle est d’accord avec elle-même et que tu ne peux pas respecter la législation sans respecter ses recommandations.
Il te faudra en tout cas de très bons arguments si tu veux démontrer que tu respectes la législation sans respecter les recommandations, mais en l’état typiquement sur la DSP2, le libre est incapable de démontrer ça.
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.
[^] # 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 c’est une FAQ ou une charte , qui n’engage donc… pas grand monde.
Et c’est marqué « dans la mesure du possible ». Y’a pas de solution légale alternative en l’état. Donc bon 😅
[^] # 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é à 3 (+2/-0).
Spoiler : il n’y a que la DSP3 qui impose(ra?) dorénavant a priori un système alternatif, mais qui doit être équivalent en terme de sécurité à la version smartphone
Mais le texte n’est pas encore définitif, pour le moment ce n’est qu’une note d’intérêt
https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:52023PC0366
[^] # 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 bon, c’est écrit où dans la législation ? 😏
Et quel système alternatif respecte les obligations légales qui, elles, sont bien écrites ? 😏
[^] # 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).
La différence de sécurité est plus que notable oui, mais pas dans le sens que tu penses.
C’est plus que documenté qu’un téléphone rooté avec le bootloader non verrouillé est AUTREMENT plus unsafe que même le xiaomi le plus pourrave rempli de merde en tout genre (qui resteront bien gentiment sandboxées parce que justement sans root).
Et c’est bien pour ça que les banques imposent généralement une version minimale et à jour de ton OS. Et c’est encore pire pour les SoftPOS bancaires.
[^] # 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).
Sauf que le choix n’est pas celui-là, et que tu te places encore une fois du côté DE L’UTILISATEUR, sauf que j’ai répété 42.000× que c’est celui DES BANQUES qui compte.
C’est ELLES qui encaissent le risque de contestation et donc d’avoir à te rembourser SUR SA THUNE les paiements frauduleux.
Elle en a rien à carrer de ce que toi tu penses mieux sur ton PC, c’est sa thune qu’elle est en train de jouer là.
C’est donc pas « Android avec surcouche Xiaomi de Tata Michu avec 628 applis malwares » puisque SafetyNet sur un tel téléphone garanti toujours que l’application banque est safe (et encaissera la fauche s’ils ont faussement attesté le truc et que c’est démontré par la banque) vs « Debian Stable sur le PC de Tonton Barbu avec libreboot et que des applis libres » que la banque se contrefiche parce qu’elle n’a aucune garantie (justement parce que c’est libre) que t’as pas bricolé son app bancaire et donc que sa SCA n’est plus conforme et que tu pourrais la contester en cas de fraude.
C’est « Android avec surcouche Xiaomi de Tata Michu avec 628 applis malwares que de toute façon SafetyNet sur un tel téléphone garanti toujours que l’application banque est safe (et encaissera la fauche s’ils ont faussement attesté le truc et que c’est démontré par la banque) et que la banque fait 2-3 vérifs en plus que t’as pas des merdes root ou screen reader actif » vs « un téléphone rooté que la banque sait de base que tu peux bypass SafetyNet et qu’elle ne peut pas avoir confiance en ton machin parce qu’elle ne sait pas ce que tu fais de la SCA et donc que ça sera contestable en cas de fraude ».
Encore une fois, place-toi du côté de la banque QUI A DES OBLIGATIONS LÉGALES SUR LA TRONCHE À RESPECTER.
[^] # 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 (+2/-2).
J’ai déjà expliqué 42.000×.
Ton appli open source N’A PASSÉ AUCUNE CERTIFICATION ET NE PROPOSE AUCUNE ASSURANCE EN CAS DE RATÉ aux banques.
Fait ta solution opensource, présente-là à l’EBA, fait en sorte que l’EBA accepte ta solution, finance tes infras pour gérer tout ça, passe la certification bancaire obligatoire et souscrit à des assurances que les banques vont te demander.
Voilà.
C’est ce qu’a fait Let's Encrypt pour réussir à rentrer dans le monde des root CA reconnus par les navigateurs.
Juste beugler « oui mais le libre c’est mieux », c’est omettre 99.9999% de la chaîne et t’as absolument 0 chance de passer la moindre étape pour intégrer la chaîne de confiance.
[^] # 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 (+1/-0).
Ah ? Première nouvelle.
Le Safety Net est juste là pour dire « moi je garanti que je fais tourner un OS en version machin ». C’est au développeur ensuite de dire « ok, moi je fais tourner un jeu mobile, donc ta version pérave, je m’en cogne, tient voilà mon application » quand une banque dira « hum, c’est un peu tout pourri et t’as plus de maj de sécu, donc je te jette » et qu’une application SoftPOS PSP dira « attend, t’as 2 versions mineures de retard et tu comptes vraiment faire transiter des données PCI-DSS là-dessus ???? ».
C’est pas Safety Net qui prend la décision encore une fois, Safety Net ne fait que remonter l’état de ton système au développeur, qui prend ensuite la décision d’accepter ou non le risque. À chaque modèle de menace et risques sa réponse.
Safety Net doit uniquement et exclusivement garantir que les infos qu’il remonte sont fiables et qu’il est relativement robuste à des attaques diverses et variés (donc oui, signature de l’OS, clef crypto en TPM qui est effacé au moindre flash d’une ROM alternative, etc, etc, etc).
C’est aussi pour ça que les banques cherchent les applis root ou autre : pour s’assurer que la réponse Safety Net est légitime et pas un truc forgé par Magisk ou autre. Si doute, alors le téléphone n’est plus considéré comme légitime et safe et l’éditeur rejettera l’exécution.
[^] # 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).
Non, mais je ne prétendrais pas que tu es sécurisé non plus (probablement : bootloader déverrouillé, téléphone rooté, ROM de source douteuse, etc).
Tu utilises un téléphone rooté sans verrouillage du bootloader ? Tu as une sécurité très certainement aussi peu enviable que de conserver un téléphone avec un OS sans security fix depuis 2 ans.
Faire un classement de qui est le moins pourri entre deux systèmes manifestement totalement défaillants en terme de sécurité, c’est assez peu ma came.
Le SafetyNet a fait justement son taff, ou plus exactement permet aux banques de faire le leur : interdire l’usage de leurs applications sur un téléphone qu’elles jugent non sécurisé.
Ce n’est pas SafetyNet qui prend la décision, mais les banques.
[^] # 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 (+0/-3).
Tu peux, mais en attendant la loi est comme ça et le régulateur a (malheureusement ou pas, la question n’est pas là) reconnu que passer par Google était plus sécurisé qu’avoir un téléphone rooté.
Et factuellement toute personne qui fait de la vraie sécurité sera forcée de reconnaître qu’un téléphone rooté (et pire, sans bootloader verrouillé) est un véritable risque énorme en terme de sécurité.
Donc entre SafetyNet et un téléphone rooté, j’aurais aucun problème à reconnaître que le 1er est TRÈS LARGEMENT meilleur en terme de sécu que le 2nd. Et donc bien du mal à en critiquer la position du régulateur.
Encore une fois, il faudra aussi que le libre se bouge sur le sujet pour proposer des alternatives réellement crédibles pour répondre à un vrai besoin réel de garantie d’intégrité au moment de l’exécution.
Et pas que pour les banques d’ailleurs, les développeurs (et non les utilisateurs) ont de plus en plus besoin de s’assurer de l’intégrité de l’application réellement exécutée, et sur ce terrain il n’y a que Google et Apple qui ont apportés des solutions.
GrapheneOS a commencé le taff, mais personne ne les suit.
https://grapheneos.org/articles/attestation-compatibility-guide
[^] # 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 04 mai 2026 à 16:09.
Et encore une fois tu dis absolument n’importe quoi.
Le passage de la DSP2 impose la garantie d’intégrité
L’EBA a étudié cette obligation et en a déduit l’obligation de s’assurer du non jailbrake ou root des téléphones.
L’EBA n’est malheureusement pas un législateur mais « seulement » un régulateur, et ne peut donc pas imposer d’obligation législative en tant que telle (droit souple = interdit d’interdire ou interdit d’autoriser), par contre elle peut émettre des recommandations… dont elle est elle-même le régulateur.
C’est un peu comme si t’allais dire que tu pouvais chier sur les recommandations de l’ANSSI, de la CNIL ou de l’ACPR au motif que c’est juste des recommandations et pas une législation. 🙄
Et autant ils ont pas de pouvoir législatif, autant ils sont doté de pouvoir de sanction (en tout cas CNIL et ACPR). Et autant te dire que te sanctionner sur la seule base de leur recommadation, ils sauront faire.
Je rappelle aussi la position de la CNIL sur le sujet des recommandations de droit souple
https://www.legifrance.gouv.fr/cnil/id/CNILTEXT000053352643
À bon entendeur…
Concernant le supposé contrôle par Google, la banque non seulement s’en fout, mais en plus LE SOUHAITE. Google leur CERTIFIE que l’application bancaire ne sera pas modifié, et c’est ce que la banque souhaite, et que Google est même prêt à la payer si jamais Safetynet conduisait à de la fraude (ils ont des assurances pour ça de toute façon).
Ils sont dans tous les cas qualifiés et certifiés en ce sens par les autorités bancaires, et donc la banque s’en contrefiche totalement du reste, elle a son papier qui lui dit qu’elle respecte les obligations réglementaires et les recommandations de l’EBA en la matière.
[^] # 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 (+1/-0).
Et donc c’est pas que la DPS2 interdit le rootage des téléphones, c’est que la DSP2 impose aux banques qu’elles cherchent à détecter si ton téléphone est rooté ou non et à t’interdire d’y utiliser son application mobile si c’est le cas, parce qu’elle n’a plus l’assurance que le matériel cryptographique de calcul de la 2FA ou le contexte d’exécution et donc d’affichage correspond bien à ses obligations légales.
[^] # 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).
Tu trouveras aussi le problème exposé ici :
https://www.eba.europa.eu/eba-response/345
Bref, tu ne sembles manifestement pas du tout maîtriser le sujet.
[^] # 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 (+1/-0).
C’est ça. Et ça se découle en recommandation et RTS côté EBA qui disent que les téléphones rootés et cie ne respectent pas ce critère d’intégrité.
[^] # 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 (+1/-0). Dernière modification le 04 mai 2026 à 15:21.
La DSP2 impose le contrôle de l’intégrité du téléphone PAR LA BANQUE (article 97(3))
Les directives EBA qui en dérivent nécessitent la détection du root du téléphone. J’ai cité les liens qui vont bien plus haut. Tu pourras trouver les RTS qui vont bien aussi je suppose, en fouillant bien les Internet.
Tiens encore un petit ici : https://www.eba.europa.eu/eba-response/331
Je te l’ai déjà expliqué, mais tu persistes à dire que je racontes n’importe quoi, sachant que c’est littéralement mon boulot au quotidien, alors que tu t’obstines à balancer des poncifs totalement faux sans savoir manifestement de quoi tu parles.
[^] # 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 tu onboard comment ton OTP sans avoir de solution anti-root ? 😏
Manifestement tu ne comprends pas la DSP2, et manifestement entre nous deux celui qui l’a le plus étudiée n’est pas toi.
Et non, je ne sur-interprète pas les textes, j’ai par exemple déjà cité https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2018_4039 qui discalifie le SMS pour justement tous les motifs indiqués (pas de certitude du device, duplication possible, etc)
[^] # 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).
Non, c’est bien aussi la confidentialité, ce qui implique les traitements sur ces données pour en empêcher la duplication, transmission, compromission et j’en passe.
Bref, manifestement tu n’as pas étudié la DSP2 et tu ne sais pas de quoi tu parles.
[^] # 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).
Et tu proposes quoi en attendant ? On a attendu 40 ans pour Let's Encrypt hein… Et on n’avait pas de solution alternative, et on a toujours pas de solution alternative sans matos type HSM propriétaire hein.
[^] # 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).
C’est la transposition en directive EBA de la législation DSP2. Mais la législation est claire que tu dois t’assurer de l’intégrité du système. Et ça, le libre ne sait pas le faire. Tu sais éventuellement l’assurer à l’utilisateur, mais là on parle de devoir l’assurer au développeur (la banque).
Pour l’EBA et la DSP2, c’est comme pour la CNIL et le RGPD, c’est du droit souple et elle ne peut pas écrire « vous devez » sinon elle se fait rattraper par la patrouille du Conseil d’État/Commission Européenne, donc elle se limite à des « recommandations ».
https://www.conseil-etat.fr/actualites/le-conseil-d-etat-annule-partiellement-les-lignes-directrices-de-la-cnil-relatives-aux-cookies-et-autres-traceurs-de-connexion
Mais c’est autre chose que juste des recommandations au sens commun du terme. Si tu te fais contrôler, tu te prendras une prune pour ne pas avoir respecter la législation puisque l’autorité en charge de la faire appliquer et donc de te sanctionner dira bien entendu qu’elle est d’accord avec elle-même et que tu ne peux pas respecter la législation sans respecter ses recommandations.
Il te faudra en tout cas de très bons arguments si tu veux démontrer que tu respectes la législation sans respecter les recommandations, mais en l’état typiquement sur la DSP2, le libre est incapable de démontrer ça.
[^] # 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 (+1/-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é à -1 (+0/-2).
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é à 1 (+1/-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é à 1 (+1/-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/