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é à 4 (+4/-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é à 1 (+0/-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é à 7 (+5/-0). 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 (+4/-0).
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é à 4 (+1/-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 (+3/-0). 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é à 4 (+1/-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é à 5 (+2/-0).
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.
# Idée
Posté par tkr . Évalué à 9 (+7/-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 (+6/-1).
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é à 4 (+3/-2). 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 (+1/-0).
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 (+0/-0).
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é à 3 (+0/-0).
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.
# Une partie de réponse
Posté par boarf . Évalué à 8 (+7/-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é à 8 (+5/-0). 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é à 5 (+3/-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 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é à 3 (+2/-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 devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0).
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é à 3 (+2/-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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3 (+0/-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é à 5 (+3/-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.
# Râler ou décider
Posté par jpglinuxfr . Évalué à 2 (+3/-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.
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.