Ben dans ce cas du logiciel propriétaire quoi…
Tu ne peux décemment pas imposer aux banques de faire du libre (ce qui est en plus totalement et légalement impossible dans le cas bancaire justement, puisque t’aurais a minima pas le droit d’exécuter une version modifiée).
Il n’y a aucune obscurité ici. Tout est documenté et parfaitement accessible et reproductible.
Sauf que tu ne verras jamais la clef privée de signature du matériel et de l’OS reconnu par les banques.
C’est un pur problème d’autorité de confiance, et pas de soft.
Mais si, mais si, il suffit d'intégrer ça intelligemment. Genre, sur la page de validation d'une transaction par CB : rendez-vous sur votre espace client pour valider cette transaction.
Se rendre sur ton espace client n’est pas une 2FA mais une 1FA. Et est lui-même soumis à SCA.
Pour se connecter en 2FA à ton espace client il te faudra… valider la SCA sur ton mobile. Retour au point de départ.
En fait, c'est juste pareil qu'avec l'appli bancaire, mais dans un navigateur, et avec du TOTP au lieu de la biométrie ou un code appris par cœur.
Comme dit, TOTP n’est pas contextuel et ne permet donc pas de remplir les obligations légales de la SCA DSP2/3.
Pour autant, il doit bien être possible de faire du contextuel avec des API ouvertes et une implémentation libre, non ?
Non, puisque les banques doivent avoir la certitude d’une application non modifiée et non modifiable. C’est pour ça qu’elles refusent actuellement les téléphones rootés et toute modif à même d’avoir altéré le fonctionnement de la SCA.
Et le passage sur les téléphones leur permet justement un contrôle au niveau matériel.
Et les systèmes alternatifs n’arriveront jamais à se faire reconnaître « de confiance », surtout sans les moyens financiers des assurances qui vont derrière (s’il y a de la fraude à cause de ton système de certif, c’est toi qui paie la fraude, pas les banques) https://grapheneos.org/articles/attestation-compatibility-guide
il y a d’autres moyens de double authentification (2FA) comme OTP, Yubikey, etc.
Qui ne respectent pas la notion de SCA contextuelle bancaire (action, montant & destinataire)
il n’y a aucune obligation égale à avoir un ordiphone,
Mais la banque a une obligation légale à fournir une SCA légale (DSP3)
dans les CGV de la banque il n’y a nulle part indiqué qu’il faut avoir un ordiphone pour en utiliser les services,
Mais la banque est concernée elle-même par une obligation légale qui est supérieure à ses CGUE
dans les mêmes CGV, il n’est indiqué nulle part qu’il faille un compte auprès d’Apple ou de Google pour utiliser les services en ligne,
Idem
Google exige des versions d’Android mises à jour pour les applis bancaires ce qui va raccourcir de facto la durée d’utilisation des ordiphones pour ces applis, la banque est-elle prête à payer des ordiphones plus récents aux clients ?
Pas le problème de la banque
la banque utilisait déjà d’autres systèmes de double authentification, pourquoi ne plus les utiliser ?
Parce que plus légales. Ne l’était déjà plus depuis longtemps pour la plupart (SMS, calculette, code fixe…). Les exigences DSP3 ont fait sauter tout le reste.
Solutions envisageables :
OTP (mot de passe à usage unique donc valable pour une seule transaction)
Non, pas contextuel
saisie d’un code fixe transmis par papier initialement nécessaire pour les transactions en ligne et qui s’ajoute aux informations de paiement et au code temporaire reçu par SMS, exemple du Securicode du CA,
Pas contextuel ou plus fiable (SMS)
une petite télécommande qui génère un code unique après flashage d’un QR-Code (CIC),
Pas contextuel, illégal
U2F (Universal Second Factor norme d’authentification ouverte qui vise à renforcer et à simplifier l’authentification à deux facteurs en utilisant des périphériques USB ou à communication en champ proche), exemple des clés USB de type Yubikey.
Non, tu ne peux pas installer tes propres certificats. ’fin ça ne fonctionne pas quoi.
Une banque ne se protégera pas avec un certificat qui n’est pas reconnu out-of-the-box par la majorité des navigateurs du monde. Et ne demandera certainement pas à ses utilisateurs d’installer un certificat random pas reconnu (ça casserait de facto la sécurité).
Et toute la question est là. Une banque n’utilisera pas un certificat/une clef de signature Android qui n’est pas massivement reconnue par tous.
Tu peux faire ta PKI tout seul dans ton coin, mais tu ne peux pas faire de la prod réelle avec des gens non techniques (et pire, avec une sécurité correcte) avec un certificat non reconnu par les navigateurs. Et ça, le libre n’y peut rien.
Dans les autres domaines (DRM dans la musique et la vidéo, protections des consoles, secureboot), toute cette belle théorie s'est toujours fait troué le slip par la pratique.
Absolument pas. TLS et x509 est même la démonstration que « ça marche » et à très grande échelle.
Le problème est « comment devenir une racine de confiance ». Il aura fallu 40 ans à Let's Encrypt pour s’y faire une place. Et très clairement le libre n’y aura eu AUCUNE place pour le coup.
Et avant qu’on ne me tombe dessus, il faut entendre par là que les propriétés du libre n’y ont été d’aucune utilité et n’y sont juste pas possible en pratique. Tu auras beau avoir le code source de LE, pouvoir recompiler le logiciel, pouvoir le redistribuer, tu ne pourras pas refaire LE parce que tu n’es pas une root CA. Et si tu modifies la moindre ligne, tu as toute la certification de LE à repasser pour être à nouveau une root CA.
On n’est pas du tout en train de parler de backdoor, interception, droit root partout & cie qui sont effectivement le rêve humide de la DGSI.
On est juste en train de parler de chaîne de confiance et surtout de racine de confiance et de reconnaissance par les pairs et SURTOUT par les tiers. Et que le libre n’a JAMAIS été capable de mettre en place correctement et ce depuis GPG.
Techniquement : on sait faire sans passer par Google et Apple. Faut « juste » refaire ce que Google fait avec Play Integrity ou ce que Apple fait avec App Attest. C’est de la crypto & cie basique, rien de folichon.
Le problème est après : passer la certif pour arriver à avoir ton attestation approuvée par les banques, et intégrer par les banques. Là déjà, c’est un peu plus coton.
Le faire tout en conservant le côté « libre » des outils : là on est carrément plus proche du mission impossible. Ça suppose aussi de ne pas avoir d’OS rooté de possible par exemple, et que ton OS est qualifié et qu’un utilisateur standard ne doit pas pouvoir le modifier/builder/déployer sans faire sauter la certification.
En fait le problème est le même (en pire) que les autorités de certification de ton navigateur. N’importe qui peut faire la sienne et l’utiliser, éventuellement l’échanger un peu avec le copain d’à côté (CACert). Peu auront la chance de finir dans /etc/ssl/ca-certificates.crt dans Debian ou d’être intégré aux navigateurs. Les process pour y arriver sont trop chers, contraignants, avec des risques assurantiels ou juridiques très importants, du matériel hors de prix à acquérir (HSM…), des salles serveurs sécurisées à mettre en place, des audits annuels à financer et à assurer…
GrapheneOS a typiquement déjà pas mal avancé le boulot mais il faudrait maintenant passer les certifications et inciter les banques à intégrer ce nouveau SDK.
Pour résumer plus simplement, la 2FA niveau bancaire n’est pas que la vérification par le serveur de l’OTP en lui-même, mais aussi la vérification par le serveur du client-même ayant généré l’OTP.
Afin de s’assurer de l’intégrité de toute la chaîne et que le serveur puisse avoir effectivement une bonne certitude de ce qui s’est réellement passé, et en particulier de ce qui aura été affiché par le client.
Pour que la banque puisse avoir une vraie preuve recevable en justice que Mr Machin ne pouvait qu’avoir bien conscience de valider un paiement de 1000€ à AliExpress quand il a validé l’OTP. Avec TOTP tout seul, tu pourrais dire à la banque « ah non, moi j’ai validé 10€ et à Amazon ».
L’OTP seul est limite un élément accessoire dans toute la chaîne.
Que le serveur puisse avoir la garantie que les données contextuelles ont bien été présentées non altérées à celui qui a validé l’OTP est vraiment la partie difficile où le libre n’a pas vraiment de réponse technique viable possible en tout cas actuellement.
Quand tu valides un OTP, ce n’est bien entendu pas le client qui fait la vérification mais le serveur.
La clef est générée côté serveur, est envoyé côté client par un canal CERTIFIÉ à une application CERTIFIÉ (par Google/Apple), qui la stocke dans une enclave CERTIFIÉE géré par un OS CERTIFIÉ et reçoit un token CERTIFIÉ crypto.
Le serveur envoie à ton application (certifiée) les données de contexte (action, montant, destinataire…)
Ton application (certifiée) garantie à la banque que ces données :
ne seront pas altérées
s’afficheront à l’endroit certifié, connu et garanti par la banque, à côté de l’OTP
Ton application (certifiée) transmet à la banque l’OTP, avec une empreinte crypto généré par l’OS (certifié) prouvant que l’application était légitime, non modifiée, et correspondait bien à celle attendue par ta banque
Ta banque vérifie alors À LA FOIS que l’OTP est valide, que ton device est bien celui attendu (signature crypto de ton application avec le token crypto généré à l’enrollement), ET que ton téléphone était safe (signature crypto réalisé par ton OS de l’authenticité de l’application.
La banque a donc la certitude, et la preuve, que :
tu as bien reçu la demande d’OTP et les données contextuelles
ton application était légitime et correspondait à celle fournit par ta banque (pas de modif logiciel)
ton OS était légitime et correspondait à celui livré par ton fournisseur (Google ou Apple)
tu as bien validé l’OTP (2nd facteur d’auth, bio ou code) avec les données nécessairement contextuelles affichées
1+2+3 permet à la banque de certifier que tu as nécessairement eu connaissance des données du 1, affiché exactement à l’endroit attendu, sous la forme attendue, et comme prouvable par le code source détenu par elle, par le téléphone enrollé attendu, 4 que c’était bien toi
La banque peut donc valider l’OTP
Si tu n’as pas 2 et 3, la banque ne peut plus en déduire 4, la 2FA n’est plus valide.
La seule et unique problématique du libre est 2 (incompatible avec le libre) et 3 (difficile à mettre en œuvre sur des OS libres puisqu’il faut les faire certifier et avec une certification reconnue par les banques).
L’existant « bien fait » suppose de revoir la loi. La question n’est pas du tout technique, mais juridique. Et actuellement les choix juridiques ne me semblent pas si déconnants que ça. La fraude a réellement été massive avant l’entrée en vigueur de la DSP2 et je pense que plus ou moins personne ici ne serait content de se faire pouiller son compte en banque sans avoir rien à dire ou à voir ses frais bancaires explosés si la banque devait prendre la fraude à sa charge.
Je suis client, je m'en balec de l'avis de la banque :-)
Oui, sauf que là on est en train de jouer aussi ta responsabilité pénale et financière hein… 🤷 On ne parle pas que de sécurité.
Un OTP légalement valide implique ta responsabilité pleine et entière, en terme pénal et financier.
Un OTP invalide implique celle pleine et entière de la banque.
Tu peux détailler pourquoi tu penses que "lien opération/montant/destinataire" n'est pas établi avec webauthn/TOTP ? (Sachant que les applis mobiles utilisent les mêmes principes…).
Le principe final de génération du code peut être basé sur TOTP. C’est la chaîne complète qui fait que les systèmes standard reposant uniquement sur TOTP ne répondent pas aux obligations légales.
Si tu prends par exemple Aegis sur Android, une banque ne pourrait pas s’en servir.
La seule présence de la fonction de backup de Aegis annihile la certification DSP2. Il requalifie le facteur de possession en facteur de seule connaissance, et donc la 2FA en 1FA.
Le secret est accessible « en clair » dans le téléphone et n’est pas write-only comme dans les applications mobiles bancaires (enclave matérielle généralement) ou en tout cas avec des mesures de protection interdisant l’export du secret sur un autre téléphone.
Ensuite parce que Aegis ne permet pas, ou vraiment pas facilement, d’afficher à côté de l’OTP les données contextuelles (opération réalisée, montant, destinataire…).
Il n’existe aucun moyen, et encore moins certifié permettant à la banque d’envoyer ces infos à Aegis, et de garantir à cette banque que l’accès à l’OTP a été impossible sans voir ces informations, et des informations correctes (typiquement que Aegis n’a pas un bug qui affiche les montants en centimes au lieu d’euro, ou des dollars à la place des euro, ou que le nom d’affichage a été tronqué ou modifié…).
Même à supposer que Aegis ait une telle fonction, étant modifiable par l’utilisateur (puisque logiciel libre), tu pourrais très bien supprimer cette obligation vérifiée/auditée/certifiée par la banque. En cas de contestation, tu reporterais alors la responsabilité pénale et financière sur ta banque, puisque tu pourrais très facilement prouver que tu n’avais pas l’info au moment de l’OTP, ou en tout cas démentir que c’était bien le cas.
Tu comprends maintenant pourquoi les banques veulent aussi s’assurer et de l’authenticité du téléphone (non root) et de l’authenticité de l’application (certification Google ou Apple).
Pour éviter un soft modifié et donc avoir la certitude que ce qu’elles attendent est bien ce qu’il va se passer.
Elles en obtiennent la garantie que l’OTP a été validé par une application certifiée par elles, et dont elles ont même la preuve crypto au moment de la validation de l’OTP que l’application était légitime et non modifié. Elles peuvent donc prouver en cas de contestation que tu ne pouvais qu’avoir connaissance du contexte au moment où tu as validé l’OTP et donc que tu en étais dorénavant le seul responsable pénal et financier. C’est un process littéralement impossible, sinon extrêmement complexe, sur un écosystème libre.
On pourrait très certainement « en théorie » envisager des solutions libres répondant aux problèmes (non répudiabilité, qualification, non modification, envoi et affiche des données contextuelles…), mais « en pratique » complexes, difficiles à certifier, posant des problèmes de compatibilité (Une banque change son SI ? Une législation évolue ? Ah ben va falloir requalifier tout ça…).
Et « en pratique » la banque a du coup tout intérêt à faire sa solution à elle, dans son application à elle, qu’elle maîtrise elle-même, qu’elle certifie elle-même, qu’elle peut modifier quand elle le souhaite, pour y intégrer ce qu’elle veut, le niveau de détail qu’elle veut, plutôt que de se limite au PPCM de l’intégralité du marché. Tout est plus simple, plus contrôlable par elle, etc.
Les téléphones se cassent ou se perdent. On peut même ajouter qu'un téléphone n'est PAS un périphérique de confiance.
La question n’est pas là. Mais que tu as beaucoup plus de chance de prendre soin d’un truc dorénavant omniprésent dans l’intégralité de ta vie quotidienne (à tord ou à raison) que d’un truc qui ne va te servir que 2× dans le mois.
Et le « vrai » problème est surtout le côté « urgence » ou en tout cas non planifié de l’usage de la 2FA. Les périphériques dédiés sont justement dédiés et restreints à un cas d’usage souvent très limité (uniquement chez soi par exemple).
Tu ne peux pas non plus te permettre de te trimballer en permanence avec une valise de matériel dédié sur toi pour chaque usage. Personnellement j’ai 4 banques différentes par la force des choses, et je suis loin d’être le seul (37% de la population a au moins 2 banques).
C’est le côté pratique/omniprésent/dispo partout et en toute circonstance qui fait que le téléphone est plutôt une bonne idée.
On espère toujours ne pas être touché par cette situation, mais par exemple en cas de fraude, un conseiller peut te demander de t’authentifier par 2FA (Boursorama le fait ou en tout cas l’a fait par exemple). Tu n’as pas ton device sur toi ? T’es juste en train de te faire démolir ton compte par un escroc et ton conseiller ne peut pas bloquer les paiements sans ta 2FA. Au contraire le paiement est légitime et la banque suspecte une fraude et l’a bloqué ? Ton conseiller ne le laissera au contraire pas passer sans ton authentification. Ça peut être vite compliqué.
Tu as le plus confiance en quoi? Un téléphone facile à voler avec un android ou pire un iOS privateur et des services tout aussi privateurs ? Un PC de bureau ou un portable avec antivol et un vrai GNU/linux OS libre ?
La question n’est pas ce que TOI tu as le plus confiance mais ce en quoi LA BANQUE a le plus confiance. Cet OTP engage sa responsabilité pénale et financière de ta banque et justement pas (que) la tienne. Si tu parviens à prouver que l’OTP de ta banque ne répond pas aux principes de sécurité légaux, alors ta responsabilité est justement reporté sur la banque (un traitement validé par OTP légal rend irréfutable la responsabilité du client).
Et le problème est là : une banque ne PEUT PAS utiliser un système dont elle n’aurait pas la certification (et les assurances qui vont avec) sur la sécurité du système. Google et Apple les leur apporte. GNU/Linux non.
Et le vol est typiquement inclut dans les modèles de menace des systèmes de 2FA sur mobile (authentification par biométrie ou code personnel nécessaire). C’est bien de la 2FA et non de la 1FA, le seul facteur de possession ne suffisant pas et ne devant pas suffire à valider l’authentification et est couplé à un facteur de connaissance (code) ou d’identité (biométrie).
Je le répète : si les banques aiment les applis mobiles, ce n'est pas pour la sécurité.
Ce n’est pas non plus ce que j’ai dit. C’est essentiellement pour des critères de responsabilité/certification, de contrôle logiciel, et d’assurance. Couplé à des critères de tarif, de disponibilité, de facilité d’accès, de maintenance, etc.
Tout ça mélangé rend le choix du téléphone mobile pas si déconnant en pratique, même si effectivement pose quelques problèmes pour certains cas.
Et à l’inverse les solutions libres ou sur OS libre ou… ne répondent que difficilement aux exigences légales posés (certification, non modification du système, confiance de la banque en le système, contextualisation…).
La BNP propose toujours le MFA par SMS + code secret, donc non toutes les solutions ne sont pas hors jeux.
La BNP est dans l’illégalité (SMS plus reconnu comme 2FA + authentification non contextuelle) et se prend ou se prendra des prunes pour ça et ce système disparaîtra à terme.
C’est un truc qui est effectivement envisageable a priori, mais ça coûte cher et c’est chiant à gérer autant pour les banques que pour les clients. Faut le trimbaler partout avec soit, ça casse, c’est chiant en vacances, etc… Les gens en prennent beaucoup moins soin que leur téléphone, l’oubli, le perde…
Typiquement t’es au boulot, tu veux faire un paiement ou te connecter sur le site de ta banque ? C’est mort, t’as pas ton device…
Et tu le paies 30€. Des téléphones android « bas de gamme » coûtent à peine plus chers pour le coup…
Ça n’impose pas de téléphone, mais le fait que le périphérique soit nécessairement connecté pour traiter la partie dynamique a poussé les banques à passer sur téléphone, le matériel dédié devenant hors de prix et complexe à mettre en œuvre (maintenance, livraison, etc).
Le côté privateur vient avec l’obligation de certification des mécanismes de sécurité, et actuellement seuls les gros (Google et Apple) les ont passé. Et la certification impose « by design » du privateur, ou en tout cas que même un logiciel libre ne puisse pas être modifié (même problème que celui qui s’était posé avec les logiciels de caisse).
Et le côté non standard avec le fait que le système nécessite du coup des interactions avec les SI des banques, qui couplé avec le § précédent rend compliqué d’avoir à passer par un système tiers à certifier ou non certifié, et encore pire sur un système peu courant ou peu contrôler comme Linux (Microsoft ou Apple peuvent éventuellement certifier les softs installés)…
Les banques engagent quand même leur responsabilité pénale et financière sur cette authentification…
Et sur le lien cité, là par contre c’est une interprétation. Le texte réglementaire ne dit pas ça et les propos ne concernait qu’une initiative privée d’un sous-ensemble de prestataire FR (les établissements de la Place française, portés par la Banque de France), le tout nécessitant toujours dans tous les cas de respecter les autres points des articles de la directive (dynamique, certifié, etc).
Toutes les solutions hors téléphone ont fini par se faire dégager pour des raisons de non conformité avec la législation, et à ma connaissance la Banque de France a justement fini par virer cette obligation de fourniture d’un moyen autre.
[…] Le dispositif utilisé pour initier l’opération de paiement […], devraient, par conséquent, inclure l’authentification des opérations par des codes dynamiques, afin que l’utilisateur soit à tout moment conscient du montant et du bénéficiaire de l’opération qu’il autorise.
Article 97(2) de la DSP2
En ce qui concerne l’initiation des opérations de paiement électronique visée au paragraphe 1, point b), les États membres veillent à ce que, pour les opérations de paiement électronique à distance, les prestataires de services de paiement appliquent l’authentification forte du client comprenant des éléments qui établissent un lien dynamique entre l’opération, le montant et le bénéficiaire donnés.
Donc non, ce n’est même pas une interprétation, c’est écrit en dur explicitement dans la directive.
Pour l’anecdote, on rappellera quand même qu’un système est légalement obligé de supporter l’orthographe correct des noms. Sinon violation de l’article 16 du RGPD.
Une banque a déjà été contrainte par une Autorité de Contrôle à modifier tout son système d’information pour supporter les accents. 😊
C’est un peu plus compliqué que juste avoir une clef et la stocker… Cf ici.
Du coup il y a de la communication sécurisée avec leurs backends bancaires, du push notif pour déclencher la 2FA sans exploser ta batterie avec du polling, de la certification de l’OS pour éviter les systèmes compromis (obligation légale, qui explique le recours à Google et Apple pour la couche de sécu)…
[^] # Re: Résumé des arguments à utiliser (quelle que soit la banque d'ailleurs) et des solutions possibles
Posté par Aeris (site web personnel) . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à 0 (+1/-2).
Ben dans ce cas du logiciel propriétaire quoi…
Tu ne peux décemment pas imposer aux banques de faire du libre (ce qui est en plus totalement et légalement impossible dans le cas bancaire justement, puisque t’aurais a minima pas le droit d’exécuter une version modifiée).
[^] # Re: Résumé des arguments à utiliser (quelle que soit la banque d'ailleurs) et des solutions possibles
Posté par Aeris (site web personnel) . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à 1 (+0/-0).
Les listes de sanction sont des obligations légales, et n’ouvrent donc pas le droit à poursuite pour discrimination.
[^] # Re: Résumé des arguments à utiliser (quelle que soit la banque d'ailleurs) et des solutions possibles
Posté par Aeris (site web personnel) . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à 1 (+2/-2).
Sauf qu’un tel truc coûte… plus que le prix d’un téléphone.
[^] # Re: Résumé des arguments à utiliser (quelle que soit la banque d'ailleurs) et des solutions possibles
Posté par Aeris (site web personnel) . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à 0 (+1/-2).
Il n’y a aucune obscurité ici. Tout est documenté et parfaitement accessible et reproductible.
Sauf que tu ne verras jamais la clef privée de signature du matériel et de l’OS reconnu par les banques.
C’est un pur problème d’autorité de confiance, et pas de soft.
[^] # Re: Résumé des arguments à utiliser (quelle que soit la banque d'ailleurs) et des solutions possibles
Posté par Aeris (site web personnel) . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à 1 (+1/-1). Dernière modification le 10 février 2026 à 10:18.
Se rendre sur ton espace client n’est pas une 2FA mais une 1FA. Et est lui-même soumis à SCA.
Pour se connecter en 2FA à ton espace client il te faudra… valider la SCA sur ton mobile. Retour au point de départ.
Comme dit, TOTP n’est pas contextuel et ne permet donc pas de remplir les obligations légales de la SCA DSP2/3.
[^] # Re: Résumé des arguments à utiliser (quelle que soit la banque d'ailleurs) et des solutions possibles
Posté par Aeris (site web personnel) . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à 1 (+1/-1). Dernière modification le 10 février 2026 à 10:18.
Non, puisque les banques doivent avoir la certitude d’une application non modifiée et non modifiable. C’est pour ça qu’elles refusent actuellement les téléphones rootés et toute modif à même d’avoir altéré le fonctionnement de la SCA.
Et le passage sur les téléphones leur permet justement un contrôle au niveau matériel.
Et les systèmes alternatifs n’arriveront jamais à se faire reconnaître « de confiance », surtout sans les moyens financiers des assurances qui vont derrière (s’il y a de la fraude à cause de ton système de certif, c’est toi qui paie la fraude, pas les banques)
https://grapheneos.org/articles/attestation-compatibility-guide
[^] # Re: Résumé des arguments à utiliser (quelle que soit la banque d'ailleurs) et des solutions possibles
Posté par Aeris (site web personnel) . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à 1 (+1/-1).
Parce que la DSP3 impose dorénavant une connexion Internet pour récupérer ce contextuel
[^] # Re: Résumé des arguments à utiliser (quelle que soit la banque d'ailleurs) et des solutions possibles
Posté par Aeris (site web personnel) . En réponse au journal Boursorama semble dorénavant imposer l'usage d'un smartphone pour utiliser ses services. Évalué à 2 (+1/-0).
Arguments
Qui ne respectent pas la notion de SCA contextuelle bancaire (action, montant & destinataire)
Mais la banque a une obligation légale à fournir une SCA légale (DSP3)
Mais la banque est concernée elle-même par une obligation légale qui est supérieure à ses CGUE
Idem
Pas le problème de la banque
Parce que plus légales. Ne l’était déjà plus depuis longtemps pour la plupart (SMS, calculette, code fixe…). Les exigences DSP3 ont fait sauter tout le reste.
Solutions envisageables :
Non, pas contextuel
Pas contextuel ou plus fiable (SMS)
Pas contextuel, illégal
Pas contextuel, illégal
[^] # Re: pas prêt pour le grand public
Posté par Aeris (site web personnel) . En réponse au journal De la migration d’une instance Mastodon à une autre et ses effets secondaires. Évalué à 2.
Instances that block mastodon.social
federated_timeline_removal (94)
followers_only (241)
reject (199)
quarantined_instances (5)
# Celui-là ?
Posté par Aeris (site web personnel) . En réponse au journal L’informatique, ce truc de jeune (!?). Évalué à 10.
https://lunatopia.fr/blog/les-gamins-ne-savent-pas-utiliser-les-ordinateurs
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 2. Dernière modification le 14 septembre 2024 à 20:54.
Non, tu ne peux pas installer tes propres certificats. ’fin ça ne fonctionne pas quoi.
Une banque ne se protégera pas avec un certificat qui n’est pas reconnu out-of-the-box par la majorité des navigateurs du monde. Et ne demandera certainement pas à ses utilisateurs d’installer un certificat random pas reconnu (ça casserait de facto la sécurité).
Et toute la question est là. Une banque n’utilisera pas un certificat/une clef de signature Android qui n’est pas massivement reconnue par tous.
Tu peux faire ta PKI tout seul dans ton coin, mais tu ne peux pas faire de la prod réelle avec des gens non techniques (et pire, avec une sécurité correcte) avec un certificat non reconnu par les navigateurs. Et ça, le libre n’y peut rien.
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 2. Dernière modification le 14 septembre 2024 à 00:11.
Absolument pas. TLS et x509 est même la démonstration que « ça marche » et à très grande échelle.
Le problème est « comment devenir une racine de confiance ». Il aura fallu 40 ans à Let's Encrypt pour s’y faire une place. Et très clairement le libre n’y aura eu AUCUNE place pour le coup.
Et avant qu’on ne me tombe dessus, il faut entendre par là que les propriétés du libre n’y ont été d’aucune utilité et n’y sont juste pas possible en pratique. Tu auras beau avoir le code source de LE, pouvoir recompiler le logiciel, pouvoir le redistribuer, tu ne pourras pas refaire LE parce que tu n’es pas une root CA. Et si tu modifies la moindre ligne, tu as toute la certification de LE à repasser pour être à nouveau une root CA.
On n’est pas du tout en train de parler de backdoor, interception, droit root partout & cie qui sont effectivement le rêve humide de la DGSI.
On est juste en train de parler de chaîne de confiance et surtout de racine de confiance et de reconnaissance par les pairs et SURTOUT par les tiers. Et que le libre n’a JAMAIS été capable de mettre en place correctement et ce depuis GPG.
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 1. Dernière modification le 13 septembre 2024 à 17:53.
Techniquement : on sait faire sans passer par Google et Apple. Faut « juste » refaire ce que Google fait avec Play Integrity ou ce que Apple fait avec App Attest. C’est de la crypto & cie basique, rien de folichon.
Le problème est après : passer la certif pour arriver à avoir ton attestation approuvée par les banques, et intégrer par les banques. Là déjà, c’est un peu plus coton.
Le faire tout en conservant le côté « libre » des outils : là on est carrément plus proche du mission impossible. Ça suppose aussi de ne pas avoir d’OS rooté de possible par exemple, et que ton OS est qualifié et qu’un utilisateur standard ne doit pas pouvoir le modifier/builder/déployer sans faire sauter la certification.
En fait le problème est le même (en pire) que les autorités de certification de ton navigateur. N’importe qui peut faire la sienne et l’utiliser, éventuellement l’échanger un peu avec le copain d’à côté (CACert). Peu auront la chance de finir dans /etc/ssl/ca-certificates.crt dans Debian ou d’être intégré aux navigateurs. Les process pour y arriver sont trop chers, contraignants, avec des risques assurantiels ou juridiques très importants, du matériel hors de prix à acquérir (HSM…), des salles serveurs sécurisées à mettre en place, des audits annuels à financer et à assurer…
GrapheneOS a typiquement déjà pas mal avancé le boulot mais il faudrait maintenant passer les certifications et inciter les banques à intégrer ce nouveau SDK.
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 1. Dernière modification le 13 septembre 2024 à 16:40.
Pour résumer plus simplement, la 2FA niveau bancaire n’est pas que la vérification par le serveur de l’OTP en lui-même, mais aussi la vérification par le serveur du client-même ayant généré l’OTP.
Afin de s’assurer de l’intégrité de toute la chaîne et que le serveur puisse avoir effectivement une bonne certitude de ce qui s’est réellement passé, et en particulier de ce qui aura été affiché par le client.
Pour que la banque puisse avoir une vraie preuve recevable en justice que Mr Machin ne pouvait qu’avoir bien conscience de valider un paiement de 1000€ à AliExpress quand il a validé l’OTP. Avec TOTP tout seul, tu pourrais dire à la banque « ah non, moi j’ai validé 10€ et à Amazon ».
L’OTP seul est limite un élément accessoire dans toute la chaîne.
Que le serveur puisse avoir la garantie que les données contextuelles ont bien été présentées non altérées à celui qui a validé l’OTP est vraiment la partie difficile où le libre n’a pas vraiment de réponse technique viable possible en tout cas actuellement.
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 2.
Tu ne comprends en effet toujours pas.
Quand tu valides un OTP, ce n’est bien entendu pas le client qui fait la vérification mais le serveur.
La clef est générée côté serveur, est envoyé côté client par un canal CERTIFIÉ à une application CERTIFIÉ (par Google/Apple), qui la stocke dans une enclave CERTIFIÉE géré par un OS CERTIFIÉ et reçoit un token CERTIFIÉ crypto.
La banque a donc la certitude, et la preuve, que :
tu as bien validé l’OTP (2nd facteur d’auth, bio ou code) avec les données nécessairement contextuelles affichées
1+2+3 permet à la banque de certifier que tu as nécessairement eu connaissance des données du 1, affiché exactement à l’endroit attendu, sous la forme attendue, et comme prouvable par le code source détenu par elle, par le téléphone enrollé attendu, 4 que c’était bien toi
La banque peut donc valider l’OTP
Si tu n’as pas 2 et 3, la banque ne peut plus en déduire 4, la 2FA n’est plus valide.
La seule et unique problématique du libre est 2 (incompatible avec le libre) et 3 (difficile à mettre en œuvre sur des OS libres puisqu’il faut les faire certifier et avec une certification reconnue par les banques).
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 1.
L’existant « bien fait » suppose de revoir la loi. La question n’est pas du tout technique, mais juridique. Et actuellement les choix juridiques ne me semblent pas si déconnants que ça. La fraude a réellement été massive avant l’entrée en vigueur de la DSP2 et je pense que plus ou moins personne ici ne serait content de se faire pouiller son compte en banque sans avoir rien à dire ou à voir ses frais bancaires explosés si la banque devait prendre la fraude à sa charge.
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 1. Dernière modification le 13 septembre 2024 à 15:01.
Oui, sauf que là on est en train de jouer aussi ta responsabilité pénale et financière hein… 🤷 On ne parle pas que de sécurité.
Un OTP légalement valide implique ta responsabilité pleine et entière, en terme pénal et financier.
Un OTP invalide implique celle pleine et entière de la banque.
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 2.
Le principe final de génération du code peut être basé sur TOTP. C’est la chaîne complète qui fait que les systèmes standard reposant uniquement sur TOTP ne répondent pas aux obligations légales.
Si tu prends par exemple Aegis sur Android, une banque ne pourrait pas s’en servir.
La seule présence de la fonction de backup de Aegis annihile la certification DSP2. Il requalifie le facteur de possession en facteur de seule connaissance, et donc la 2FA en 1FA.
Le secret est accessible « en clair » dans le téléphone et n’est pas write-only comme dans les applications mobiles bancaires (enclave matérielle généralement) ou en tout cas avec des mesures de protection interdisant l’export du secret sur un autre téléphone.
Ensuite parce que Aegis ne permet pas, ou vraiment pas facilement, d’afficher à côté de l’OTP les données contextuelles (opération réalisée, montant, destinataire…).
Il n’existe aucun moyen, et encore moins certifié permettant à la banque d’envoyer ces infos à Aegis, et de garantir à cette banque que l’accès à l’OTP a été impossible sans voir ces informations, et des informations correctes (typiquement que Aegis n’a pas un bug qui affiche les montants en centimes au lieu d’euro, ou des dollars à la place des euro, ou que le nom d’affichage a été tronqué ou modifié…).
Même à supposer que Aegis ait une telle fonction, étant modifiable par l’utilisateur (puisque logiciel libre), tu pourrais très bien supprimer cette obligation vérifiée/auditée/certifiée par la banque. En cas de contestation, tu reporterais alors la responsabilité pénale et financière sur ta banque, puisque tu pourrais très facilement prouver que tu n’avais pas l’info au moment de l’OTP, ou en tout cas démentir que c’était bien le cas.
Tu comprends maintenant pourquoi les banques veulent aussi s’assurer et de l’authenticité du téléphone (non root) et de l’authenticité de l’application (certification Google ou Apple).
Pour éviter un soft modifié et donc avoir la certitude que ce qu’elles attendent est bien ce qu’il va se passer.
Elles en obtiennent la garantie que l’OTP a été validé par une application certifiée par elles, et dont elles ont même la preuve crypto au moment de la validation de l’OTP que l’application était légitime et non modifié. Elles peuvent donc prouver en cas de contestation que tu ne pouvais qu’avoir connaissance du contexte au moment où tu as validé l’OTP et donc que tu en étais dorénavant le seul responsable pénal et financier. C’est un process littéralement impossible, sinon extrêmement complexe, sur un écosystème libre.
On pourrait très certainement « en théorie » envisager des solutions libres répondant aux problèmes (non répudiabilité, qualification, non modification, envoi et affiche des données contextuelles…), mais « en pratique » complexes, difficiles à certifier, posant des problèmes de compatibilité (Une banque change son SI ? Une législation évolue ? Ah ben va falloir requalifier tout ça…).
Et « en pratique » la banque a du coup tout intérêt à faire sa solution à elle, dans son application à elle, qu’elle maîtrise elle-même, qu’elle certifie elle-même, qu’elle peut modifier quand elle le souhaite, pour y intégrer ce qu’elle veut, le niveau de détail qu’elle veut, plutôt que de se limite au PPCM de l’intégralité du marché. Tout est plus simple, plus contrôlable par elle, etc.
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 2.
La question n’est pas là. Mais que tu as beaucoup plus de chance de prendre soin d’un truc dorénavant omniprésent dans l’intégralité de ta vie quotidienne (à tord ou à raison) que d’un truc qui ne va te servir que 2× dans le mois.
Et le « vrai » problème est surtout le côté « urgence » ou en tout cas non planifié de l’usage de la 2FA. Les périphériques dédiés sont justement dédiés et restreints à un cas d’usage souvent très limité (uniquement chez soi par exemple).
Tu ne peux pas non plus te permettre de te trimballer en permanence avec une valise de matériel dédié sur toi pour chaque usage. Personnellement j’ai 4 banques différentes par la force des choses, et je suis loin d’être le seul (37% de la population a au moins 2 banques).
C’est le côté pratique/omniprésent/dispo partout et en toute circonstance qui fait que le téléphone est plutôt une bonne idée.
On espère toujours ne pas être touché par cette situation, mais par exemple en cas de fraude, un conseiller peut te demander de t’authentifier par 2FA (Boursorama le fait ou en tout cas l’a fait par exemple). Tu n’as pas ton device sur toi ? T’es juste en train de te faire démolir ton compte par un escroc et ton conseiller ne peut pas bloquer les paiements sans ta 2FA. Au contraire le paiement est légitime et la banque suspecte une fraude et l’a bloqué ? Ton conseiller ne le laissera au contraire pas passer sans ton authentification. Ça peut être vite compliqué.
La question n’est pas ce que TOI tu as le plus confiance mais ce en quoi LA BANQUE a le plus confiance. Cet OTP engage sa responsabilité pénale et financière de ta banque et justement pas (que) la tienne. Si tu parviens à prouver que l’OTP de ta banque ne répond pas aux principes de sécurité légaux, alors ta responsabilité est justement reporté sur la banque (un traitement validé par OTP légal rend irréfutable la responsabilité du client).
Et le problème est là : une banque ne PEUT PAS utiliser un système dont elle n’aurait pas la certification (et les assurances qui vont avec) sur la sécurité du système. Google et Apple les leur apporte. GNU/Linux non.
Et le vol est typiquement inclut dans les modèles de menace des systèmes de 2FA sur mobile (authentification par biométrie ou code personnel nécessaire). C’est bien de la 2FA et non de la 1FA, le seul facteur de possession ne suffisant pas et ne devant pas suffire à valider l’authentification et est couplé à un facteur de connaissance (code) ou d’identité (biométrie).
Ce n’est pas non plus ce que j’ai dit. C’est essentiellement pour des critères de responsabilité/certification, de contrôle logiciel, et d’assurance. Couplé à des critères de tarif, de disponibilité, de facilité d’accès, de maintenance, etc.
Tout ça mélangé rend le choix du téléphone mobile pas si déconnant en pratique, même si effectivement pose quelques problèmes pour certains cas.
Et à l’inverse les solutions libres ou sur OS libre ou… ne répondent que difficilement aux exigences légales posés (certification, non modification du système, confiance de la banque en le système, contextualisation…).
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 3. Dernière modification le 13 septembre 2024 à 12:15.
La BNP est dans l’illégalité (SMS plus reconnu comme 2FA + authentification non contextuelle) et se prend ou se prendra des prunes pour ça et ce système disparaîtra à terme.
C’est un truc qui est effectivement envisageable a priori, mais ça coûte cher et c’est chiant à gérer autant pour les banques que pour les clients. Faut le trimbaler partout avec soit, ça casse, c’est chiant en vacances, etc… Les gens en prennent beaucoup moins soin que leur téléphone, l’oubli, le perde…
Typiquement t’es au boulot, tu veux faire un paiement ou te connecter sur le site de ta banque ? C’est mort, t’as pas ton device…
Et tu le paies 30€. Des téléphones android « bas de gamme » coûtent à peine plus chers pour le coup…
Non conforme (non contextuel), ils doivent se prendre des amendes aussi du coup, et ça disparaîtra à terme
Comme expliqué, le côté lien dynamique (lien opération/montant/destinataire) interdit légalement ce type de solution.
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 1. Dernière modification le 13 septembre 2024 à 11:13.
Ça n’impose pas de téléphone, mais le fait que le périphérique soit nécessairement connecté pour traiter la partie dynamique a poussé les banques à passer sur téléphone, le matériel dédié devenant hors de prix et complexe à mettre en œuvre (maintenance, livraison, etc).
Le côté privateur vient avec l’obligation de certification des mécanismes de sécurité, et actuellement seuls les gros (Google et Apple) les ont passé. Et la certification impose « by design » du privateur, ou en tout cas que même un logiciel libre ne puisse pas être modifié (même problème que celui qui s’était posé avec les logiciels de caisse).
Et le côté non standard avec le fait que le système nécessite du coup des interactions avec les SI des banques, qui couplé avec le § précédent rend compliqué d’avoir à passer par un système tiers à certifier ou non certifié, et encore pire sur un système peu courant ou peu contrôler comme Linux (Microsoft ou Apple peuvent éventuellement certifier les softs installés)…
Les banques engagent quand même leur responsabilité pénale et financière sur cette authentification…
Et sur le lien cité, là par contre c’est une interprétation. Le texte réglementaire ne dit pas ça et les propos ne concernait qu’une initiative privée d’un sous-ensemble de prestataire FR (les établissements de la Place française, portés par la Banque de France), le tout nécessitant toujours dans tous les cas de respecter les autres points des articles de la directive (dynamique, certifié, etc).
Toutes les solutions hors téléphone ont fini par se faire dégager pour des raisons de non conformité avec la législation, et à ma connaissance la Banque de France a justement fini par virer cette obligation de fourniture d’un moyen autre.
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 1.
Pour le cas des banques, en tout cas ça l’est
https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2018_4039
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 1.
https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX%3A32015L2366%3Afr%3AHTML
Considérant 95 de la DSP2
[…] Le dispositif utilisé pour initier l’opération de paiement […], devraient, par conséquent, inclure l’authentification des opérations par des codes dynamiques, afin que l’utilisateur soit à tout moment conscient du montant et du bénéficiaire de l’opération qu’il autorise.
Article 97(2) de la DSP2
En ce qui concerne l’initiation des opérations de paiement électronique visée au paragraphe 1, point b), les États membres veillent à ce que, pour les opérations de paiement électronique à distance, les prestataires de services de paiement appliquent l’authentification forte du client comprenant des éléments qui établissent un lien dynamique entre l’opération, le montant et le bénéficiaire donnés.
Donc non, ce n’est même pas une interprétation, c’est écrit en dur explicitement dans la directive.
# Violation RGPD
Posté par Aeris (site web personnel) . En réponse au journal Les caractères accentués dans les logiciels d'ENT. Évalué à 10.
Pour l’anecdote, on rappellera quand même qu’un système est légalement obligé de supporter l’orthographe correct des noms. Sinon violation de l’article 16 du RGPD.
Une banque a déjà été contrainte par une Autorité de Contrôle à modifier tout son système d’information pour supporter les accents. 😊
https://gdprhub.eu/index.php?title=Court_of_Appeal_of_Brussels_-_2019/AR/1006
[^] # Re: pétition
Posté par Aeris (site web personnel) . En réponse à la dépêche Démarches administratives et fracture numérique. Évalué à 1. Dernière modification le 11 septembre 2024 à 19:33.
C’est un peu plus compliqué que juste avoir une clef et la stocker… Cf ici.
Du coup il y a de la communication sécurisée avec leurs backends bancaires, du push notif pour déclencher la 2FA sans exploser ta batterie avec du polling, de la certification de l’OS pour éviter les systèmes compromis (obligation légale, qui explique le recours à Google et Apple pour la couche de sécu)…