L’obligation croissante d’utiliser une application mobile bancaire pour valider des opérations sensibles devient un problème bien réel pour une partie des usagers : personnes sans smartphone, téléphones trop anciens, appareils non compatibles, ou encore systèmes alternatifs et dégooglisés.
Le sujet n’est pas seulement bancaire. Il touche aussi aux logiciels libres, à la liberté de choix technique, et plus largement à l’exclusion numérique. Lorsqu’une opération essentielle ne peut plus être validée que depuis une application propriétaire distribuée dans les écosystèmes de Google ou d’Apple, l’accès au service dépend alors d’un canal technique unique.
Le cas de BoursoBank a récemment relancé la discussion sur LinuxFr. Dans mon cas, lors d’opérations sécurisées, l’interface web m’a renvoyé vers l’application mobile comme unique moyen de validation. Certaines pages d’aide de la banque évoquent pourtant des solutions alternatives ou de secours, mais le service client m’a indiqué aujourd’hui qu’il n’existait en pratique pas d’autre moyen de valider ces opérations sans l’application mobile.
C’est précisément ce décalage entre la communication affichée, l’expérience réelle et la réponse du support qui pose problème. Il laisse l’usager dans une situation d’incertitude, y compris lorsqu’il cherche à quitter ce modèle pour une autre banque, sans garantie de ne pas retrouver la même contrainte quelques mois plus tard.
Cette évolution interroge : pourquoi ne pas proposer systématiquement des alternatives robustes, comme un second facteur indépendant de l’application mobile ?
Dans ce contexte, une pétition a été lancée pour demander que les banques opérant en France proposent au moins une méthode de validation forte utilisable sans application mobile imposée. Elle met en avant un principe simple : une banque peut être sécurisée sans réserver de fait ses services aux smartphones Google ou Apple.
Aller plus loin
- Pétition sur change.org (662 clics)
- la FAQ BoursoBank sur l’accès sans application (127 clics)
- la FAQ BoursoBank sur la validation des paiements (72 clics)
# Une pétition sur change.org
Posté par jpglinuxfr . Évalué à 6 (+6/-1).
Merci pour cette info mais je me questionne sur l'utilité de ce type de pétition (change.org, etc.). Tant qu'on n'a pas de RIC en France, ça sert vraiment à quelque chose ? (sans ironie de ma part)
Les autres pistes et actions évoquées sur la précédente discussion sur linuxfr ne seraient-elles pas plus efficaces ?
J'en profite pour dire que j'utilise uniquement smartphone (lineageos sans gapps) et ordi (linux) et que je n'ai pas de problème. À chaque fois que je fais un virement ou quelque chose de sensible dans les deux banques que j'utilise (banques déjà évoquées dans ladite discussion), j'ai droit à un code par mail ET un autre par texto pour valider l'opération. C'est un peu pénible et lent mais ça fonctionne.
[^] # Re: Une pétition sur change.org
Posté par Lenbootil . Évalué à 8 (+8/-0).
Certaines pétitions sur le site de l'Assemblée Nationale ont été des succès. Pas directement (la plupart du temps, elles sont "classées sans suite" en commission), mais la pression sur le législateur est bien réelle.
De toute façon, chaque canal de communication est une occasion de faire remonter le sujet en haut de la pile.
Tant mieux pour toi. Mais c'est loin d'être une généralité.
De mon côté, je suis régulièrement emm… bêté par ma banque, qui exige un… hem… "mobile enrôlé" pour créer des cartes bancaires virtuelles. Solution rapide : utiliser les numéros de ma carte bancaire physique pour payer mes factures (s'il fallait une preuve par l'absurde que trop de sécurité tue la sécurité, en voici une). Solution pénible : ouvrir un énième ticket de réclamation sur une messagerie gérée par des bots. Ça fait au moins trois ans que je résiste, et les blocages sont de plus en plus nombreux.
[^] # Re: Une pétition sur change.org
Posté par Astaoth . Évalué à 6 (+4/-0).
Je me suis posé la même question, tout comme pourquoi garder ca au niveau national. A la place j'aurais plutôt vu une pétition européenne qui aurait eu :
- plus de visibilité
- couvert un public plus grand
- les lois nationales sont soumises au cadre de l'EU. Il suffit d'une décision de l'EU pour casser une législation nationale. Une loi EU aurait plus de pérénité sur le sujet.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Une pétition sur change.org
Posté par Maderios . Évalué à 3 (+1/-0). Dernière modification le 27 avril 2026 à 11:49.
Il ne s'agit pas de validation par texto mais par application mobile bancaire. Concernant la banque postale, elle fournit sa propre application android pour utiliser le service Certicode Plus (service non obligatoire)
Méthode (à vos risques et périls, jamais essayée) qui permettrait l'utilisation d'une appli bancaire sur un android rooté https://blog.cubieserver.de/2025/running-banking-apps-and-other-suspects-on-custom-roms-with-root/
[^] # Re: Une pétition sur change.org
Posté par jpglinuxfr . Évalué à 9 (+8/-0).
J'ai peut-être mal compris ce dernier message mais j'avais bien compris la différence entre une appli obligatoire et la réception d'un code par texto à saisir sur un formulaire web.
Je disais juste comment ça se passait pour moi, c'est-à-dire que je n'avais pas à passer par une appli.
Ce que je ne savais pas, c'est que le problème de l'appli obligatoire concernait surtout les nouveaux clients. Pour le moment, ils laissent les anciens clients tranquilles mais ça ne durera probablement pas si on ne fait rien.
Ceci dit, le problème de notre impuissance fondamentale à changer les choses reste posé : nous ne sommes pas en démocratie, juste dans un système qui y ressemble de très loin. On peut faire une pétition pour l'utilisation de nos comptes bancaires, une autre sur le climat, une autre pour l'hopital, une autre sur la justice, etc. Tant qu'on ne change pas le fonctionnement du système, on en est réduit à râler, à quémander. Il faut exiger beaucoup plus à mon avis 😉
# N'est-ce pas un droit ?
Posté par Sygne (site web personnel) . Évalué à 8 (+6/-0).
Je croyais que l'alternative à l'application mobile était un droit. Et Que Choisir semble le confirmer :
Qu'en est-il donc ?
[^] # Re: N'est-ce pas un droit ?
Posté par guiohm . Évalué à 10 (+10/-0).
Pour ma part, dans mon expérience avec Boursobank, j'ai utilisé dans le passé leur app, mais j'ai maintenant un tel avec ROM custom (je veux m'éloigner des services Google et des pubs) qui fait que leur app refuse de fonctionner.
Lors de mon appel jeudi dernier, le conseiller m'a répété plusieurs fois qu'il ne pouvait rien faire (avec pause pour consulter un responsable entre temps), et quand je lui ai dit que j'étais donc obligé de changer de banque, il m'a répondu : "Oui je comprends, désolé".
Du coup mon interprétation de leur procédure interne est : Si un client n'a jamais utilisé l'app, on laisse encore les anciens mécanismes en place, mais pour quelqu'un comme moi, ils ne veulent plus retourner en arrière.
[^] # Re: N'est-ce pas un droit ?
Posté par sebas . Évalué à 9 (+7/-0).
Exactement, c'est même écrit en toutes lettres dans leur FAQ :
Du coup, si tu casses ton spyphone, ou que tu veux le dégoogliser, t'es cuit. Ce qui effectivement est en contradiction avec les prescriptions gouvernemtales :
[^] # Re: N'est-ce pas un droit ?
Posté par Astaoth . Évalué à 7 (+5/-0).
Je confirme, n'ayant jamais utilisé d'app pour bourso, je n'ai vu aucun changement de mon côté.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: N'est-ce pas un droit ?
Posté par deyv . Évalué à 7 (+7/-0).
Dans le cas de boursobank et lineageos (Android unlock), l'application accepte d'enregistrer le téléphone en tant que tiers de confiance, mais une fois fait, elle refuse d'utiliser ce téléphone.
Il suffit de demander de révoquer ce téléphone en indiquant qu'on utilise le navigateur. Cette révocation demande quelques jours.
Une fois fait, la 2fa avec le navigateur (pc ou android) fonctionne (mail+sms pour chaque opération sensible).
[^] # Re: N'est-ce pas un droit ?
Posté par pfelelep (site web personnel, Mastodon) . Évalué à 7 (+7/-0).
bonjour,
pour mon cas, lineageOS (20:0), l'app boursobank m'envoie un message d'erreur lorsque je me connecte, MAIS si je me déconnecte et que je me reconnecte dans la foulée… tout fonctionne.
Et cela depuis quelques années déjà avec l'app boursobank sur 2 téléphones différents sous LineageOS.
Je suis conscient que le sujet de cet article est d'avoir le choix de ne PAS utiliser l'app des banques, mais si cela peut aider?
Cordialement.
Pfelelep
[^] # Re: N'est-ce pas un droit ?
Posté par Stephane21 . Évalué à 4 (+4/-0).
S'agit il de "Lineage" ou bien de "Lineage + Services Google" ?
De mon coté, sur "GrapheneOS + Sandboxed GooglePlay", l'appli Boursorama fonctionne bien en bloquant les requêtes vers "Play Integrity API". GrapheneOS renvoie le code d'erreur "API is not available" à l'application Boursorama. Cette astuce fonctionne avec toutes les applis qui ont mal implémenté la vérification "Play Integrity".
[^] # Re: N'est-ce pas un droit ?
Posté par pfelelep (site web personnel, Mastodon) . Évalué à 1 (+1/-0).
Lineage + MigroG (une ré-implementation libre des services googles)
https://github.com/microg/GmsCore/wiki
Pfelelep
[^] # Re: N'est-ce pas un droit ?
Posté par deyv . Évalué à 3 (+3/-0).
Dans le cas de boursobank et lineageos (Android unlock), l'application accepte d'enregistrer le téléphone en tant que tiers de confiance, mais une fois fait, elle refuse d'utiliser ce téléphone.
Il suffit de demander de révoquer ce téléphone en indiquant qu'on utilise le navigateur. Cette révocation demande quelques jours.
Une fois fait, la 2fa avec le navigateur (pc ou android) fonctionne (mail+sms pour chaque opération sensible).
[^] # Re: N'est-ce pas un droit ?
Posté par Voltairine . Évalué à 8 (+6/-0).
Oui cela a déjà été discuté et les textes cités
, extrait :
Si la banque refuse de fournir une autre méthode, il faut la mettre face à ses responsabilités et envisager sérieusement d'en changer.
Faire signer une pétition qui demande un droit qui existe déjà risque de ne pas servir à grand chose. Dénoncer publiquement, et auprès des associations de consommateurs, les pratiques déloyales d'une banque serait sans doute plus utile.
[^] # Re: N'est-ce pas un droit ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10 (+8/-0).
Depuis quand le fait que quelque chose soit obligatoire ou interdit s'imposerait-il automatiquement aux acteurs concernés ?
Par exemple, lorsqu'un employeur licencie un salarié, il doit fournir un certificat de travail destiné à Pôle Emploi. Ce document est indispensable pour prétendre toucher des allocations de chômage. Sauf que si le licenciement s'est effectué sur de mauvais termes, par exemple sur une faute lourde, voire pire, parce que l'employé a signalé des problèmes qui dérangent la hiérarchie, l'employeur peut se permettre de s'amuser à faire de la rétention de documents. Concrètement, ça met l'ancien employé dans une situation très difficile, où il est évidemment impossible de toucher des allocations de chômage, mais où il peut même être impossible de prendre un nouvel emploi.
Un autre exemple : depuis des années, les copropriétés équipées de chauffage collectif sont dans l'obligation d'installer des compteurs de chauffage individuels. Cela peut s'installer sur l'arrivée d'eau chaude ou sur les radiateurs selon comment l'installation est faite. C"est obligatoire donc, mais ça ne s'installe pas par magie, pour que ce soit mis en place, il choisir un installateur, puis décider l'installation par un vote favorable de l'assemblée générale des copropriétaires. Et dans les copropriétés pleines de vieux égoïstes frileux qui aiment bien être chauffés à 25°C aux frais des autres, ça vote systématiquement contre. La mise en place de compteurs est obligatoire, ça oui, mais en pratiquement, cette obligation est carrément facultative, pour y échapper il suffit de ne pas le faire. (Et de prendre ses responsabilités, à la mode du président Macron)
Allez, encore un autre exemple. Si vous avez un enfant majeur sous curatelle et que vous l'hébergez, depuis quelques années il n'a pas besoin de votre accord pour se marier. Sauf qu'en fait si, parce que si vous ne voulez pas lui permettre de se marier, c'est facile, il suffit de ne pas lui remettre d'attestation d'hébergement, puisqu'on ne peut pas se marier sans justificatif de domicile.
Bref, les exemples sont multiples. Des tas de trucs sont obligatoires ou interdits, mais en réalité, la plupart des prescriptions sont en général facultatives, dès lors qu'il n'y a pas de répression organisée, voir s'il n'est carrément pas prévu de sanction en cas de non respect.
[^] # Re: N'est-ce pas un droit ?
Posté par arnaudus . Évalué à 4 (+3/-2).
C'est tout à fait vrai, et il y a plein de situations absurdes comme ça dans la vie où la loi oblige quelqu'un à faire quelque chose mais ne prévoit pas de sanction ni de procédure dérogatoire. C'est même souvent le cas pour les documents administratifs, la loi impose tout un tas de délais (pour avoir un RDV à la préfecture, pour un jugement, etc), mais il n'existe aucun mécanisme pour forcer l'administration en question à respecter ces délais (le mieux que tu puisses espérer est de faire condamner l'État, bon courage).
Là, on est dans le cadre du droit du commerce, la loi impose à un commerçant de faire quelque chose, et le commerçant refuse. Ça pourrait être payer en liquide, séparer deux articles dans le cadre d'une vente liée, n'importe quoi, c'est le même principe. Tu peux saisir la répression des fraudes, tu peux changer de crêmerie, tu peux poursuivre au tribunal si tu considères que tu as été lésé, mais rien de ceci ne résoudra ton problème. Concrêtement, tu es là, chez le boulanger, avec ton billet de 10€, et le boulanger te dit qu'il ne le prend pas, il a tort, il est pourtant obligé, tu peux lui prouver, mais il te dit "non" quand même. C'est la vie réelle, c'est un rapport de force, il est objectivement absurde, lui fait le pari que tu vas lacher l'affaire, et c'est probablement l'intérêt de toutes les parties que tu lâches l'affaire.
En l'occurrence, pour l'histoire des appli bancaires, il semble tout à fait possible que la banque perde moins d'argent en perdant un client qu'en maintenant un système d'identification rarement utilisé tout en restant sensible au niveau de la sécurité. En étant même plus cynique, il est peut-être possible que ton profil de clients n'est pas réellement celui qu'ils recherchent (pas de smartphone = probablement pas un acheteur compulsif qui va activer les options du retrocashback Amazon, dont la revente des données associées rapporte probablement bien plus que les activités bancaires). Est-ce ton intérêt de rester client d'une banque qui souhaite se débarrasser de toi? À court terme, c'est casse-pieds de changer de banque, mais de toutes manières ils trouveront bien un moyen de te "rentabiliser" (c'est même un devoir pour une entreprise commerciale), éventuellement en augmentant les frais bancaires pour tout le monde, et en accordant un discount de 90% pour les utilisateurs du retrochashback…).
[^] # Re: N'est-ce pas un droit ?
Posté par vpo . Évalué à 7 (+6/-0).
Le code du commerce s'applique aux entreprises pas aux particuliers en général.
Pour les relations entre les banques et les particuliers, c’est surtout le code monétaire et financier qui encadre les obligations des banques. Et le code de la consommation s’applique aussi à certains volets quand le client est un particulier et non une entreprise.
Pour le billet de 10 euros chez le boulanger, tout dépend si le montant à payer est d'au moins 10 euros. Le fait de refuser un billet qui a cours légal est une infraction pénale (Article R642-3 du Code Pénal). Donc bien sûr ça ne s'applique pas si le commerçant dit que le billet est faux.
Mais le client est tenu de régler le montant exact, donc de faire l'appoint.
Article L112-5 du Code Monétaire et financier
C'est donc au commissariat qu'il faut porter plainte puisque c'est une infraction pénale même si un signalement à la répression des fraudes ne peut pas faire de mal.
[^] # Re: N'est-ce pas un droit ?
Posté par floriang . Évalué à 2 (+1/-0).
Par conséquent, rien n'oblige le commerçant à rendre la monnaie sur ces 10 euros. Le rendu monnaie n'étant finalement qu'un geste commercial.
[^] # Re: N'est-ce pas un droit ?
Posté par Pol' uX (site web personnel) . Évalué à 2 (+0/-0).
Disons que le refus de la vente par paiement espèce n'est pas pénalisé si le vendeur n'a pas de quoi rendre la monnaie et que l'acheteur n'a pas amené l'appoint.
Adhérer à l'April, ça vous tente ?
[^] # Re: N'est-ce pas un droit ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5 (+2/-0).
C'est surtout que ce n'est pas un refus de vente. C'est un refus de rendu de monnaie, qui conduit à un refus d'achat de la part du client.
[^] # Re: N'est-ce pas un droit ?
Posté par Pol' uX (site web personnel) . Évalué à 2 (+0/-0).
Dans ce cas oui mais tu peux aussi par exemple légitimement refuser la vente à quelqu'un qui amène l'appoint en espèce, si cet appoint est déraisonnable (par exemple 10€ apporté en pièces de 1 et 2 cents).
Adhérer à l'April, ça vous tente ?
[^] # Re: N'est-ce pas un droit ?
Posté par vpo . Évalué à 2 (+1/-0). Dernière modification le 29 avril 2026 à 15:55.
Oui mais dans la limite de 50 pièces, ce qui laisse de la marge pour enquiquiner le monde.
Et puis de toute façon, de plus en plus de boulangerie ont la machine mange pièce et mange billet qui compte elle même et qui dissuade les braqueurs puisque le personnel n'a plus accès aux espèces.
# Question rhétorique, je suppose ?
Posté par Lenbootil . Évalué à 1 (+1/-0).
La réponse est plutôt évidente pour une banque, non ?
# On initie une pétition européenne ?
Posté par Bristow_69 . Évalué à 10 (+10/-0).
Je plussoie cette dépêche.
De même que wero, le paiement européen, non seulement est sur AWS mais nécessite Google ou Apple.
La rigolade a assez duré, il faut passer à l'action ! Nous pourrions monter une pétition sur le site de la commission européenne, non ?
[^] # Re: On initie une pétition européenne ?
Posté par sebas . Évalué à 7 (+5/-0). Dernière modification le 26 avril 2026 à 20:52.
Toutafé, les faiseurs de loi ne se préoccupent sûrement pas des pétitions sur les sites lambda. Mais par règlement, ils ne peuvent pas ignorer les pétitions sur leur propre site dès qu'elles dépassent 500.000 signatures. Ce qui n'arrivera sûrement pas avec ce genre de demandes nous sommes dans une niche : qui dans vos connaissances n'a pas de spyphone, ou en a un dégooglisé, ou refuse de mettre son appli bancaire dessus ? Moi j'en connais trois, et l'une d'elles est ma femme.
Mais bon, tenter le coup ne coûte rien, on n'est pas à l'abri d'une bonne surprise.
[^] # Re: On initie une pétition européenne ?
Posté par guiohm . Évalué à 5 (+5/-0).
Au départ, je me sentais viser le plus large possible, mais après recherche, il s'avère qu'il est préférable de faire grossir "un noyau dur", ou en l’occurrence de s'occuper d'abord du national avant d'élargir.
Bon je peux me tromper, il y a peut-être des pays européens plus sensibilisés à ce sujet.
Mais la réussite d'une pétition est très liée à la comm' médiatique qui l'accompagne. Donc se rendre visible déjà à quelques plateformes/media français est la première étape je pense.
Même chose pour les pétitions sur le site de l'assemblée nationale. Démarrer direct ici sans appui médiatique est plus difficile.
Ça reste mon avis, je n'ai jamais monté de pétition jusqu'ici.
[^] # Re: On initie une pétition européenne ?
Posté par martoni (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Si j'ai bien compris cette situation est tout simplement illégale non ?
N'y a-t-il pas des actions en justices lancées par des associations ?
J'ai plus qu'une balle
[^] # Re: On initie une pétition européenne ?
Posté par Brice.C . Évalué à 4 (+4/-0). Dernière modification le 29 avril 2026 à 18:50.
Salut,
Tu touches un point intéressant : malgré l'apparente illégalité de tout cela, la smartphonisation continue à marche forcée. C'est pas juste les banques, il y a de plus en plus de pression d'utilisation de toutes parts.
Et non, il n'y a pas de recours juridique pour l'instant.
Je suis de près ces questions de dépendance au smartphone, et j'ai l'impression que sur internet ces sujets sont seulement évoqués sur ce forum et quelques sub reddit. ça en discute dans la vie de tous les jours car ça saoule plein de gens, mais pour l'instant pas de mouvement ni de collectif structuré spécifiquement sur ce sujet.
J'ai lu je ne sais plus où que certains ici en discutaient sur le matrix de la Quadrature du Net. J'y suis allé, et pour l'instant je n'ai trouvé aucune discussion dédiée.
Serait-il possible que les personnes actuellement en train d'écrire les lettres à envoyer au niveau européen me contactent? j'aimerais discuter de tout cela avec elles.
Le filet se resserre tranquillement, et c'est pas en continuant d'utiliser les quelques contournements qui existent encore qu'on va réussir à desserer les mailles. Il faut de l'action collective, et c'est super de voir ce fil avec autant d'interactions sur le sujet.
Merci, et force à vous.
# Google Play Integrity API
Posté par Stephane21 . Évalué à 6 (+7/-1).
Les banques préfèrent que nous utilisions leurs applis mobiles car les OS mobiles (même non mis à jour) sont généralement plus sécurisés que les OS des ordis portables ou ordis de bureau sous Linux/Windows/AppleOS. Par exemple, Boursorama me force a utiliser l'application mobile pour créer une carte bancaire virtuelle. Ce que je pourrais éventuellement accepter si cela en restait là.
Sous Android, le gros problème est que de plus en plus de banques imposent d'avoir un Android certifié Google (AOSP + services invasifs de Google dont le code source est fermé). Ce qui met de coté les téléphones "Android AOSP" du genre LineageOS ou GrapheneOS (AOSP, code ouvert, sans les librairies invasives).
Ces applis bancaires problématiques utilisent l'API "Google Play Integrity" qui est un gros problème de monopole anticoncurrentiel, car elle tendent à nous forcer à utiliser un téléphone Apple ou "Android Google", les OS mobiles concurrents ne peuvent rien faire pour s'aligner, les services clients des applis bancaires ne comprennent pas ce genre de problématique et considèrent à tord que "Google Play Integrity" signifie que le téléphone est sécurisé.
[^] # Re: Google Play Integrity API
Posté par Glandos . Évalué à 6 (+4/-0).
Oui et non, ça dépend du modèle de menace, et de qui le regarde. La banque préfère les OS mobiles, car le vol de données de connexions y est plus difficile.
Par contre, pour l'utilisateur, une application mobile de la banque est bien moins contrôlable, donc la banque exfiltre les données qu'elle veut de la part de l'utilisateur.
[^] # Re: Google Play Integrity API
Posté par Lenbootil . Évalué à 6 (+6/-0). Dernière modification le 27 avril 2026 à 00:40.
C'est ce qu'elle croit, en tout cas.
Pas plus tard que la semaine dernière, j'ai fait remarquer à un collègue que l'adresse IP du ste web qu'il était en train de consulter, celle renvoyée par le serveur DNS de son FAI sur une liaison 4/5G, était une adresse privée, donc celle d'un proxy transparent.
De plus, l'obsolescence logicielle d'un mobile est bien plus rapide que celle d'un micro-ordinateur. Un mobile un peu ancien est très souvent une passoire.
Et enfin, que perd-on le plus facilement, entre un ordiphone et un ordinateur ?
[^] # Re: Google Play Integrity API
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+11/-1). Dernière modification le 28 avril 2026 à 14:44.
Non, la banque préfère les OS mobiles, car :
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Google Play Integrity API
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6 (+3/-0).
Est-ce qu'ils sont tous au sommet de la chaîne vestimentaire ?
[^] # Re: Google Play Integrity API
Posté par Lenbootil . Évalué à 4 (+4/-0).
Tu oublies Jean-Maurice* Trésault, comptable en chef, qui croit dur comme fer qu'un logiciel installé sur les terminaux des clients, ça coûtera toujours moins cher que du matos dédié.
Et il est conforté dans son opinion par Jean-Jostophe Lesclav, le stagiaire ingénieur en alternance, qui pisse gratuitement du code que personne ne saura relire, et aidé en cela par Jean-Claude Groku, la nouvelle intelligence très artificielle mais très rentable de MicroPomme.
Ajoute le pouvoir de nuisance des Jean-Bernard Laxionnère, Jean-Léonard Letrédeur, Jean-Roger Paillasson (de l'autorité des marchés), du Maître-Docteur-Pi-Hache-Di Jean-Anatole Profdécaud (qui sait que les banques sont incontournables dans le monde d'aujourd'hui) et de son assistant Jean-Bruno Leboncense, et tu obtiens un mélange assez instable pour provoquer des réactions que même les physiciens les plus éminents ne savent pas expliquer.
* (pour réduire un peu le poids sur les épaules des Jean-Michel, qu'on embrasse :)
[^] # Re: Google Play Integrity API
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+3/-0). Dernière modification le 27 avril 2026 à 11:39.
Grâce au compromis entre le député Jean et le sénateur Michel, responsables de La Commission Sur Les Prénoms Publics de 2042, tout le monde s’appellera Jean Michel d'ici la fin du siècle.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Google Play Integrity API
Posté par arnaudus . Évalué à 4 (+3/-2).
L'argument est donc que les banques favorisent l'utilisation d'applications smartphone parce que l'intégralité de leur chaine de décision est incompétente.
Ça a l'avantage d'être une explication tellement pratique qu'elle ne nécessite même pas de réflechir.
Bon, maintenant, en vrai, il faut bien avoir en tête que c'est les banques (ou leurs assurances, ce qui revient plus ou moins au même) qui couvrent le coût de la fraude bancaire. Il faut aussi réaliser que les tribunaux, régulièrement, prennent position contre les banques sur la définition de la faute du client. Vous avez là l'ensemble de l'équation : les banques veulent contrôler la totalité de la chaine de sécurité, car si vous pouvez faire une transaction avec une partie de la chaine moins sécurisée que la procédure standard, alors c'est pour la tronche de la banque. Par exemple, si vous avez installé par mégarde un tracker sur votre smartphone dégooglisé et que vous vous êtes fait aspirer votre pin, bah la fraude sera pour la banque (à moins de pouvoir convaincre le tribunal qu'avoir un smartphone dégooglisé est une faute de la part du client, ce qui me semble chaud). Il est donc totallement rationnel de la part de la banque d'interdire toute transaction qui implique n'importe quel matériel ou logiciel non-audité.
Moi je suis super pour la liberté de choisir sa banque en fonction de valeurs ou en fonction des services fournis. Je préfère utiliser l'interface web que l'application par exemple, et si ma banque cessait de fournir une interface web, j'imagine que je pourrais changer. Mais il faut aussi que je sois prêt à payer plus cher pour un service. C'est le principe même du commerce, si je veux une coupe de cheveux, je vais payer plus cher que pour la barbe. Bah là c'est pareil, je veux quelque chose en plus, cette chose a objectivement un coût (équipe de développement, service client, documentation…), et j'ai du mal à comprendre sur quel principe je devrais pouvoir bénéficier d'un service supplémentaire sans raquer derrière si la banque a pris la décision que de me garder parmi leurs clients ne justifiait pas un geste commercial. À ma connaissance, la nature de l'OS utilisé ne fait pas partie des critères de discrimination, et "pouvoir accéder à mes comptes sous Linux" n'est pas un droit garanti par la loi…
[^] # Re: Google Play Integrity API
Posté par Lenbootil . Évalué à 8 (+8/-0).
Dans ce cas, pourquoi la banque ne fournit-elle pas le matériel dûment audité, au lieu de casser les pieds de leurs clients ?
[^] # Re: Google Play Integrity API
Posté par TuxMips . Évalué à 2 (+0/-0).
A mon avis pas besoin !
Cf le lien que j'ai déjà posté dans ce fil : https://forum.sailfishos.org/t/banking-apps-on-sailfish-os/18438
L'application bancaire doit pouvoir être "autonome" des services Google/Apple. Problème faut payer deux ou trois développeurs de plus. En attendant certaines banques arrivent à bien faire quand même les choses (ou à peu près).
[^] # Re: Google Play Integrity API
Posté par arnaudus . Évalué à 0 (+1/-4).
Parce que les clients ne sont pas prêts à payer pour ça? Sans compter que pour la majorité des clients ça serait plutôt considéré comme une galère de devoir utiliser un machin électronique monofonction. Je ne peux qu'imaginer, mais je pense que si tu es dans une grosse banque Suisse et muni d'un compte au solde comportant 6 ou 7 chiffres, tu as tout le matériel que tu veux, y compris un smartphone uniquement dédié à ça, qui sera enfermé dans ton coffre. Si tu veux payer moins de 5€ de frais de tenue de compte par mois, tu vas utiliser du matériel personnel, mais dans les conditions restreintes autorisées par ta banque.
Les libristes sont les premiers à aller donner des leçons à tout le monde sur la manière dont les banques devraient gérer leurs API, genre "si j'étais vous je ferais tout pour satisfaire les clients comme moi". On ne peut pas vivre comme ça, ce monde théorique est infernal. Tu ne peux pas passer ta vie à dire à la maitresse de tes gamins "si j'étais vous je ferais comme ça". Ou à ton plombier "si j'étais vous je mettrais de la graisse de porc plutôt que de la pâte à joint". Ou au cuistot du resto du coin "si j'étais vous je mettrais de l'échalotte plutôt que des oignons". Et ça, c'est indépendant du fait d'avoir raison ou tort.
En tout cas, si j'étais votre banque, je vous enverrais chier, parce que je n'ai pas envie qu'1% de mes clients me bouffe 50% de mon budget de sécurité informatique pour maintenir de multiples interfaces compatibles avec du hardware improbable qui tourne sous Hurd. Si j'étais une banque, ce que je voudrais, c'est des clients pas chiants qui ont tous le même iPhone pour acheter des millions de merdouilles sur Amazon en activant le cashback qui va me permettre de revendre les informations sur les habitudes d'achat, qui vont me rapporter beaucoup plus que les petites miettes des frais de tenue de compte. Et les clients qui veulent un service sur mesure, ils iront voir les banques qui offrent des services sur mesure, et ils verront bien le coût d'un service sur mesure.
[^] # Re: Google Play Integrity API
Posté par devnewton 🍺 (site web personnel) . Évalué à 9 (+6/-0).
Si la maitresse mets la photo de tes gamins en ligne (avec leurs noms & adresses), si ton plombier installe un compteur intelligent (qui revends tes données de consommation) ou si le cuistot te demande de lui mettre un avis 5 étoiles pour avoir droit à une carafe d'eau, j'espère bien que tu vas leur dire si j'étais vous je ferais comme ça et par ça je veux dire ne pas être un gros connard digne d'un banquier qui impose ses applis pourraves sécurisées avec le cul, bourrées de trackers et dark patterns.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Google Play Integrity API
Posté par arnaudus . Évalué à 2 (+2/-3).
Possibilité 1: "Oh pardon, nous tenons absolument à ce que nos clients qui font tourner un LinuxFromScratch sur Raspberry puissent modifier leur plafond de carte bancaire avec un script bash dans leur crontab, nous allons de ce pas modifier notre API et nous vous prions de présider à partir de maintenant notre service international de sécurité informatique qui, nous vous faisons confiance, conçoit la sécurité de nos applications avec leur cul, une faille de sécurité que vous avez d'ailleurs pu détecter sans même installer notre application sur le smartphone que vous n'avez pas, ce qui ne peut que prouver sans aucun doute possible votre sagacité hors du commun."
Possibilité 2: "Suite à votre demande, nous avons activé le contrat "Senior EHPAD noelec" sur votre compte, destiné à nos ainés qui ne sont pas à l'aise avec la validation électronique de leurs transactions. Vous aurez accès à un carnet de chèque par an, un relevé papier tous les deux mois, ainsi qu'à trois virements par trimestres validables par pigeon voyageur, pour seulement 47€99 par quinzaine."
[^] # Re: Google Play Integrity API
Posté par devnewton 🍺 (site web personnel) . Évalué à 7 (+4/-0). Dernière modification le 28 avril 2026 à 15:28.
Possibilité 3 : la France se dote enfin d'une vraie autorité de la concurrence qui envoie une équipe d'intervention spéciale taser les testicules des banquiers qui ne se mettent pas en conformité avec les obligations sur l’interopérabilité, l'accessibilité et la concurrence libre et non faussé (tiens reprends un coup de 10000 volts pour t'apprendre les vertus du libre marché et le respect de la clientèle).
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Google Play Integrity API
Posté par arnaudus . Évalué à 8 (+5/-0).
C'est sûr qu'avec cette possibilité ça va booster la carrière des femmes dans les DSI des banques.
[^] # Re: Google Play Integrity API
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Alors que c'est une évidente suggestion tout à fait censée !
[^] # Re: Google Play Integrity API
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
Bof, l'échalote c'est juste de l'oignon de petite taille.
[^] # Re: Google Play Integrity API
Posté par antistress (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 30 avril 2026 à 12:38.
C'est pas la même chose. La preuve, on dirait "mêle toi de tes échalotes" sinon (ou "faire la course à l'oignon")
# J'ai signé, mais…
Posté par Johnny Begood . Évalué à 10 (+11/-0).
…suis-je le seul a ne pas aimer
change.orget leur façon d'être……… insistants ?[^] # Re: J'ai signé, mais…
Posté par guiohm . Évalué à 3 (+3/-0). Dernière modification le 26 avril 2026 à 20:39.
Non. Habituellement, je signe une pétition puis je me désinscrit de leur liste de diffusion dès leur premier mail.
Mais c'est justement ce qui en fait un bon choix pour faire connaître le problème. Le site de pétition de l'assemblée ne va pas aider à diffuser.
Personnellement j'ai signé beaucoup plus de pétitions sur change.org qu'ailleurs.
D'où mon choix de plateforme "grand public" pour "sonder" l'intérêt général, car je ne me rends pas compte à quel point la population a conscience de ce problème, et le but est plus de sensibiliser que de viser une action légale tout de suite.
# Inadmissible
Posté par JC (site web personnel) . Évalué à 7 (+7/-0).
Bonjour,
J’ai signé cette pétition parceque je me sens concerné : je suis en train de quitter ma banque (MonaBank) parceque maintenant ils obligent de passer par leur App pour valider certaines opérations: virement…
Il paraît que le SMS n’est pas assez sécurisé comme 2FA !
Ils préfèrent que j’installe leur App sur un tel Android ou iOS!
Et impossible de gruger en installant l’App sur une image AOSP: l’App ne s’installe pas : pas un Android officiel que ça dit !
J’ai trouvé un vieux tel Android dans un tiroir qui fait l’affaire en attendant mais j’ai décidé de sauter le pas: changer de banque.
Et encore j’ai de la chance paraît-il parcequ’il semble que parfois sur certaines banque l’App vérifie qu’il s’agit bien du tel qui porte la ligne téléphonique déclaré à la banque.
Bientôt il faudra avoir une 2ème ligne tel pour pouvoir valider une opération !
Je trouve ça inadmissible.
Donc il faut réagir.
# AOSP
Posté par TuxMips . Évalué à 6 (+4/-0).
Mon smartphone est sous Sailfish OS (avec la licence payante). Je bénéficie du AppSupport, c'est à dire un Android aosp qui tourne dans un container.
Cet Android aosp n'a pas Google Play ni Google Store. J'ai fatalement des applications Android. Je privilégie toujours les applications natives, puis ensuite les applications en provenance de Fdroid et enfin Aurora Store.
Avant d'installer une application, mon réflexe est de vérifier l'application sur Exodus Privacy.
Alors oui l'application de ma banque est installée. Elle fonctionne parfaitement dans mon environnement (pas testé Wero). Son grand défaut : les pisteurs. Mais elle est fonctionnelle sans avoir installé microG.
La communauté des utilisateurs de Sailfish OS a ouvert un fil sur le sujet.
Je pense que cela devrait aider.
# Betteridge a dit non
Posté par xryl669 . Évalué à 6 (+5/-0).
Suivant la loi de Betteridge la réponse est non.
Et pour Boursobank, je confirme que j'ai une validation par SMS sans application liberticide sur mon téléphone Android. Lorsque j'ai changé de téléphone, la version d'Android plus récente (16 au lieu de 8), fait que l'application ne voulait plus fonctionner sur mon téléphone rooté (et sans Google sévices).
Résultat, j'ai appelé le service client, j'ai donné les messages que l'application retournait (messages bidons du style: Il semble y avoir un problème de compatibilité sur votre appareil), ils m'ont posés toutes les questions de sécurités habituelles (quelle était la couleur de poils de votre chat préféré dans les Aristochats, et tout le toutim). Bref, ça a duré 20mn où j'ai fait le guignol en répétant que ça m’embêtait drôlement de ne plus pouvoir utiliser cette banque magnifique mais que, vu que je ne peux plus rien faire chez eux à défaut d'appli mobile qui fonctionne, …
Au final, il y a eu un transfert vers un autre service qui m'a rebeloté sur les questions de sécurité puis qui m'a désactivé leur 2FA basée sur l'application. Au final, j'ai une validation par SMS et clé TOTP gérée par Bitwarden, et ça me va très bien. Comme quoi, il faut résister et les saouler, c'est beau 2026…
[^] # Re: Betteridge a dit non
Posté par nud . Évalué à 7 (+5/-0).
En Belgique ça fait 20 ans qu'on a des digipass et ça marche toujours. Les modèles "récents" (disons d'il y a moins de 10 ans) permettent d'insérer directement la carte pour générer un TOTP pas standard pour s'identifier sur le site web de la banque ou pour signer les transactions. D'ailleurs même quand on fait des paiements via l'application mobile, il faut parfois (en fonction du montant ou du fait que le bénéficiaire soit nouveau) valider le virement via digipass.
Je ne vois pas bien pourquoi une quelconque raison technique ou légale empêcherait de continuer à le faire, et, de ce fait, je ne vois aucune raison pour qu'on ne le fasse pas aussi en France?
[^] # Re: Betteridge a dit non
Posté par ... a little wood elfe . Évalué à 2 (+1/-0).
Cela se fait aussi en France, je ne possède pas de smartphone et pour valider une opération sensible sur le site de ma banque j'utilise un petit lecteur de carte bleu (dont il va bientôt falloir que je change la pile d'ailleurs).
Bon en réalité ça sécurise plus la banque que moi car quand il m'arrive de ne pas l'avoir sur moi la banque propose (proposait ? ça ne m'est pas arrivé depuis longtemps) l'envoi d'un code par SMS…
[^] # Re: Betteridge a dit non
Posté par nud . Évalué à 3 (+1/-0).
Bah ici à ma connaissance pour toutes les banques "classiques" tu dois avoir le digipass (ou sa version "app") pour te connecter. Je n'ai jamais vu de banque où on pouvait se connecter avec un mot de passe seul ou avec un code SMS. C'est dommage parce que ça aurait été pratique pour scripter le budget mensuel mais bon ¯\_(ツ)_/¯
Par classiques je veux dire qu'il y a sans doute une néobanque ou l'autre qui fait n'importe quoi.
[^] # Re: Betteridge a dit non
Posté par xryl669 . Évalué à 2 (+1/-0). Dernière modification le 28 avril 2026 à 10:45.
Aucune de mes banques "à guichet physique" ne propose ce que tu décris. Elles m'envoient toute un SMS pour le 2FA.
[^] # Re: Betteridge a dit non
Posté par floriang . Évalué à 2 (+1/-0).
Ça se fait encore parfois en France, mais c'est "démodé", pas assez moderne, selon les banques elles-mêmes et certainement certains clients bruyants…
# Il existe des trucs
Posté par Marc (site web personnel) . Évalué à 3 (+2/-0).
La SoGé ne propose rien, les échanges étaient assez drôles, mais le TLDR c'était "installez l'appli".
Certaines banque (CIC au moins) proposent un boîtier payant pour valider.
J'ai découvert Wise, qui permet de faire le 2FA via TOTP ou fido2.
La validation d'un achat se fait dans son espace web:
- on achète un truc, le vendeur "attend la validation"
- on va dans son espace web
- la transaction est listée: quel vendeur, la sommes à payer (ça respecte la directive qui impose que la validation doit être explicite sur qui/combien).
- on valide
- ça débloque l'attente dans le tab côté vendeur
Pas d'appli, pas de SMS (voués à disparaître).
[^] # Re: Il existe des trucs
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
Si le second facteur est basé sur du TOTP, même pas besoin de boîtier dédié en fait. N'importe quel téléphone ou ordinateur peut faire l'affaire.
[^] # Re: Il existe des trucs
Posté par Marc (site web personnel) . Évalué à 2 (+1/-0).
Pour wise, c'est le cas, pas besoin de grand chose à part un ordinateur et un navigateur web.
Pour les autres banques qui proposent un boîtier (genre CIC et digipass: https://www.cic.fr/fr/particuliers/comptes/authentification-forte-digipass.html) par contre, ils utilisent un truc à base de qrcode de couleur qu'il faut scanner… Bref, c'est joli l'effort de proposer une alternative à un smartphone avec Google Android ou Apple iOS, mais c'est pas encore ça.
[^] # Re: Il existe des trucs
Posté par antistress (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 27 avril 2026 à 16:59.
La SocGen, justement, m'ennuie.
Le virement instantané (et le relevage des plafonds de virement) sont décrétés réservés à l'appli.
Rien de tel sur la Caisse d'Épargne à ce jour.
Je vais commencer par écrire à mon conseiller SocGen ?
(pétition signée, merci)
[^] # Re: Il existe des trucs
Posté par Ysabeau 🧶 (courriel, site web personnel, Mastodon) . Évalué à 5 (+2/-0).
Je vais fermer mon compte !
Je n’ai aucun avis sur systemd
[^] # Re: Il existe des trucs
Posté par xryl669 . Évalué à 4 (+3/-0).
Moi aussi ça m'ennuie, je vais fermer ton compte.
[^] # Re: Il existe des trucs
Posté par Marc (site web personnel) . Évalué à 3 (+2/-0).
C'était mon point de départ aussi… Je voulais rembourser qq1 pas en France, mais en Europe (Belgique). Impossible d'ajouter le compte sans l'appli. Au guichet, on me dit que c'est pas possible de faire le virement "mais que je peux quand même remplir le formulaire, mais ça sera sans doute rejeté".
J'ai pu ajouté un compte pour ensuite virer dessus depuis l'iface web.
Après plusieurs échanges avec directrice de l'agence, la conclusion était assez rigolote. Ça bouclait sur "oui vous pouvez… avec l'appli" "ok mais je n'ai pas d'appli" "alors il faut utiliser une des méthodes d'auth disponible" "ok, c'est à dire" "l'appli"
Quand je demande comment ils gèrent la directive qui suggère des solution alternative… Ben pas vraiment de réponse.
J'ai rendu ma CB, je garde la gestion des compte en lignes, et pour le reste, je suis passé chez Wise.
Bon courage. C'est bien de leur dire que ça ne convient pas, mais en l'état cherche quand même un plan B :D
# obligation d'alternative et actions possibles
Posté par FilG . Évalué à 5 (+5/-0). Dernière modification le 27 avril 2026 à 15:45.
Bonjour,
ça pose pas mal de question.
Pour répondre à l'« obligation » de mettre à dispo une alternative à l'appli, le sujet est précisé ici : https://wiki.april.org/w/Atelier-directive-dsp2#Ce_que_disent_les_textes
Sur la même page a été dressée une liste des conditions d'accès aux comptes en ligne par les banques sur cette liste collaborative suivie de proposition d'actions à court terme ici pour les personnes qui se sentent concernées.
Une proposition plus à moyen terme est aussi proposée dans cette section.
Je comprend qu'une pétition sur mobilizon aurait eu plus de public mais les personnes qui ne souhaiteraient pas signer sur change.org pourront trouver dans le wiki plus haut des idées d'actions simples, ou plus ambitieuses selon leur motivation.
# Rassurez-vous sur la sécurité bancaire : le code des cartes de paiement va être supprimé
Posté par Ysabeau 🧶 (courriel, site web personnel, Mastodon) . Évalué à 7 (+4/-0). Dernière modification le 27 avril 2026 à 17:35.
Ce code sera remplacé par un système biométrique : les cartes à empreintes digitales remplacent les cartes à code numérique. Parce que c'est beaucoup plus sûr, selon les banques.
Il est vrai qu'on ne laisse pas traîner ses empreintes digitales partout et qu'on peut les modifier comme on veut, et évidemment, on ne se coupe jamais les doigts.
Je n’ai aucun avis sur systemd
[^] # Re: Rassurez-vous sur la sécurité bancaire : le code des cartes de paiement va être supprimé
Posté par Maderios . Évalué à 3 (+1/-0).
On est prévenu:
[^] # Re: Rassurez-vous sur la sécurité bancaire : le code des cartes de paiement va être supprimé
Posté par vpo . Évalué à 3 (+2/-0).
Meuh non. Comme nous avons des cadors de la cyber-sécurité pour sécuriser les données personnelles des français comme le démontre la récente fuite des données personnelles chez France Titres, ex-ANTS, nous ne risquons rien.
Moi qui avais une adresse mail dédiée pour banque/administration/sécu, adresse communiqué à personne d'autre, j'ai fait une erreur de débutant : considérer que ces gens là auraient des systèmes sécurisés !
J'aurais dû créer des adresses mails par service avec des triplets de lettres faciles à retenir mais sans rapport avec mon identité. Ca évitera aussi les emmerdeurs qui spamment tous les couples possibles parmi (nom, prénoms, initiales).
[^] # Re: Rassurez-vous sur la sécurité bancaire : le code des cartes de paiement va être supprimé
Posté par Faya . Évalué à 3 (+1/-0).
Apparemment les journaux qui titrent en ce sens s'avancent beaucoup. Le code n'est pas censé disparaître :
«Le narratif "fin du code à quatre chiffres" est faux : quasi toutes les implémentations gardent un fallback PIN pour les cas où le capteur foire ou pour les retraits au DAB, ce qui signifie que le maillon faible du PIN persiste en option.» Et le capteur sur la carte n'est pas très performant (moins que ceux des smartphones) donc au final ça rajoute surtout un vecteur d'attaque.
[^] # Re: Rassurez-vous sur la sécurité bancaire : le code des cartes de paiement va être supprimé
Posté par Ysabeau 🧶 (courriel, site web personnel, Mastodon) . Évalué à 3 (+0/-0).
C'est censé rajouter une touche de sécurité, pas fragiliser le système !
Je n’ai aucun avis sur systemd
[^] # Re: Rassurez-vous sur la sécurité bancaire : le code des cartes de paiement va être supprimé
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Il est vrai surtout que tout est bon pour justifier la collecte de données biométriques. Et comme fatalement il y aura de la fuite et qu’on ne sait pas changer ce type de données, bah les usurpations d’identités vont être une joyeuseté boostée par IA les prochaines années.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# La pétition ne mentionne pas les bonnes alternatives
Posté par HG203 . Évalué à 3 (+3/-1).
L'utilisation des SMS est fortement déconseillé car :
Le protocole SS7 et complètement troué (voir les explication détaillés sur https://korben.info/first-wap-surveillance-protocole-ss7.html);
il faut quand avoir un smartphone et du réseau.
Les cartes de codes (cartes TAN) se photocopient et peuvent se transmettre comme les mots de passe.
Les TOTP peuvent être admis à la rigueur, car les utilisateurs ne savent pas forcément extraire le secret (bien que cela est possible);
Il ne reste donc que les boîtiers pour cartes à puce (les cartes bancaires) et les clés FIDO qui peuvent fonctionner avec n'importe quel OS, navigateurs, ordinateurs et smartphone.
C'est donc ces dispositifs qu'il faut imposer explicitement car les banquiers ne sont absolument pas au courant de ces solutions qui existent depuis plusieurs dizaines d'années.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par xryl669 . Évalué à 1 (+1/-1).
Comment extrait tu le secret d'un TOTP en ayant seulement les codes générés?
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par HG203 . Évalué à 2 (+1/-0).
La plus part ont une option qui permet de partager le QRcode contenant le secret. D'autre permettent aussi d'exporter la base des secrets pour pouvoir changer gestionnaire de TOTP.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par xryl669 . Évalué à 2 (+1/-0).
Donc… il n'y a pas de faille de sécurité.
C'est même mieux que le boîtier RSA classique qui a une pile et qui perd sa RTC lorsqu'elle faiblit et dont on ne peut pas extraire la graine. Au moins avec ton TOTP sur Bitwarden, tu ne tombe pas en rade à 2h du mat lorsque tu es en panne sur l'autoroute, parce que cette satanée pile vient juste de te lâcher et qu'il faut payer le dépanneur "par chèque ou par virement".
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5 (+2/-0).
C'est compliqué. Apparemment, le fait qu'on agresseur puisse te forcer à lui donner le secret de génération de TOTP est considéré comme un problème plus grand que le fait qu'il puisse te forcer à lui remettre ton boîtier TOTP.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par arnaudus . Évalué à 3 (+2/-2).
Sur une échelle de 10-20 à 10-6, quelle est la probabilité que cette proposition soit vraie?
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Ysabeau 🧶 (courriel, site web personnel, Mastodon) . Évalué à 5 (+2/-0).
Ben quand on voit qu’il est question de remplacer (ou tout au moins de les ajouter comme moyen d’identification) les codes pin des cartes de paiement par des empreintes digitales parce que « c’est plus sûr », la probabilité peut être évaluée à environ 99,9%.
Je n’ai aucun avis sur systemd
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par arnaudus . Évalué à 1 (+0/-2).
Le sarcasme n'est pas un argument. Tu as des sources sérieuses qui pourraient confirmer que les empreintes digitales sont moins sûres qu'un code pin à 4 chiffres?
Par exemple, j'ai trouvé une page du service de sécurité informatique du CERN (https://home.cern/fr/news/news/computing/computer-security-swipes-vs-pins-vs-passwords-vs-you) qui classe la sécurité dans l'ordre motif < code < empreintes < scan visage.
On parle de l'efficacité relative entre plusieurs systèmes. Quelle que soit l'efficacité absolue de l'identification par empreintes, la question est de savoir si elle est plus grande de l'identification par pin de 4 chiffres.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Ysabeau 🧶 (courriel, site web personnel, Mastodon) . Évalué à 5 (+2/-0).
Voir commentaire plus haut.
Et comme tu es superbement intelligent, tu vas m'expliquer comment faire pour ne pas laisser ses empreintes partout, les changer quand la base de données qui les recueille est trouée ou encore modifier le bousin quand tu t'es coupé le doigt en faisant la vaisselle.
Je n’ai aucun avis sur systemd
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par arnaudus . Évalué à 2 (+0/-1). Dernière modification le 28 avril 2026 à 15:29.
Tu as écris un truc factuel : tu as clairement dit que l'identification par PIN était plus sûre que l'identification par empreintes, et je n'ai trouvé aucun document qui pourrait aller dans ce sens. Au contraire, j'ai trouvé des documents qui prétendaient le contraire, dont ce fameux document issu du CERN, qui sont confrontés à des problèmes de sécurité informatique assez substantiels, et qui ne sont donc pas à priori des bouffons.
En sécurité, on peut raconter n'importe quoi si on confond le risque réel, le risque potentiel, le danger, les estimations théoriques et les risques en pratique, etc. Pour le cas concret des cartes de payement, tu as tout un tas de facteurs logistiques, économiques, commerciaux, et réglementaires à prendre en compte, et je ne comprends pas comment tu peux évaluer comme ça les rapports coûts/bénéfices des trois options possibles (PIN tout seul, empreintes toutes seules, ou les deux combinés).
Je me demande du coup sur quel genre de site on est. Est-ce que l'objectif c'est de faire une sorte de catharsis collective pour conjurer un traumatisme d'entretiens d'embauches dans la DSI des banques qui se sont mal passés, ou est-ce qu'on essaye de comprendre la logique de sécurisation des moyens de payement?
Si c'est le premier, alors: C'tous des bouffons les banquiers, genre ils se renseignent même pas sur Linuxfr avant de demander à ChatGPT de coder leur appli..
Si c'est la deuxième, je me permettrais de remettre en question la vraisemblance d'un scénario où quelqu'un achète tes empreintes sur le dark web, te retrouve, imprime un faux doigt avec tes empreintes, te suive, te pique ta carte, et utilise le faux doigt pour valider les achats. Je ferais aussi remarquer que des doigts on en a plusieurs.
Ceci par contre ne tient pas pour la carte d'identité, pour laquelle on numérise tous ses doigts (seulement ceux de la main droite de mémoire), et surtout où on peut imaginer des sources de motivation un peu plus crédibles que de tirer 80€ avant que la carte soit mise en opposition.
Dans tous les cas, comme les fraudes au moyen de payement sont prises en charge par les banques, je ne vois pas tellement la raison pour laquelle elles développeraient un système qui est par nature troué. Elles ont très probablement étudié la question et en ont probablement conclu que les trous du nouveau système étaient moins problématique que ceux de l'ancien.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Ysabeau 🧶 (courriel, site web personnel, Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 28 avril 2026 à 15:54.
Je n'ai pas écrit écrit que le code PIN était plus sûr, seulement que le système des empreintes digitales ne l'étaient pas dans ce contexte, et d'autres ont signalé que ça rajoutait un angle d'attaque, etc. Il serait bon de lire les commentaires sur le sujet et de répondre à ma question. Le code PIN je le cache quand je le saisis, mes empreintes digitales je ne vois pas comment faire pour ne pas en mettre partout, je ne vois pas comment les remplacer, etc.
Il n'est pire sourd que celui qui ne veut pas entendre.
Je n’ai aucun avis sur systemd
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par arnaudus . Évalué à 1 (+0/-2).
"quand on voit qu’il est question de remplacer (ou tout au moins de les ajouter comme moyen d’identification) les codes pin des cartes de paiement par des empreintes digitales parce que « c’est plus sûr »"
Je ne vois pas moyen d'interpréter ça autrement que "les empreintes sont moins sûres".
Quoi qu'il en soit, j'ai du mal à concevoir comment on pourrait t'obliger à donner tes empreintes, donc si tu ne veux pas tu ne fais pas.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Ysabeau 🧶 (courriel, site web personnel, Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 28 avril 2026 à 16:38.
Et bien ton interprétation est biaisée. Et je vois que tu t'en tires pas une pirouette, qui ne répond donc pas fondamentalement pas à la question.
Je n’ai aucun avis sur systemd
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Faya . Évalué à 6 (+4/-0). Dernière modification le 28 avril 2026 à 17:49.
Ah bin justement, ça fait partie des trucs qu'un attaquant peut t'obliger à donner (Oui je sais que tu parlais de l'obligation par les banques) : « un code PIN, si on vous menace devant un DAB, vous pouvez théoriquement saisir un faux code (certaines cartes ont même une notion de " code sous contrainte " qui bloque la carte directement). Alors qu'avec un doigt, on vous chope la main et force et voilà… » Après il faut voir que la sécurité des empreintes dépend beaucoup de la qualité du lecteur d'empreinte, et (toujours d'après le lien plus haut) ceux prévus pour les CB seraient un cran en-dessous de ceux qu'on trouve sur les smartphone. Or ton article du CERN parle des capteurs pour smartphone. J'ai vu de mes propres yeux quelqu'un déverrouiller le smartphone d'une autre personne en lui prenant le doigt pendant qu'elle dormait… Ça n'était que pour lui faire une blague innocente mais bon, le mot de passe attaché à ton corps, visible par tout le monde, que tu ne peux jamais changer si compromis, j'ai vraiment du mal à trouver ça plus sécurisé qu'un truc dans ma tête accessible par moi seul. Mais tout dépend du modèle de menace : xkcd de rigueur.
Bon au-delà de ça je suis d'accord avec toi, je doute que les banquiers (ou du moins leurs services techniques) ne soient pas au courant de toutes ces autres technologies qui existent et qu'ils ne font qu'un calcul de coût/praticité.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par arnaudus . Évalué à -1 (+0/-4).
C'est leur métier. Le responsable de ce bordel receuille les avis des actionnaires, les avis du service marketting, peut-être même les remontées des agences, les retours du service client, le rapport des juristes, les évaluations des services de gestion, les assurances, et … l'avis des responsables sécurité. Il prend tout ça, et ça fait des chocapics. Peu de chance que les chocapics correspondent seulement aux contraintes de sécurité.
On peut tomber d'accord sur le fait que quelques geeks libristes sans grande expérience du secteur bancaire n'auraient pas pris les mêmes décisions que les banques. Ça, pas de problème. On peut discuter de pourquoi. Je ne sais pas pourquoi, donc je trouve ça intéressant. Je trouverais intéressant par exemple de comprendre dans quelle mesure la sécurité théorique de ces dispositifs diffèrent de la sécurité en pratique, etc (bon, j'ai quand même ma petite idée, parce que les histoires de modèles de visage à l'imprimante 3d etc, ça ne va pas vraiment impressionner les assurances :-) ). Mais ce qui me fait réagir, c'est l'explication "c'est tous des bouffons", parce que s'il fallait choisir comme ça à froid entre les deux, il semble bien plus vraisemblable que les bouffons sont ceux qui parlent de ce qu'ils ne connaissent pas.
Pour le côté "on peut te forcer à tirer de l'argent", une application concrête de l'analyse d'image pourrait de refuser de distribuer de l'argent quand plusieurs personnes sont devant le distributeur. Bien sûr, on peut te menacer avec une arme à feu à distance ou prendre ton chihuahua en otage, mais concrêtement ça éviterait quand même une partie des retraits d'argent avec contrainte (et notamment le coup de l'empreinte digitale).
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par HG203 . Évalué à 7 (+6/-0).
Les empreintes digitales ne sont pas un moyen d'authentification mais d'identification (en gros le login et pas le mot de passe).
De plus le CCC a présenté une attaque par clonage d'empreinte en 2013 (https://www.ccc.de/en/updates/2013/ccc-breaks-apple-touchid)
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0).
S'ils lisaient linuxfr, on aurait du webauthn pour se connecter à son espace client et y valider les paiements (avec tout le contexte qui va bien).
Horrible.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par xryl669 . Évalué à 3 (+2/-0).
Celui qui classe le scan de visage comme plus fiable que le scan d'empreinte est un idiot. À la limite le scan du fond de la rétine oui (oui, je sais, techniquement, la rétine est dans le visage… gnarf).
Vu que tu peux pas mapper ton visage en 2D (comme le fait ton empreinte lorsque tu presses ton doigt sur un plan), il sera toujours possible de faire un modèle générique d'un visage et d'y projeter ta texture de face pour tromper le logiciel. Dit autrement, n'importe qui avec un appareil photo peut capturer ta texture de face en 2s sans que tu t'en aperçoives (et comme, justement, les appareils qui ont la fonction FaceID font l'enrollement de ton visage, tu peux détourner cet enrollement pour capturer le visage de ton voisin tout pareil).
Le FaceID, c'est pratique, mais c'est clairement moins fiable que les empreintes digitales (mais plus pratique, c'est certain).
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par HG203 . Évalué à 5 (+4/-0).
Le 2FA avec les clé FIDO existe depuis au moins 15 ans avec une interface normalisée et est supporté par tous les navigateurs. Notamment la plus part des sites US (PAYPAL, etc.) le propose alors qu'aucune banque française ne le propose. Elles n'ont que des solutions propriètaires.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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: La pétition ne mentionne pas les bonnes alternatives
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6 (+3/-0).
… mais le deviennent dès qu'on couple ça avec le fait d'aller entrer le code sur une page Web … qui affiche les informations de contexte.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5 (+2/-0).
C'est censé bloquer quel scénario d'attaque au juste ?
Bon sinon, il y a toujours une alternative en fait : validation non pas par l'appli bancaire installé sur le téléphone, mais pas le site Web de la banque consultable sur le téléphone ou l'ordinateur. 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 ?
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Pol' uX (site web personnel) . Évalué à 2 (+0/-0).
Comment tu valides la connexion à l'espace en ligne ?
Adhérer à l'April, ça vous tente ?
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3 (+0/-0).
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.
Bon, et dans la mesure où la connexion en question a pour seul but de valider une transaction en fournissant justement un TOTP, on peut envisager un mode de connexion limité, avec mot de passe seul, ne permettant que la validation d'un paiement, qui elle demandera un TOTP.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Marc (site web personnel) . Évalué à 1 (+0/-0).
C'est exactement ce que fait Wise si je comprend ce que tu dis.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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) . É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) . Évalué à 1 (+2/-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 devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0).
C'est débile ton histoire : quand tu lances une application Android, tu n'as pas plus de garantie que c'est LA bonne.
Un margoulin peut avoir fait une appli qui ressemble. Ton téléphone peut avoir été compromis. Et d'ailleurs il l'est déjà puisqu'il est sous contrôle de Google/Apple/Huawei/[insérer ici une société de non confiance agissant dans le domaine des smartphones].
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.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . Évalué à 0 (+2/-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 devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0).
Je ne sais pas trop pourquoi tu veux rester accrocher à cette fameuse obligation obligatoirement obligatoire :
Ils ont tous tort et tu es le seul à avoir raison ?
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . Évalué à 1 (+1/-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 devnewton 🍺 (site web personnel) . Évalué à 2 (+0/-1).
Soit tu as raison et les bonnes banques ont bien raison de prioriser la sécurité de leur client sur le respect de la réglementation pondue par des débiles.
Soit tu as tort et les bonnes banques ont bien raison de prioriser la sécurité de leur client sur le respect des interprétations de la réglementation pondues par des débiles.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0). Dernière modification le 01 mai 2026 à 08:25.
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.
Il y a la même tendance dans le cloud avec les partisans du trusted computing (qui est une facon de justifier l'envoi de nos données et services essentiels sur Azure et AWS).
Même si des acteurs européens faisaient de même, ce serait encore mauvais puisque la prise de contrôle des terminaux des utilisateurs est une façon de leur imposer des applis privatrices donc avec une sécurité par obscurité, modele qui a montré son inefficience.
La sécurité sans liberté, ça n'existe pas.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . Évalué à 0 (+1/-2). 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 fearan . Évalué à 5 (+2/-0).
Tu peux faire une extension qui s'assure que tous les paramètres sont 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
Ah oui et elle peut avoir été remplacée par une en tout point identique.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 fearan . Évalué à 7 (+4/-0).
Et tu remarqueras que malgré tout y'en a qui arrivent a court-circuiter play integrity.
ç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.
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.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par mahikeulbody . Évalué à 1 (+0/-1).
Ça représente combien de % des usagers ? 0,001% ? J'imagine que pour une banque, Play Integrity fait le taff malgré ce potentiel minuscule trou dans la raquette.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par fearan . Évalué à 6 (+3/-0).
Non ça veut dire que si Machin arrive a tromper Play integrity, le pirate, il le peut aussi.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
Les libristes sont minoritaires, tout comme les handicapés, les non francophones, les gens qui ne veulent pas financer l'industrie de l'armement…
Les banques ne devraient servir que les gens "normaux" ?
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 03 mai 2026 à 19:11.
Si un cas particulier minoritaire est légitime, on peut l'imposer par la Loi ou la mobilisation.
Si la Loi est nulle, il faut la changer. Ce qui peut se faire en ne l'appliquant pas, en trainant des pieds, en la contournant…
Le secteur bancaire est très fort pour défendre les minorités contre les lois même quand c'est illegitime (les riches contre la fiscalité par exemple).
Donc pas la peine de continuer en boucle à dire qu'on y peut rien.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par mahikeulbody . Évalué à 4 (+2/-0).
Ce n'est pas du tout ce que je comprends du discours d'Aeris. Moi je comprends qu'il n'y a rien à attendre des banques sur ce sujet ; principalement à cause de la législation, et aussi parce qu'elles ne trouvent pas d'intérêt à se mobiliser auprès des instances de régulation pour changer les règles en vigueur en faveur de ceux qui réclament (à juste titre) une solution sans smartphone imposé.
C'est donc à nous, usagers, de pousser pour que le législateur change les règles.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
Tu veux que des libristes montent eux mêmes une infrastructure pour faire tourner des applis privatrices hostiles sur leurs machines (c'est tout le but du trusted computing) ?
Tu es en train d'expliquer que pour se libérer du féodalisme, les serfs doivent désigner parmi eux des contrôleurs travaillant gratuitement pour vérifier qu'ils ne quittent pas les terres du seigneur ?
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 fearan . Évalué à 5 (+2/-0).
Non le coût montera parce qu'ils auront un point de vente dessus, cf moneo où c'était plus rentable pour eux que les gens utilisent (même gratuitement), et ils ont voulu faire payer a tous les étages.
Une solution libre fait en coopération avec d'autre banque permet de déléguer une partie du dev et donc de réduire son coût.
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.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 Renault (site web personnel) . Évalué à 5 (+2/-0).
On notera qu'ils utilisent dans ces paragraphes du conditionnel (can / could), cela ne semble pas être une obligation légale. Plus une recommandation.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
Données != traitements.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
C'est sur l'on boarding, la vérification d'identité, le KYC… Quel est le rapport avec le paiement ?
Je reste convaincu que tu surinterprètes des textes non contraignants. Un peu comme le RSSI qui indique qu'il faut une identité numérique niveau substantielle et un paiement validé par la direction pour utiliser la machine à café de l'entreprise.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
La DSP2 interdit le rootage d'Android ? Dans quel paragraphe ?
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0).
C'est ça ?
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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) . É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) . É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 devnewton 🍺 (site web personnel) . Évalué à 4 (+2/-1).
Merci, mais du coup :
Donc DSP2 == no rooted Android est bien une interprétation plutôt capillotractée :-)
Par contre la DSP2 précise bien qu'il faut protéger la confidentialité des paiements. Hors un Android normal non rooté est sous contrôle de Google, un acteur hostile et intrusif => d'aucun pourrait interpréter ça comme la DSP2 interdit l'usage de téléphone non rooté / non dégooglisé :-)
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 devnewton 🍺 (site web personnel) . Évalué à 5 (+3/-1).
C'est du droit tellement souple qu'il tort la sécurité.
Une banque qui confie la sécurité à Google se rends coupable de trahison. Et ça c'est pas dur à comprendre.
La CNIL et l'ANSSI sont bien sûr criticables.
Et il vaut mieux être dur avec elles que de les laisser faire preuve de souplesse avec notre sécurité individuelle et nationale.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 fearan . Évalué à 6 (+3/-0).
Ça dépends, si tu travail pour la CPI, c'est le risque de ne plus avoir de téléphone du tout.
Mon téléphone n'avait plus de mise à jour depuis plus de 2 ans quand je me suis décidé à déverrouiller le boot loader, et installer un ROM altérative, elle à jour coté sécurité. Va tu prétendre que je suis moins sécurisé maintenant?
Et pourtant le Safety Net ne mouftait pas.
Non ce n'est pas des solutions, sinon le Safety Net aurait dit que mon téléphone n'était pas sécurisé.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par mahikeulbody . Évalué à 2 (+2/-2).
C'est un débat où je n'ai aucune expertise mais il me semble que tu mélanges deux types de sécurité : celle apportée par un OS à jour (mais qui ne garantit en rien que l'appli que tu exécutes n'est pas une copie falsifiée de celle que la banque attend) et celle apportée par les mécanismes de vérification que l'appli est bien celle qu'elle prétend être. Du coup, le problème que tu soulèves - la non mise à jour des systèmes après quelques années - n'est pas un problème intrinsèque à Android ou Google et n'a rien à voir avec la discussion en cours.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par fearan . Évalué à 5 (+2/-0).
Mais c'est exactement ça le problème; un système vérolé qui passe le safety net ne te garantie en aucune façon que l'appli est la bonne, que y'a pas un truc qui lit ton écran sans que tu le sache ou qui fait valider une application et de fait exécuter une autre.
Tu peux même avoir l'appli officielle qui fonctionne dans un render séparé pour tout passer, et avoir la fausse qui s'affiche et le swap des render au bon moment.
Ton safety net doit s'assurer que ton device est à jour (bon un système troué pourra prétendre l'être)
Une solution est d'avoir des clé révocable dans la puce trust store du téléphone qui est effacée en cas de débloquage du boot loader, et qui sont révoqués lorsque le fabriquant décide d'arrêter de faire les mises à jour du téléphone.
Et espérer que les clés valides ne s'échappent pas d'un truststore, car à partir de ce moment là tous les devices troué pourront passer avec cette clé (que tu peux pas révoquer sans invalider des téléphones valides)
La sécurité du système est indissociable de l'intégrité de l'application. Et prétendre le contraire c'est être passé à coté d'un pan entier de la sécurité. Tu peux blinder la porte, la serrure, faire valider ta serrure, si le mur a coté est en papier, ta porte n'a qu'un intérêt cosmétique.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 fearan . Évalué à 3 (+0/-0).
Mais justement si ton OS est troué, il ne peux rien garantir, il va 'juste' croire que c'est bon.
Ben c'est un peu le soucis si ton Safety Net valide un OS troué, tu ne peux pas garantir que l'appli exécuté est celle testé par Safety net, et le téléphone peut très bien prétendre être plus récent.
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?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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) . É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 devnewton 🍺 (site web personnel) . Évalué à 2 (+0/-1). Dernière modification le 05 mai 2026 à 15:19.
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 ?
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 fearan . Évalué à 5 (+2/-0).
Oui, tout comme celui de devoir fournir gratuitement aux clients un système alternatif.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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) . É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 devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0).
La CSS de linuxfr étant toute pétée par ce passionnant débat, on peut boucler en repartant de ce commentaire.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 Pol' uX (site web personnel) . Évalué à 2 (+0/-0).
Moi qui pensait que c'était ainsi à dessein. :)
Adhérer à l'April, ça vous tente ?
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par fearan . Évalué à 3 (+0/-0).
C'est marrant mais ton PC c'est exactement le même problème si tu veux le faire tourner sous Linux.
Et pour te répondre, un système qui peut se faire rooter via un mms invisible avec ouverture persistant d'accès à distance, c'est nettement moins robuste que le même système qui n'est pas vulnérable à l'attaque.
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.
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.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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) . É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: La pétition ne mentionne pas les bonnes alternatives
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
Les banques n'existent que pour sécuriser l'argent de leurs clients.
Sinon autant garder des billets dans un coffre à la maison (ou des crypto monnaies sur son PC si on veut être moderne).
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 devnewton 🍺 (site web personnel) . Évalué à 2 (+1/-2).
Arrête avec cette histoire de contexte, tu le ressors dans chaque débat sur les applis bancaires et on t'a déjà montré que c'était une surinterprétation de ta part.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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) . É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 Faya . Évalué à 4 (+3/-1).
Où ? Parce que je pense avoir lu toutes ces discussions et bien que je sois à 100% contre l'obligation Apple/Google pour accéder à ses services bancaires, ce que dit aeris me semble clair et sourcé. Les règles disent que tu dois présenter ensemble le qui, quoi, combien. Et le fait que toutes les banques ne respectent pas encore la règle n'est pas une preuve que la règle n'existe pas… Alors peut-être qu'on devrait réfléchir sur un moyen standardisé de respecter cette règle.
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 Glandos . Évalué à 4 (+2/-0).
Ah, je sais ce que je voulais demander la dernière fois (ces débats sont sans fin, on en oublie des trucs ).
J'ai bien compris que le tuple
(code unique; contexte)doit être intriqué lors de sa communication au client de la banque. Mais niveau accessibilité au non-voyant / malvoyant / personne avec des difficultés de motricité fine (j'ai vu quelqu'un galérer ce matin pour taper son code de CB sur un terminal tactile), comment ça se passe ?Une application bancaire sur un appareil purement tactile, ça marche ? Je sais que la base d'Android fournit un ensemble d'outil d'accessibilité, je m'en sers d'ailleurs pour mon audition un peu foireuse, mais est-ce que ça ne met pas sur la touche tout un pan de la population, déjà fragilisé ?
[^] # Re: La pétition ne mentionne pas les bonnes alternatives
Posté par Aeris (site web personnel) . É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 Glandos . Évalué à 4 (+2/-0).
C'est effectivement une bonne blague. Et je n'aimerai pas être aveugle, d'autant plus aujourd'hui que la grande majorité de nos informations passent par des écrans et des interfaces tactiles :(
# bonne initiative
Posté par gibs . Évalué à 3 (+3/-0).
Bonne initiative, mais n'attaque pas le problème de fond.
On est sur un processus de longue durée (deux décennies), dont les appli' bancaire ne sont qu'une étape, pour un secteur.
La "sécurité" signifie ici "contrôle" (de l'usager, non pas le contrôle de l'usager sur ses fonds ou son accès à ses fonds). Et ce contrôle est déjà passé par plusieurs étapes:
De la passphrase simple au SMS, puis du SMS à l'OTP, puis de l'OTP à l'appli, puis de l'appli à l'OS qui prépare l'étape suivante: puces sécurisées pour collecter fingerprints, selfie et autres données biométriques.
L'extension s'est elle-aussi faite suffisamment progressivement: Pour le paiement par carte d'abord, ensuite étendu aux opérations dites "sensibles" dans l'espace en ligne (virements) puis la connexion à l'espace en ligne. (Ce alors même que la DSP2 concoctée par le lobby bancaire promouvait la 2FA en tant que palliatif au fait que le numéro de CB ne peut pas faire office d'identifiant lors d'un paiement)
Il faut reprendre la chronologie pour comprendre son aberration:
Vice numéro un: dans les années 2000, les banques doivent permettre le paiement par internet et laissent les clients s'authentifier avec un secret qui n'en est pas un: les données de la CB (qui n'est ni quelque chose que l'on connaît exclusivement, ni quelque chose dont la possession garantie à elle seule la légitimité à l'opération [c'est le propre d'un objet])
Pour pallier à ce faux secret: vice numéro 2: un code à usage unique. D'abord envoyé par SMS, puis sous la pression de Google (la hype autour du SS7), à l'OTP.
L'occasion était trop belle pour ne pas pousser pour plus de contrôle et imposer des app'.
(=> Le corollaire étant que la 2FA pour une authentification, à la différence d'un paiement, ne s'est jamais justifiée sauf par l'argument "Mme Michu utilise toujours le même mot de passe sur tous ses sites web, depuis 40 cyber-cafés")
D'ailleurs la 2FA n'est jamais rien d'autre qu'un second shared-secret sauf qu'il faut un CPU pour le dériver. Dans la DB du validateur il est dans la table
{mfa_secrets}juste à côté de la table{users}). Mais devoir dériver mathématiquement un shared secret, ça incite fortement le client à être très bon en calcul mental ou avoir une calculette (autrement dit un smartphone). Serait-ce possible que le 2FA ait conçu inventé pour le smartphone ? (alternativement, on pouvait juste utiliser la colonne "passphrase" dans{users})Le problème de fond (déjà soulevé) est qu'une politique de sécurité doit se baser sur une analyse des risques rationnelle qui ne peut pas être monolithique et unilatérale.
Or actuellement, c'est le fait du prince de la DSI d'une banque. Elle doit revenir aux usager (avec ou sans iphone, avec ou sans clef GPG, avec ou sans 2FA, etc…) car ils sont les seuls légitimes à arbitrer entre sécurité (empêcher l'accès à un tiers) et accessibilité/résilience (accéder à ses fonds en cas d'urgence [hôpital, à l'étranger, pas de batterie/4G, téléphone volé, …]
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.
Concernant les secteurs, ils vont bien au-delà des banques: transfert de fonds (selfie chez Wise/Western Union etc…) mais aussi administration (identité numérique laposte). Les services (gaz/électricité) ne sont pas loin. Payer des services d'hébergement (ou de VPN) devra se faire de plus en plus avec des validations d'identité.
Il faut aussi mettre ça en parallèle avec la guerre aux VPN (Boursorama interdit l'usage du VPN pour des "raisons de sécurité" à l'instar de la BPCE qui fait régulièrement des tentatives d'extension dans ce sens, par petits pas).
De nombreux hébergeurs sont invités (par prestataires en "DDoS prevention") à couper d'emblée leur réseau aux VPN quand bien même leurs clients souhaiteraient permettre un accès vraiment universel à leur sites/services.
On pourrait rajouter la guerre aux humains avec les captchas à tour de bras. (Rappelons que vérifier une captcha pour un GET coûte plus de cycles CPU que de renvoyer la ressource depuis un cache : ce n'est donc pas pour lutter contre les "abus" que celles-ci existent mais bien dans le cadre d'une collecte d'information et de contrôle progressif du trafic)
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…) ou que les conseillers bancaire accorde une valeur une signature manuscrite sur un scan :|
Le principe même de la 2FA est une quête sans fin, car si le mot de passe ne suffit pas, rien suffira jamais car tout le reste peut être hacké. (C'est très pratique que ça puisse l'être car ça force à rajouter une couche de complexité et de contrôle). D'ailleurs se qui compte n'est pas le fait que ça puisse être hacké mais le récit qui en est fait et les transformations à sens unique qui en sont obtenues. Le SMS pouvait être intercepté… certes, en 2G du SDR. On est passé à la 5G et personne n'est pourtant revenu au SMS. (De temps à autre on nous sort une histoire anecdotique de sim-swap pour garder la pression en faveur de l'OTP/smartphone)
Quant au Droit c'est une blague qui a déjà quelques siècles. Tout ceux qui étaient avant-hier les fervent défenseurs de la liberté d'expression et de la neutralité du net, adoraient, hier, la censure-de-facebook/Google/Twitter-pour-lutter-contre-la-désinformation et argumentaient que "Facebook est un réseau privé qui a donc le droit de choisir ses utilisateurs" (lorsqu'il s'agit de censurer les antivaxx-fachistes-…). Demain ils adoreront la "banque privée qui vous garantit le droit… d'aller voir ailleurs si vous n'êtes pas contents".
Et ne mentionnons pas tous les ravis de la crèche de la 2FA (certains en font même des listes de vertu: https://2fawebsites.github.io/) et autres libertariens du passe-sanitaire qui ont acheté à peu près chaque narrative sécuritaire des GAFAM pendant deux décennies. Oh, oui, je veux ma clef de chiffrement de disque dans une TPM (mais "opensource"). Oh oui, je veux renouveler mon certificat SSL toutes les 2 semaines (mais seulement avec les gentils de LetsEncrypt), oh oui je veux du CORS/COOP/COEP dans mon navigateur, et puis aussi ses 1000 autorités de certification (mais avec de la certificate transparency!) et puis protéger les mineurs sur internet grâce à de la validation d'identité, etc etc etc…
Tout ça pour dire qu'il serait temps d'avoir un peu moins de naïveté technologique et un peu plus de hauteur de vue sur des cycles longs parce qu'au rythme actuel, l'étape du contrôle biométrique lors de l'allumage de la box sera atteinte au tournant des années 2035… et comme toujours… "par le plus grand des hasards et sans préméditation"
[^] # Re: bonne initiative
Posté par Aeris (site web personnel) . Évalué à 1 (+1/-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: bonne initiative
Posté par Aeris (site web personnel) . É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/
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.