Les banques vont bientôt supprimer l'envoi de SMS pour renforcer l'authentification sur leur site.
C'est une bonne chose car cette méthode est l'objet d'attaques.
Elles vont soit-disant déployer l'authentification forte (ou a double facteur) en application de directive européenne DSP2.
En fait, l'alternative proposée est de pousser les utilisateurs à installer l'application de la banque sur leur smartphone. Ce qui n'améliore pas vraiment la sécurité (quand on utilise l'appli pour faire ses opérations bancaires et qu'on s'authentifie avec, il n'y a plus qu'un seul facteur).
De plus cette solution n'est pas résiliente lors de perte, vol, casse ou encore piratage du smartphone.
De manière générale cette solution impose d'avoir un smartphone avec Android ou iOS assez récent pour qu'il puisse être mis à jour et bien sur un abonnement (c'est déjà un budget !).
Pour ceux qui n'ont pas de smartphone (ou qui refuse l'usage de l'appli) trois possibilités plus ou moins mal-foutues :
-- une carte avec des nombres à usage unique (carte "tan");
-- le boîtier Digipass qui est un lecteur dédié de QR code qui fait office de TOTP,vendu plusieurs dizaines d'euros.
Mais son usage est d'une complexité inutile : il faut scanner à chaque fois un QR code puis fournir le code à 8 chiffres ! C'est l'exemple même du principe "Pourquoi faire simple alors qu'on peut faire compliqué" !
-- Le lecteur SAFETRANS qui permet l'authentification avec sa carte bancaire (le code peut être demander lors de certaines opérations). Cependant il ne fonctionne qu'en environnement Windows ou MAC, Linux n'est pas supporté.
Le diagnostic de compatibilité donne le message suivant :
Les systèmes d'exploitation pris en charge sont :
macOS 11 ou version ultérieure
Windows 10 ou version ultérieure
Pourquoi donc les banques inventent-elles des solutions "maison" donc forcément mal-sécurisée ?
Alors qu'il existe (depuis au moins 15 ans) des solutions standardisées et éprouvées qui ne demandent que peu de travail d'implémentation dans les navigateurs, ni pour les sites à sécuriser :
—TOTP (code a usage unique qui peut aisément remplacer l'envoi des SMS et qui fonctionne avec une aplli comme FreeOTP sur pratiquement tout les smartphone
—les clés fido (Yubekey, etc. )
(voir : https://linuxfr.org/users/acatton/journaux/cles-de-securite-pas-assez-utilisees)
En tant qu'individu isolé je ne peux pas faire grand chose, d'autres ont déjà protesté ici ou ailleurs
(voire :https://linuxfr.org/users/fcartegnie/journaux/l-authentification-molasse
Apparemment le problème principal est de trouver un interlocuteur capable de comprendre les enjeux et les solutions éprouvées disponibles.
Il faut donc une action menée par des organismes ayant une audience certaine comme les associations de consommateurs
Parmi les lecteurs de linuxfr n'y a-t-il pas des membres de l'APRIL ou d'organismes de consommateurs ou de partis politiques concernés par le libre qui puissent demander à leurs organisations de se concerter pour lancer une campagne (ou au minimum une pétition) en vue de forcer les banques à supprimer leurs bidouillages et à utiliser de véritables solutions 2FA ainsi que de permettre le fonctionnement de Safetrans sur Linux.
# Ces solutions sont en cours d'abandon
Posté par Stun43 . Évalué à 6 (+6/-0).
Salut.
Il y a plusieurs années, la banque populaire m'a fourni un lecteur de CB. La double authentification se réalisant via un périphérique dédié et ma CB, je pense qu'on avait trouvé ici une solution formidable.
Aujourd'hui, tout est basculé autant que possible sur l'App mobile, comme les autres mais je pense que cette alternative est toujours proposé à ceux qui refusent/ne peuvent utiliser l'App.
[^] # Re: Ces solutions sont en cours d'abandon
Posté par nizan666 . Évalué à 2 (+1/-0).
Pour ce que j'ai pu en juger une fois de plus il y a quelques semaines, les "conseillers" de cette banque sont à la rue et ne connaissent pas cette possibilité mais selon les services techniques de ce même établissement (qu'il faut nécessairement joindre après avoir fait une opposition car cette démarche "désactive" automatiquement le lecteur comme moyen d'authentification) à qui je posais la question de l'avenir de cette solution, elle est encore très utilisée et en tous cas "n'est pas près de disparaître".
# Illégal d'imposer l'appli, la banque *doit* proposer une alternative
Posté par tkr . Évalué à 8 (+7/-1). Dernière modification le 03 avril 2025 à 17:12.
Salut,
je me sens particulièrement concerné par ce sujet, d'autant que je crains qu'en DSP3 en 2027 plus aucune banque n'aura le droit d'utiliser le SMS.
ça risque de terminer comme les dizaines de milliers de clients du crédit mut coupés du j au lendemain :
https://www.challenges.fr/entreprise/banque-assurance/pourquoi-les-banques-vont-exiger-que-leurs-clients-aient-un-smartphone_695920
ou comme celui qu'a accepté benoitement l'appli, et qui le regrette quand son tel n'est plus compatible :
https://www.rtl.be/actu/belgique/lapplication-bancaire-de-michel-ne-fonctionne-plus-sur-son-telephone-de-2018-je/2023-04-24/article/533828
pour ma part, zéro appli dans la vie, pour raison de :
-le téléphone est trop sensible (comme les clés) aux aléas physiques
-la version du système finira tot ou tard par être refusée par la dernière version de l'appli
-perdre son tel, c'est la merde => zéro système de paiement dessus
-diviser pour mieux régner, vs tous leurs oeufs dans le même tel
-économique : tout est à la charge du client (appareil+abo), et les tarifs commerciaux ne descendront pas
==> exigez que l'on vous apporte un boitier, la banque a obligation à fournir une solution pour les non smartphonisés.
Il s'agit d'un petit boitier, à tarif modéré (30e) Par contre : soit c'est gratuit si vous ne possédez pas de smartphone, soit ca vous est facturé (ou carrément refusé) si vous montrez que vous en possédez un. Quid s'il est trop vieux et ne s'installe pas? La banque vous impose => gratuit pour vous, point barre.
[^] # Re: Illégal d'imposer l'appli, la banque *doit* proposer une alternative
Posté par tkr . Évalué à 6 (+5/-1).
Le boitier doit être gratuit si vous ne possédez pas de smartphone compatible (la banque ne peut vous forcer son achat)
boursorama (à tester):
https://www.boursobank.com/aide-en-ligne/securite/proteger-mon-espace-client/question/comment-se-connecter-a-votre-espace-client-grace-aux-cles-de-securite-5165516
crédit agricole :
https://www.credit-agricole.fr/particulier/compte/service-bancaire/securicode.html
credit mut :
https://www.creditmutuel.fr/fr/particuliers/comptes/authentification-forte-digipass.html
caisse epargne :
https://www.caisse-epargne.fr/comptes-cartes/dsp2/
to be continued..
[^] # Re: Illégal d'imposer l'appli, la banque *doit* proposer une alternative
Posté par arnaudus . Évalué à 6 (+3/-0).
C'est quel genre de "doit"? C'est un "droit" légal ou bien c'est un "dans un monde idéal ça devrait"?
C'est évident, mais la banque a le droit de facturer tout un tas de services, la gratuité n'est pas un droit (d'ailleurs, il y a des frais de tenue de compte…). Donc pourquoi pas facturer la location d'un terminal d'identification ?
[^] # Re: Illégal d'imposer l'appli, la banque *doit* proposer une alternative
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+4/-1). Dernière modification le 04 avril 2025 à 10:38.
La gratuité ne veut pas dire que les coûts ne sont pas intégrés dans le budget de la banque, mais l'avantage serait d'obliger la banque à gérer de façon plus durable un parc de terminaux si elle ne peut pas directement en imputer le coût aux clients.
Dans le même genre avec les applis mobiles, ça encourage un renouvellement plus régulier des smartphones chez les particuliers, ce qui une source majeure de pollution.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Illégal d'imposer l'appli, la banque *doit* proposer une alternative
Posté par arnaudus . Évalué à 7 (+4/-0).
Ça peut être une politique de la banque, en fonction de la typologie des clients. Il faut quand même réaliser que sauf injonction de la banque de France, une banque n'est pas obligée d'ouvrir des comptes, d'accorder des prêts, etc. Une banque est une entreprise, elle n'a aucune raison de fournir des services s'ils lui coûtent plus que ça ne lui rapporte, sauf évidemment si c'est une obligation légale (par exemple, gratuité de l'émission et de l'encaissement des chèques).
D'ailleurs, les banques ne se privent pas de facturer tout un tas de trucs (ou de refuser quand facturer est illégal) aux clients dont le profil n'est pas favorable (découverts, saisies d'huissiers, nationalité US, etc). Du coup, quand tu arrives et que tu commences à exiger des trucs que les autres clients ne demandent pas, le rapport coût/bénéfice de te garder parmi la clientèle va évidemment être évalué. Si la banque estime que les zozos qui n'ont pas de smartphone sont rentables, elle va te fournir gratuitement ton terminal. Si ça n'est pas le cas, alors on va te facturer tes exigeances pour te rendre rentable, ou t'inciter à aller voir ailleurs.
En gros, toutes les banques du monde sont très heureuses d'avoir des clients exigeants, avec des manies, des principes, ou des demandes qui sortent de l'ordinaire… tant qu'ils sont pleins aux as et qu'ils remplissent les coffres.
L'argument semble quand même assez rhétorique, parce qu'il semble assez clair que pour une application bancaire on ne peut pas se permettre de supporter les OS qui ne sont plus maintenus—le problème vient donc plutôt de l'arrêt du support que des applications elles-mêmes. Pour ma banque par exemple c'est Android 7 qui est demandé, un OS qui date quand même de 9 ans et qui n'est plus mis à jour chez certains constructeurs depuis 2020.
[^] # Re: Illégal d'imposer l'appli, la banque *doit* proposer une alternative
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6 (+4/-1).
Ou alors, il y a le TOTP. C'est portable, c'est implémenté sur ordinateur, sur téléphone, sur ce qu'on veut, il n'y a rien à développer, c'est aussi intégrable sans difficulté dans une appli bancaire, du coup c'est certainement moins cher, c'est sûrement pour ça que les banques ne s'y mettent pas.
[^] # Re: Illégal d'imposer l'appli, la banque *doit* proposer une alternative
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0).
Avec une simple webapp, il est facile et peu coûteux de gérer des terminaux très divers (PC, console, tablette, smartphone, télé connecté, montre…) et très vieux (plusieurs dizaines d'années avec un site léger).
Bonne chance pour faire ça avec une appli native (privatrice en plus).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Illégal d'imposer l'appli, la banque *doit* proposer une alternative
Posté par jihele . Évalué à 8 (+6/-0).
Au Crédit Coop j'ai un boîtier mais depuis mes dernières CB ça ne marche plus, apparemment parce que le fournisseur des cartes a changé et le voltage n'est plus compatible (c'est ce qu'on m'a dit). Donc j'ai fini par accepter le SMS à la place. Heureusement que j'avais un téléphone depuis peu.
Je partage complètement le journal. J'ai peur qu'on en arrive à devoir installer l'appli proprio ou aller au guichet. Et effectivement, l'écrire ici ne sert à rien et au risque de faire le yaka-faucon, ça me semble bien du ressort d'organisations de consommateurs ou de l'APRIL.
Dans une banque coopérative, on doit aussi pouvoir donner son avis, mais si c'est pour le donner à des gens à qui ça passe complètement au-dessus, c'est compliqué. C'est peut-être plus efficace si ça vient d'une organisation plutôt que d'un individu.
Je comprends que TOTP n'utilise pas un challenge associé à l'opération, mais comme dit dans un ou plusieurs commentaires, TOTP peut servir à se connecter à son espace client et y accepter la transaction selon les conditions qui y sont affichées de façon fiable. A chaque fois que j'ai recours au SMS, c'est soit pour me connecter à mon espace (TOTP devrait suffire), soit pour valider une opération (depuis mon espace client), soit effectivement pour valider une transaction depuis un site tiers qui me renvoie à une page de paiement sécurisée dédiée qui d'ailleurs parfois me demande en plus mon mot de passe pour me connecter à l'espace client. Donc il me semble que tout est en place pour remplacer le SMS par TOTP et vivre dans le meilleur des mondes.
[^] # Re: Illégal d'imposer l'appli, la banque *doit* proposer une alternative
Posté par antistress (site web personnel) . Évalué à 3 (+0/-0).
Et moi j'ai deux banques, dont une sans CB… C'est cuit pour celle-là ?
# Idée
Posté par tkr . Évalué à 10 (+8/-0). Dernière modification le 03 avril 2025 à 17:27.
Pour ma part, je pense surtout, au vu de l'invasion de services en lignes n'ayant qu'une app et même pas de site web, qu'il est nécessaire d'y avoir une pétition européenne (comme celle de la distro nunux) exigeant l'interdiction de vente en europe de tout service en ligne, qui n'est pas disponible sur autre chose qu'un appareil ios/android.
À ce rythme là, dans quinze ans, aucun service ne sera utilisable sans app…
J'avais lu sur reddit, il y a quelques jours, un commentateur qui disait "en europe, les banques ont toute fait le choix d'imposer une appli propriétaire à la va vite sur ios ou android.. aucun équipement TOTP ou autre système interopérable (yubikey ou autre) n'a été choisi"
triste europe..
[^] # Re: Idée
Posté par HG203 . Évalué à 3 (+2/-0).
Qu'il y ait une démarche au niveau européen c'est une bonne idée pour contraindre le banques, mais il faut surtout que se soit médiatisé (je sais, le contexte actuel n'est pas favorable) et qu'on en parle dans les JT et les reseaux socios.
[^] # Re: Idée
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
Il y a un précédent en fait : la Corée du Sud avec ActiveX sur Internet Explorer.
# Pourquoi?...
Posté par redo_fr . Évalué à 7 (+7/-2).
Toujours pour la même raison : Obliger les utilisateurs à installer "l'appli" sur leur téléphone intelligent, pour leur "pomper" leurs données personnelles…
Je suis sûr à 200% que l'appli a été conçue avec des "kits de dev" bourrés d'adware.
Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.
[^] # Re: Pourquoi?...
Posté par HG203 . Évalué à 2 (+1/-0).
C'est bien pour cela qu'il faut une alternative sans ces applications.
[^] # Re: Pourquoi?...
Posté par arnaudus . Évalué à 3 (+4/-4). Dernière modification le 04 avril 2025 à 09:38.
Pur FUD, je ne vois pas en quoi adopter un comportement Trumpiste va aider la cause de la préservation de la vie privée.
[^] # Re: Pourquoi?...
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+2/-1).
Sans faire de FUD, on ne peut pas savoir ce qu'il y a dans une appli privatrice.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi?...
Posté par arnaudus . Évalué à 3 (+1/-1).
Techniquement non, surtout qu'il y a évidemment la partie serveur qui nous échappe, mais il reste très facile de vérifier les droits demandés à l'OS (pour la mienne: caméra (pour scanner les chèques) et notifications (pour la double identification), et de lister le traffic des trackers (apparemment, uniquement les trucs bateau google pour mesure de trafic). Donc on est à des années lumière des millions de merdouilles qu'on a sur un jeu gratuit classique.
Sur le fond, je trouve que la remarque de toutes manières est assez débile. Une banque a par définition accès à des données personnelles très sensibles, elle sait tout de toi : avec qui tu vis, combien tu gagnes, quand et combien tu dépenses dans n'importe quel magasin; elle a une copie de ta pièce d'identité et de tes bulletins de salaire, et elle peut décider de ta mort sociale instantanément si elle te coupe tes accès bancaires. Comment peut-on imaginer qu'elle puisse avoir intérêt à pourrir son interface sécurisée avec des aspirateurs de données louches? Disons plutôt que bien sûr, dans le monde réel, rien n'est impossible et surtout l'incompétence est sans limite, donc bien sûr, il est tout à fait possible qu'un commercial idiot ait signé un partenariat bidon avec un broker pour récupérer ta position GPS au moment où tu te connectes à l'application, mais c'est quand même n'importe quoi d'imaginer que le but de la généralisation des applications est d'aspirer des données bateau alors que la banque a des données 1000 fois plus sensibles et monnayables sur toi.
[^] # Re: Pourquoi?...
Posté par devnewton 🍺 (site web personnel) . Évalué à 2 (+0/-1).
Je comprends, mais la security by what could go wrong, c'est pas mon truc.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi?...
Posté par arnaudus . Évalué à 3 (+1/-1). Dernière modification le 04 avril 2025 à 13:25.
Je me trompe peut-être, mais j'ai l'impression que la jurisprudence qui tend à rendre la banque responsable de pas mal de trucs quand on se fait arnaquer justifie beaucoup l'approche "application proprio". Ça me semble normal qu'à partir du moment où la banque doit couvrir les clients de "bonne foi", elle souhaite verrouiller à mort l'environnement dans lequel on peut valider une transaction. Si par exemple tu télécharges un TOTP ou un weboob pourri parce que github ou les serveurs de ta distribution se sont fait hacker et que tu te fais siphonner tes comptes, tu est techniquement de bonne foi, pourtant la banque n'y peut pas grand chose. Donc il y a deux solutions pour elle : soit fournir des moyens d'accès aux comptes (API, protocoles d'identification génériques…) mais de trouver un moyen pour ne pas garantir les fraudes (donc du coup, c'est aux risques et périls de l'utilisateur), soit fournir un nombre très limités d'interfaces dont elle contrôle la chaîne (de l'accès réseau à l'interface graphique, en passant par le catalogue d'applications).
Est-ce que les utilisateurs "libristes" souhaitent réellement s'auto-assurer vis-à-vis de la fraude bancaire?
[^] # Re: Pourquoi?...
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0).
Non, mais on est plus en sécurité avec une approche libre et ouverte.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi?...
Posté par arnaudus . Évalué à 2 (+1/-2).
Tu peux faire comme si tu n'avais pas compris ce que j'ai écris, mais là tu as l'air de répéter un mantrâ religieux sans comprendre les enjeux. Aucune banque ne couvrira les transactions frauduleuses si c'est toi qui t'occuppes de la sécurité de la connexion avec l'API bancaire. Donc soit tu utilises ta propre chaine d'identification pour te connecter à l'API de la banque et tu t'auto-assures, soit tu utilises celle de la banque et elle te couvre. Tu ne peux pas avoir les deux. Et comme la jurisprudence semble obliger les banques à couvrir, alors elles t'imposent leur chaine de sécurité.
L'allégeance au libre c'est pas Skippy le Grand Gourou. Si tu te fais siphoner ton compte parce que l'appli de la banque est trouée, elle va couvrir la fraude, c'est une sécurité. Au contraire, le protocole Bitcoin est libre et ouvert, et si tu te fais hacker ou pêter les genoux à coups de barre de fer pour que tu lâches ton mdp, tu perds toute ta fortune. Le protocole libre et ouvert ne t'a apporté aucune sécurité.
[^] # Re: Pourquoi?...
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+3/-1).
C'est faux : elle tolère bien que j'utilise ma connexion internet personnelle, un smartphone personnel…
On ne peut pas aborder sereinement ce sujet si on est mode RSSI bouché :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi?...
Posté par Elfir3 . Évalué à 1 (+0/-1).
Objection !
Ta connexion n'est qu'un canal, grâce aux progrès faits en cryptographie il est possible de s'assurer que personne ne lis ou modifie les données qui transitent.
Et le smartphone, on sait tous qu'il est pas vraiment à toi.. ou alors t'as pas l'appli de ta banque.
Merci de prendre le commentaire ci-dessus avec: un peu de recul, le premier degré, et si possible le second !
[^] # Re: Pourquoi?...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
Mon téléphone est à moi, le système d'exploitation dessus est libre, je suis root, et j'utilise le logiciel de la banque. Bon, je lui cache que je suis root, mais rien de plus.
[^] # Re: Pourquoi?...
Posté par arnaudus . Évalué à -3 (+0/-6).
Ça a été dit plus haut : libre = sécurité et il n'y a rien à discuter. Quand tu es parti sur des formules toutes faites il n'y a pas de discussion possible.
Éventuellement, le seul truc qui pourrait être libre / sources ouvertes dans l'histoire c'est éventuellement l'app de la banque, mais évidemment tu ne pourrais pas te connecter avec une version modifiée.
La seule marge de manoeuvre qu'on pourrait envisager c'est une API sécurisée avec des protocoles standard, mais évidemment sans la couverture des transactions frauduleuses. Dans ce cas, on verrait bien combien croient pour de vrai au "libre = sécurité", s'ils vont autoriser l'ajout de destinataires de virements ou la validation des payements par carte avec un TOTP qu'on vient de git pull…
Pour moi, c'est évident que c'est celui qui garantit la transaction qui choisit ses outils. Si leurs machins sont troués, je m'en fous, c'est leur argent, c'est pas mon problème. Et en plus, sans dénigrer les compétences myticoles du vendredi soir, j'imagine qu'il est peu probable que le développement de ce type d'applications soit dans les mains d'incompétents techniques.
[^] # Re: Pourquoi?...
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+9/-0).
Tu as déjà fait du développement en entreprise?
80% de l'appli sont des libs libres dont le développement est plus sérieux que les 20% privateurs fait en mode à Gilles en enfreignant toutes les bonnes pratiques possibles pour livrer à temps.
Ces applis tournent ensuite sur un OS libre bien sécurisé mais auquel une DSI en mode devoups ajoute des couches privatrices dont tu ne voudrais même pas sur un serveur de test tellement elles sont bloated et troués.
L'exploitation se fait ensuite selon la règle du pas vu pas pris et on enterre les tickets secu sous le tapis.
Sans transparence, la confiance est juste un mot marketing.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pourquoi?...
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Même avec https://exodus-privacy.eu.org/fr/ ?
[^] # Re: Pourquoi?...
Posté par Selenith (site web personnel) . Évalué à 9 (+9/-0). Dernière modification le 05 avril 2025 à 10:57.
Pour apporter de l'eau au moulin et donner un exemple concret.
Ça c'est la capture des flux DNS lorsque j'ouvre l'appli d'une banque connue (pour l'exemple) :
10:35:55.657564 IP Android-2.local.shiva-confsrvr > _gateway.domain: 10460+ A? playstoregatewayadapter-pa.googleapis.com. (59)
10:35:55.673078 IP _gateway.domain > Android-2.local.shiva-confsrvr: 10460 11/0/0 A 142.250.179.106, A 142.250.75.234, A 172.217.18.202, A 142.250.201.170, A 142.250.178.138, A 172.217.20.170, A 216.58.214.170, A 172.217.20.202, A 216.58.215.42, A 142.250.179.74, A 216.58.213.74 (235)
10:35:55.678236 IP Android-2.local.32430 > _gateway.domain: 18328+ A? play-lh.googleusercontent.com. (47)
10:35:55.693021 IP _gateway.domain > Android-2.local.32430: 18328 1/0/0 A 142.250.179.86 (63)
10:36:01.574604 IP Android-2.local.centerline > _gateway.domain: 16610+ A? collect.tealiumiq.com. (39)
10:36:01.590100 IP _gateway.domain > Android-2.local.centerline: 16610 8/0/0 A 3.124.18.126, A 3.127.174.108, A 35.157.201.4, A 3.73.180.212, A 18.194.17.119, A 52.59.151.208, A 3.66.242.143, A 3.66.208.54 (167)
10:36:01.870324 IP Android-2.local.19665 > _gateway.domain: 14194+ AAAA? www.eum2.caisse-epargne.fr. (44)
10:36:01.897827 IP _gateway.domain > Android-2.local.19665: 14194 0/0/0 (44)
10:36:01.899599 IP Android-2.local.29302 > _gateway.domain: 5344+ A? www.eum2.caisse-epargne.fr. (44)
10:36:01.914532 IP _gateway.domain > Android-2.local.29302: 5344 1/0/0 A 91.135.181.171 (60)
10:36:02.077623 IP Android-2.local.28806 > _gateway.domain: 14445+ AAAA? firebaselogging-pa.googleapis.com. (51)
10:36:02.091941 IP _gateway.domain > Android-2.local.28806: 14445 4/0/0 AAAA 2a00:1450:4007:806::200a, AAAA 2a00:1450:4007:813::200a, AAAA 2a00:1450:4007:818::200a, AAAA 2a00:1450:4007:810::200a (163)
10:36:02.092205 IP Android-2.local.22417 > _gateway.domain: 30654+ A? firebaselogging-pa.googleapis.com. (51)
10:36:02.106496 IP _gateway.domain > Android-2.local.22417: 30654 10/0/0 A 142.250.201.170, A 216.58.214.74, A 142.250.75.234, A 216.58.214.170, A 172.217.20.170, A 172.217.20.202, A 216.58.215.42, A 142.250.179.74, A 142.250.179.106, A 142.250.178.138 (211)
10:36:02.144270 IP Android-2.local.33235 > _gateway.domain: 28566+ AAAA? www.as-ano-bad-ce-m.caisse-epargne.fr. (55)
10:36:02.194143 IP _gateway.domain > Android-2.local.33235: 28566 0/0/0 (55)
10:36:02.194353 IP Android-2.local.28898 > _gateway.domain: 18045+ A? www.as-ano-bad-ce-m.caisse-epargne.fr. (55)
10:36:02.222258 IP _gateway.domain > Android-2.local.28898: 18045 1/0/0 A 91.135.181.231 (71)
10:36:02.491353 IP Android-2.local.4588 > _gateway.domain: 18082+ AAAA? www.icg1auth.caisse-epargne.fr. (48)
10:36:02.542139 IP _gateway.domain > Android-2.local.4588: 18082 0/0/0 (48)
10:36:02.543249 IP Android-2.local.14048 > _gateway.domain: 14405+ A? www.icg1auth.caisse-epargne.fr. (48)
10:36:02.557353 IP Android-2.local.27513 > _gateway.domain: 9759+ A? 4892.n.trusteer.com. (37)
10:36:02.558136 IP Android-2.local.17429 > _gateway.domain: 7031+ A? 4892.n.trusteer.com. (37)
10:36:02.558192 IP Android-2.local.14790 > _gateway.domain: 6450+ AAAA? www.rs-ano-bad-ce-m.caisse-epargne.fr. (55)
10:36:02.571752 IP _gateway.domain > Android-2.local.14048: 14405 1/0/0 A 91.135.181.104 (64)
10:36:02.587731 IP _gateway.domain > Android-2.local.17429: 7031 1/0/0 A 52.59.153.27 (53)
10:36:02.587760 IP _gateway.domain > Android-2.local.27513: 9759 1/0/0 A 52.59.153.27 (53)
10:36:02.621707 IP _gateway.domain > Android-2.local.14790: 6450 0/0/0 (55)
10:36:02.621943 IP Android-2.local.22615 > _gateway.domain: 17559+ A? www.rs-ano-bad-ce-m.caisse-epargne.fr. (55)
10:36:03.547451 IP Android-2.local.33058 > _gateway.domain: 5820+ A? rab.api.caisse-epargne.fr. (43)
10:36:03.589386 IP _gateway.domain > Android-2.local.33058: 5820 5/0/0 CNAME d20icyvvsxzf6a.cloudfront.net., A 3.165.136.80, A 3.165.136.46, A 3.165.136.64, A 3.165.136.116 (150)
Ça c'est quand je sélectionne le compte utilisateur :
10:37:33.246150 IP Android-2.local.37037 > _gateway.domain: 47088+ AAAA? www.rs-ano-bad-ce-m.caisse-epargne.fr. (55)
10:37:33.333968 IP _gateway.domain > Android-2.local.37037: 47088 0/0/0 (55)
10:37:33.334294 IP Android-2.local.65126 > _gateway.domain: 57141+ A? www.rs-ano-bad-ce-m.caisse-epargne.fr. (55)
10:37:33.362438 IP _gateway.domain > Android-2.local.65126: 57141 1/0/0 A 91.135.181.231 (71)
10:37:36.958093 IP Android-2.local.48345 > _gateway.domain: 60701+ AAAA? customers.kameleoon.com. (41)
10:37:36.960732 IP Android-2.local.65300 > _gateway.domain: 59448+ AAAA? www.as-ext-bad-ce.caisse-epargne.fr. (53)
10:37:37.047294 IP _gateway.domain > Android-2.local.65300: 59448 0/0/0 (53)
10:37:37.047698 IP Android-2.local.53507 > _gateway.domain: 38417+ A? www.as-ext-bad-ce.caisse-epargne.fr. (53)
10:37:37.054054 IP _gateway.domain > Android-2.local.48345: 60701 1/1/0 CNAME customers-services01.kameleoon.com. (135)
10:37:37.057457 IP Android-2.local.38492 > _gateway.domain: 36055+ A? customers.kameleoon.com. (41)
10:37:37.075100 IP _gateway.domain > Android-2.local.38492: 36055 2/0/0 CNAME customers-services01.kameleoon.com., A 138.201.37.217 (92)
10:37:37.080416 IP _gateway.domain > Android-2.local.53507: 38417 1/0/0 A 91.135.185.227 (69)
10:37:37.761252 IP Android-2.local.47951 > _gateway.domain: 55881+ AAAA? www.icgauth.caisse-epargne.fr. (47)
10:37:37.789537 IP _gateway.domain > Android-2.local.47951: 55881 0/0/0 (47)
10:37:37.792814 IP Android-2.local.64234 > _gateway.domain: 42570+ A? www.icgauth.caisse-epargne.fr. (47)
10:37:37.807516 IP _gateway.domain > Android-2.local.64234: 42570 1/0/0 A 91.135.181.104 (63)
ET ça c'est quand je valide le formulaire d'authentification :
10:38:12.885480 IP Android-2.local.ssr-servermgr > _gateway.domain: 47448+ A? 4892.n.trusteer.com. (37)
10:38:12.900231 IP _gateway.domain > Android-2.local.ssr-servermgr: 47448 1/0/0 A 52.59.153.27 (53)
10:38:13.968654 IP Android-2.local.49928 > _gateway.domain: 58414+ AAAA? www.icgauth.caisse-epargne.fr. (47)
10:38:14.018772 IP _gateway.domain > Android-2.local.49928: 58414 0/0/0 (47)
10:38:14.019147 IP Android-2.local.53418 > _gateway.domain: 39397+ A? www.icgauth.caisse-epargne.fr. (47)
10:38:14.034016 IP _gateway.domain > Android-2.local.53418: 39397 1/0/0 A 91.135.181.104 (63)
10:38:14.333767 IP Android-2.local.56472 > _gateway.domain: 64939+ AAAA? www.as-ext-bad-ce.caisse-epargne.fr. (53)
10:38:14.361458 IP _gateway.domain > Android-2.local.56472: 64939 0/0/0 (53)
10:38:14.362254 IP Android-2.local.41760 > _gateway.domain: 44743+ A? www.as-ext-bad-ce.caisse-epargne.fr. (53)
10:38:14.389817 IP _gateway.domain > Android-2.local.41760: 44743 1/0/0 A 91.135.185.227 (69)
10:38:14.790043 IP Android-2.local.48629 > _gateway.domain: 46042+ AAAA? www.rs-ext-bad-ce.caisse-epargne.fr. (53)
10:38:14.840512 IP _gateway.domain > Android-2.local.48629: 46042 0/0/0 (53)
10:38:14.840815 IP Android-2.local.39753 > _gateway.domain: 49019+ A? www.rs-ext-bad-ce.caisse-epargne.fr. (53)
10:38:14.840837 IP Android-2.local.63194 > _gateway.domain: 61159+ AAAA? www.rs-ext-bad-ce.caisse-epargne.fr. (53)
10:38:14.841129 IP _gateway.domain > Android-2.local.63194: 61159 0/0/0 (53)
10:38:14.878206 IP _gateway.domain > Android-2.local.39753: 49019 1/0/0 A 91.135.185.227 (69)
On voit qu'il n'y a pas que des requêtes vers des machines qui appartiennent à la banque en question.
# Une partie de réponse
Posté par boarf . Évalué à 9 (+8/-0).
Une réponse sur certains points abordés dans le journal : de mémoire, la DSP2 demande que l'authentification de l'utilisateur soit faite de telle manière qu'il soit conscient du montant et du bénéficiaire de l'opération qu'il réalise.
Ceci explique que notamment le standard TOTP ne soit pas accepté : le code généré est lié au temps et non à une opération. Et, probablement, d'où les système à calculette ou celui à QR-code (qui n'est qu'une autre façon de saisir un challenge).
En vrai, ce ne serait pas trop compliqué de réadapter TOTP pour signer un challenge, et avoir des applications libres qui implémentent ce protocole, mais j'imagine que les banques ne souhaitent pas porter la responsabilité de la sécurité du secret déposé dans une appli qu'ils ne maîtrisent pas…
[^] # Re: Une partie de réponse
Posté par devnewton 🍺 (site web personnel) . Évalué à 9 (+7/-1). Dernière modification le 03 avril 2025 à 22:00.
C'est une interprétation débile qui conduit à des aberrations en terme de sécurité (coucou la bnp et tes iframes).
La validation du paiement dans l'espace client serait 42 fois plus sécurisé.
Pour l'authentification, l'usage de certificat client serait la solution idéale si les brouteurs se décidaient à leur dédier une UX/UI correcte: on génère une paire de clefs publique / privée, on donne la clef publique à l'enrôlement et hop on ne se tape pas des codes à saisir ou des applis pénibles.
Bref ils ne cherchent pas de solutions, car imposer leurs applis les arrangent commercialement.
En attendant les passgrids ou TOTP sont des solutions ecoresponsables (pas besoin de nouveaux périphériques ou de changer de terminal).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Une partie de réponse
Posté par octane . Évalué à 10 (+8/-0).
Je me demande si c'est pas aussi un appel délirant à des sociétés de consulting, pentesting, analyzing et securing qui rendent à chaque fois un rapport. Le but du pentesteur n'est pas d'auditer une application, c'est de remplir des vulns, pleins de vulns! tout plein. Genre il y a rien, il faut qu'il trouve des vulns quand même.
"Vous administrez votre serveur depuis votre poste? wolalalala! c'est une vuln P1 critical rouge avec mention sur le rapport managérial. Il faut un compte tier1 avec authent mot de passe mini 48 caractères majuscules minuscules symbols pas deux caractères identiques ni de séquences ni de mot du dictionnaire. Ajoutez à ça un OTP 2FA sur smartphone + une clé hardware avec validation et HOTP. Interdisez le copier coller, et faites ça depuis une machine "vault" qui n'a pas d'accès au réseau dans une salle sécurisée."
A force de lire ce genre de trucs débiles un manager quelconque s'émeut que son appli bancaire puisse permettre de transférer de l'argent (si si) donc il faut AJOUTER de la sécurité. Un auditeur repasse ne trouve rien, il est triste, donc il va dire qu'on peut améliorer la sécurité. Il faut maintenant une triple authent saut périlleux arrière vrillé triple lotz. D'un autre côté le market est heureux, ça va fourguer du spyware à tout va et de l'analytics bébé!! Ca le marketing en a rien à foutre de la sécu, mais de la data pour cibler le zozo pour lui vendre une assurance supplémentaire, là, il kiff et il est prêt à dire amen à toutes ces surcouches de sécurité. Une appli? OUI! Un 2FA? Vazy mon gars! Un OTP? Ca le fait!
Bref. Désormais pour payer sur un fuckin site web je dois prendre ma carte, le code, le numéro, le code au dos, mon nom, un code par SMS, un code "payement internet", le mot de passe de mon site web bancaire, etc, etc…
Je suis salé, je viens de relire un rapport de sécu lamentable, mais je sens la douille arriver, on va nous demander d'installer encore une nouvelle appli ou de gestionnaire de mot de passe je sais pas quoi pour avoir une quadruple authent, GG les gars. A côté de ça, le bastion a 42 ports ouverts, tourne sur une redhat 7 à moitié patchée en 8 mais ça, personne s'en émeut. Et vous ça va?
[^] # Re: Une partie de réponse
Posté par bbo . Évalué à 2 (+2/-2).
Tu devrais profiter des ponts de mai pour prendre quelques jours de vacances !
Une opportunité pour aller faire un peu d'accrobranches en salto arrière :)
[^] # Re: Une partie de réponse
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0).
Les sites d'accrobranches demandent un paiement avec une appli disponible uniquement sur iOS.
Il te faut aussi prendre une assurance chute (via une appli uniquement disponible sur le store Samsung), car le budget "appli" a rogné sur le budget "vérification des cordages".
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Une partie de réponse
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4 (+1/-0).
Ce qui risque de fragiliser la sécurité en complexifiant les accès au truc sécurisé. Bravo !
Mais c'est pas pareil, euh.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Une partie de réponse
Posté par octane . Évalué à 3 (+1/-0).
Une équipe a une clé hardware avec obligation de faire de la double authent pour se logger sur leur linux en local. Genre ils ouvrent la session, login, pass + clé hardware. Justificatif: si un pirate vole un mot de passe, il y a du 2FA, youhou, la vie est belle, l'entreprise est protégé.
Sauf que ssh est activé sur les postes. Et là, vient la question: si un pirate vole des comptes login+pass (genre phish, ou n'importe quelle méthode) que va faire un pirate:
1- se connecter en ssh avec?
ou
2- prendre sa voiture, aller dans l'entreprise, passer la porte, voler un badge, passer devant les caméras, badger à l'entrée, prendre le poste linux dans l'armoire, le mettre sur un bureau, mettre le mot de passe, et oh malheur à lui, il n'a pas la clé hardware :-( "Blast!", son "evil plan is foiled". (quoique 97% des gens laissent la clé avec le PC d'ailleurs…)
ah non. C'est comme la borne wifi open qui émet. Personne ne sait qui c'est. Mais c'est "comme ça", faut pas en parler, ça doit sûrement être utile.
[^] # Re: Une partie de réponse
Posté par cg . Évalué à 4 (+2/-0).
Sauf que ni la carte à codes unique, ni le boîtier lecteur de CB ne le permettent. Pour le boîtier qui fait des qr-codes, peut-être ?
Bref, ça ressemble tout de même fortement au syndrome de NIH.
Perso j'étais très content avec la carte papier à codes uniques au début des années 2000.
[^] # Re: Une partie de réponse
Posté par HG203 . Évalué à 3 (+2/-0).
L’accès à son compte en ligne ce n'est pas une transaction bancaire, donc il n'y a pas de raison d'imposer une appli, les moyens TOTP, carte TAN ou clés Fido sont légitimes.
D'autre part comment prétendre que la CB n'est pas conforme alors qu'elle sert aux transaction dans la vie réelle ?
[^] # Re: Une partie de réponse
Posté par Toto . Évalué à 5 (+4/-0).
La CB est conforme car le terminal de paiement affiche directement la somme.
Ici, la directive impose que la somme soit affichée / connue / validée par l'utilisateur sur son terminal d'acceptation de paiement (ou tout autre mécanisme genre TOTP + somme à entrer). Le but est de se prémunir d'un site qui afficherait une somme X pour un ordre de paiement Y.
Et ça, malheureusement, un TOTP pur, une CB avec un bête lecteur de CaP etc ne sont pas intrinsèquement compatible
[^] # Re: Une partie de réponse
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 04 avril 2025 à 11:49.
Rien ne prouve qu'il n'a pas été compromis. C'est aussi fiable qu'un SMS :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Une partie de réponse
Posté par gorbal . Évalué à 2 (+1/-0).
Les terminaux de paiements ont des technologies similaires aux boîtiers HSM, avec des protections physiques et logicielles: la norme PCI PTS
[^] # Re: Une partie de réponse
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0).
Rien ne me prouve que le terminal que me présente un commerçant lambda dans lequel je mets ma carte est "conforme". Tout se joue à la "confiance".
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Une partie de réponse
Posté par gorbal . Évalué à 1 (+1/-1).
Mais si le commerçant veut pouvoir transmettre des transactions à sa banque pour être crédité, il est nécessaire que celle-ci ai authentifié le terminal (via mTLS). Je ne sais pas si mettre des faux terminaux qui imiteraient des transactions dans un magasin soit financièrement intéressant.
Enfin, pour revenir à la première affirmation, cela reste nettement plus sécurisé que n'importe lequel des PC ou des smartphone existants, et sans commune mesure avec des SMS.
Sachant que la raison d'être d'un terminal de paiement est d'authentifier la carte, le porteur de carte et de valider le résultat de la transaction.
Ce serait techniquement la meilleur méthode pour valider une opération à distance attendu par DSP2 mais beaucoup moins d'un point de vu pratique et financier :-)
[^] # Re: Une partie de réponse
Posté par ted (site web personnel) . Évalué à 4 (+2/-0).
Le commerçant pourrait par ex. coller un écran par dessus indiquant 10€, quand la vrai transaction est 100€. Bon dans ce cas la banque sait qui aller voir, mais c'est pas si rare que des distributeurs (billets, essence, boissons…) placés dans des lieux publics se font modifier. Pour ceux là tu ne peux pas vraiment faire confiance au terminal mais le risque est acceptable parce que si tu te fais voler il y a une assurance qui te rembourse.
En fait il faudrait avoir son propre terminal pour être tranquille.
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Une partie de réponse
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Quand on me demande de payer avec une CB sur un terminal SumUp connecté au téléphone portable du vendeur (typiquement sur un marché), j’ai toujours un gros doute…
[^] # Re: Une partie de réponse
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+4/-1).
One more time : il suffit de faire valider le paiement dans l'espace client.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Une partie de réponse
Posté par boarf . Évalué à 5 (+4/-0).
Un point d'attention : la DSP2 ne concerne pas que les paiements par CB. Elle organise aussi l'ouverture des systèmes bancaires à d'autres acteurs (agrégateurs de comptes, etc.), et de cette ouverture requiert également de l'authentification forte sur le simple accès aux comptes (et évidemment pour les virements, etc.).
[^] # Re: Une partie de réponse
Posté par uneTanche . Évalué à 3 (+3/-0).
Pour le boitier qui lit les QR-Codes et qui génère une suite de chiffres (dans mon cas un boitier Digipass), il n'indique le destinataire de la transaction ni le montant.
En revanche, la page web où est affiché le QR-Code récapitule ces informations, mais comme pourrais le faire une page qui attend un code TOTP à la place d'attendre le code généré à partir d'un QR-Code.
[^] # Re: Une partie de réponse
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7 (+4/-0). Dernière modification le 04 avril 2025 à 12:11.
Le texte exact :
Une façon de faire serait que, côté site de paiement, la validation invite à se rendre sur l'appli ou le site de gestion bancaire (au choix), qui afficherait l'opération à valider et demanderait un TOTP (pour le site) ou autre chose (pour l'appli, vu que visiblement pour une appli bancaire, un simple code secret statique est considéré comme suffisant).
# Pas spécifique aux banques
Posté par tkr . Évalué à 6 (+4/-0).
mais depuis quelques mois j'avais ces pétitions qui n'étaient pas publiées, qui exigent tout simplement de rendre un service/produit interdit à la vente en UE, si son usage exige un appareil ios ou android (les banques ne sont pas les seules du tout)
deux exemples, je vous laisse indiquer laquelle vous parait la plus pertinente, si les deux devraient être mélangées, ou si vous en avez une meilleure, à défaut j'en choisirai une pour la mettre sur le site de l'Europe :
https://pytition.ethibox.fr/petition/user/tkr9/to-forbidd-product-or-services-based-on-ios-or-android-based-systems-exclusively-in-the-eu
https://pytition.ethibox.fr/petition/user/tkr9/to-forbidd-any-service-product-in-the-eu-that-requires-absolutely-ios-or-androidaosp-compatible-systems
ex de pétition européenne, pour linux (qui n'a pas de succès fou) :
https://www.europarl.europa.eu/petitions/en/petition/content/0729%252F2024/html/Petition-No-0729%252F2024-by-N.-W.-%2528Austrian%2529-on-the-implementation-of-an-EU-Linux-operating-system-in-public-administrations-across-all-EU-countries
[^] # Re: Pas spécifique aux banques
Posté par Strash . Évalué à 3 (+1/-0).
Interdire un produit qui fonctionne exclusivement sur smartphone, est-ce que ça n'interdit tout simplement pas quelque chose comme un jeu mobile ou autre ?
Que ce soit explicitement affiché pour qu'on puisse ne pas l'acheter si on le souhaite, et aussi que ça ne puisse pas changer pendant la durée de vie du produit, d'accord. Mais l'interdire complètement je trouve que ça va un peu trop loin.
[^] # Re: Pas spécifique aux banques
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
Il y a déjà des contraintes d'accessibilité pour des services essentiels (malheureusement les jeux vidéos n'en font pas partie), mais c'est comme les normes environnementales…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas spécifique aux banques
Posté par tkr . Évalué à 3 (+2/-1).
Non, ça ne va pas trop loin :
Si vous voulez que les gafam rachètent internet, n'hésitez pas à ignorer ces alertes, ça vient pas de moi, jme limite à la rédac' de deux pétitions, mais chaque année certains le pointent du doigt : les initiatives de site web, disparaissent pour les pages FB, sinon pour une appli mobile.
ca va pas trop loin, c'est même pas assez suffisant… comment faire pour ne pas encourager les gens à aller sur une appli? en leur montrant que cela dépend trop du smartphone, et en faisant en sorte qu'il ne soit surtout pas obligatoire.
[^] # Re: Pas spécifique aux banques
Posté par Strash . Évalué à 3 (+1/-0).
Je critiquais juste que ça donne l'impression d'interdire TOUT service qui a uniquement une appli et je pointais que c'est abusif. Si mon produit est un jeux vidéo destiné au mobile qu'est-ce que je fais ? Je suis obligé de faire une version PC ?
[^] # Re: Pas spécifique aux banques
Posté par tkr . Évalué à 0 (+1/-3).
Absolument.
Et je soutiens : toute procédure ou activité qui exige une appli mobile doit de facto proposer son alternative, sans surcout, sur ordinateur. Sinon, c'est la continuation du duopole néfaste ios/android tel que nous le connaissons aujourd'hui, et qui gangrène le numérique sur son critère d'accessibilité.
[^] # Re: Pas spécifique aux banques
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5 (+2/-0).
Pour quel système d'exploitation ? Windows, MacOS, GNU/Linux (quelle distro ?), FreeBSD ? On s'arrête où ?
[^] # Re: Pas spécifique aux banques
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
Malheureusement personne n'a encore inventé une façon d'exécuter une application indépendamment de l'OS, par exemple avec une machine virtuelle et des API…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas spécifique aux banques
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
Ouais alors si c'est pour se retrouver avec des machins en Java, je ne sais pas si je on doit vraiment considérer ça comme un objectif à défendre.
[^] # Re: Pas spécifique aux banques
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0).
Je pensais à un navigateur tout simplement 😀.
Bref les vms+runtimes, c'est pas ce qui manquent.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Râler ou décider
Posté par jpglinuxfr . Évalué à 3 (+4/-1).
"Râler ou décider" étant la devise d'un collectif (RIC14) que je trouve fort à propos, l'efficacité des pétitions étant (très ? très très ?) limitée à mon avis, je profite de ce journal pour faire la promotion d'initiatives qui peuvent intéresser certains ou certaines d'entre vous si vous ne les connaissez pas déjà :
Et, oui, les banques mais aussi d'autres institutions devraient être à notre service et pas l'inverse.
# Paiement en iframe
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 9 (+7/-1).
Toutes ces questions de sécurisation des paiements par CB sont bien amusantes dès qu'on se rend compte d'une faille béante dont tout le monde se moque : les paiements sont autorisés dans une iframe. Ou dans une application native, ça revient au même : l'utilisateur n'a aucune idée de quel est l'intermédiaire de paiement, s'il est fournie, et même si la connexion est sécurisée.
Un site marchand pourrait siphonner ainsi les infos de CB sans que ça se voie. Un phishing invisible en somme.
La règle de base avant de transmettre des informations un peu sensibles, genre numéro de CB, c'est de vérifier l'URL du site. Eh bien dans une iframe ou une application, c'est juste impossible.
Tant que ça n'est pas proprement interdit, ça continuera à me faire bien marrer, ces précautions pour la porte blindée d'un mur en papier.
[^] # Re: Paiement en iframe
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+2/-1).
Il est possible de vérifier la présence d'une iframe en utilisant le debugger du navigateur et en auditant le code html.
Simple !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Paiement en iframe
Posté par mahikeulbody . Évalué à 4 (+2/-0).
Ou alors limiter les conséquences d'un faux affichage en utilisant une carte virtuelle du montant exact de la transaction ; avec un peu d'habitude ça va assez vite de la générer (mais c'est certes pénible si on fait des dizaines de transactions par jour).
[^] # Re: Paiement en iframe
Posté par arnaudus . Évalué à 3 (+1/-1).
J'ai du mal à te suivre. La plupart du temps, c'est au commerçant que tu files ton numéro de CB, pas à l'application/frame du site de la banque. Le truc de la banque c'est pour valider la transaction avec une double identification. Si le commerçant l'intercepte, il ne pourra valider que cette transaction, à laquelle tu as consenti dans tous les cas.
[^] # Re: Paiement en iframe
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
Ah non, donner directement les infos de CB au commerçant, ce n'est pratiqué que par les commerçants les plus craignos, genre Amazon. Les sites sérieux envoient sur un intermédiaire. Qui, à son tour, va envoyer sur une page de validation de ta banque.
[^] # Re: Paiement en iframe
Posté par arnaudus . Évalué à 3 (+0/-0).
C'est pas un argument du vrai écossais, ça? Si on donne des exemples de commerçants qui ne font pas d'iframe, tu peux toujours dire que c'est les "craignos".
J'ai essayé de vérifier mais chez la plupart des commerçants il faut créer un compte pour accéder à la page de payement, donc je ne vais pas y passer plus de temps que ça. J'ai l'impression d'expérience que le coup de l'application de la banque, c'est pour les PME, ceux qui n'ont pas le budget pour développer leur propre interface de payement (par exemple quand c'est une boutique "standard" qui prend aussi les commandes en ligne). Les sites spécialisés sur le commerce en ligne ont toujours leur propre interface et ne renvoient sur le site de la banque uniquement pour la validation de la transaction, et jamais pour la saisie du numéro de carte et du code de sécurité.
[^] # Re: Paiement en iframe
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5 (+2/-0).
La façon propre pour un site, ce n'est pas d'utiliser un iframe, ni de choper toi-même les informations de CB hein. Il existe une troisième voie, la bonne : rediriger, tout simplement.
Et c'est de la merde, qui devrait être interdite. Je sais, rediriger, ça fait une expérience utilisateur moins bonne, mais ce n'est pas une raison, au contraire, c'est juste un caprice de designer, et les designers aux commandes de trucs de sécurités, ça se gère en les contraignant à faire des choses sérieuses.
[^] # Re: Paiement en iframe
Posté par arnaudus . Évalué à 4 (+1/-0). Dernière modification le 07 avril 2025 à 12:25.
Sauf qu'en tout état de cause, ça ne l'est pas, et visiblement la pratique est largement tolérée par les banques, donc ça devrait ou ça ne devrait pas être interdit ça reste subjectif…
Par exemple, j'ai l'impression qu'Amazon et consorts gèrent eux-mêmes la nécessité de 2FA. Quand ils ont un doute (nouvelle carte, même carte sur plusieurs comptes, pas de commandes récentes, changement d'adresse, etc), ils t'envoient une demande de 2FA, mais autrement ça passe sans passer par l'interface de la banque pour valider le payement. J'imagine qu'ils prennent sur eux du coup si la transaction s'avère frauduleuse. Tu ne pourrais pas avoir ce type de comportement si la transaction était gérée par la banque directement.
Après, c'est subjectif, mais je trouve que les sites d'ID des banques sont toujours très très laids, c'est tout petit, tout moche, on a l'impression d'être sur une procédure de debug réservée aux sites qui n'ont pas justement implémenté un formulaire correct de saisie d'indentifiants bancaires. Donc ça donne vraiment l'impression inverse, que la norme est de gérer la saisie des identifiants, en lien avec un compte client qui se rappelle des vieux paniers, des commandes, des adresses de livraison, etc.
[^] # Re: Paiement en iframe
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4 (+1/-0).
Absolument.
Le côté joli ou pas, c'est sans importance, on parle de sécurité là, pas de décoration intérieure. Mais ça participe effectivement à bien faire entrer dans la tête des gens que pour effectuer un paiement, il est important de ne vérifier que dalle parce qu'on ne peut rien vérifier.
# Le problème des apps bancaires : la dernière version d'android sera obligatoire
Posté par tkr . Évalué à 1 (+1/-2).
Et c'est bien le malheur qui en attend beaucoup : l'obligation d'avoir le dernier appareil à la mode, pour des prétextes de cybersécurité :
https://www.thevermilion.com/is-your-bank-app-no-longer-working-you-may-need-to-update-your-android-smartphone-heres-why/article_8225
https://www.androidpolice.com/apps-can-require-recent-android-security-updates-play-integrity
https://old.reddit.com/r/AndroidQuestions/comments/1jmdel5/my_bank_app_is_no_longer_compatible_with_android
https://www.clubic.com/actualite-545951-apps-bancaires-les-mises-a-jour-android-bientot-obligatoires.html
[^] # Re: Le problème des apps bancaires : la dernière version d'android sera obligatoire
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0).
prétextes ? Il y a de vraies raisons à mettre à jour pour des raisons de cybersécurité justement. Et si je devais râler ça serait plutôt sur la qualité initiale (qui oblige à multiplier les mises à jour derrière), en raison de la priorité donnée au fonctionnel et au dernier truc qui fera vendre. Ce n'est pas un hasard si le législateur a tapé du poing sur la table et ajouter plein de textes pour renforcer les contraintes en sécurité informatique pesant sur les différents acteurs (NIS2, CRA, etc.). On peut râler sur la durée limitée de la prise en charge sécurité par exemple, sur l'indice de réparabilité matérielle et logicielle, sur la transparence et le code source, sur les magasins d'application, sur les pouvoirs publics qui utilisent aveuglément des moyens privés sans réflexion, etc., mais ne pas mettre à jour un téléphone mobile c'est une grosse bêtise.
[^] # Re: Le problème des apps bancaires : la dernière version d'android sera obligatoire
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+4/-1). Dernière modification le 05 avril 2025 à 20:42.
Une grosse bêtise à cause de l'écosystème privateur des mobiles qui sont fait pour ne pas pouvoir être supportés sur le long terme.
Une grosse bêtise des banques qui forcent les utilisateurs à utiliser cet écosystème.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Le problème des apps bancaires : la dernière version d'android sera obligatoire
Posté par tkr . Évalué à 2 (+2/-2).
et c'est le client qui encaisse : changer l'appareil parce que le fabricant préfère gagner 100 000$ de vente renouvellées plutot qu'investir 100 000$ pour mettre à jour l'OS.
Le fabricant rechignera au mieux, trainera des pieds ou ne fera pas. J'ai six samsung android 4.0 qui n'ont jamasi été maj. J'en ai vu deux autres la semaine dernière, six ans sans maj, merci le même fabricant. Comme 99% des gens ont des samsung, la messe est vite dite.
Le fait que samsung ait été forcé par l'UE a faire du six/sept ans de maj après des années à s'arrêter à deux ans de maj, est éliminatoire pour le fabricant ET pour google qui n'a pas forcé les fabricants android à maj.
l'énorme reproche de google, c'est d'avoir mis aucune règle dans l'intégration de son système android. Je persiste : séparer le bancaire du téléphone est la meilleure voie pour le long terme.
[^] # Re: Le problème des apps bancaires : la dernière version d'android sera obligatoire
Posté par tkr . Évalué à 0 (+0/-2).
Je n'aurai aucune once d'hésitation à aligner le curseur de la technologie sur la praticité pour l'utilisateur final : un appareil est fabriqué pour qu'il réponde au besoin d'un utilisateur, point.
La praticité et les choix utilisateurs prévalent sur tout autre aspect. Sans aucun regret, jamais, nulle part.
# Même pas foutus d'implémenter WebAuth / FIDO2
Posté par fcartegnie . Évalué à 2 (+0/-0). Dernière modification le 08 avril 2025 à 04:45.
Chez Boursorama FIDO2 (avec et sans PIN) n'est qu'un moyen d'accélérer le login.
Si la clé n'est pas dispo, retour sur login/mdp. (qui d'ailleurs revient aussi "comme ça" de temps en temps)
# un certificat TLS EV pour la route?
Posté par merinos . Évalué à 1 (+0/-0).
une autre chose bien pratique: l'utilisation d'un certificat TLS EV par la banque.
et comment vérifier la chose: https://www.ebas.ch/fr/controle-du-certificat-du-navigateur/
# une solution sans smartphone...
Posté par merinos . Évalué à 4 (+3/-0).
en terres helvétiques, il est possible d'utiliser ce système (gratuit)… le plus court et simple possible, cela donne:
- la banque affiche un numéro à l'écran.
- j'entre ma carte de compte dans une sorte de "calculatrice".
- je tape le fameux numéro.
- puis je donne le NIP de ma carte.
- l'appareil sort un autre numéro.
- et j'inscris ce second numéro à l'écran.
et le tour est joué.
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.