Avec la numérisation très rapide des services administratifs français est arrivé le besoin d’authentifier et certifier à distance une personne faisant une démarche avec des outils numériques officiels.
La certification à distance est un problème déjà traité depuis longtemps sur internet. Que ce soit sur LinuxFr.org ou sur un site marchand, « s’enregistrer en ligne » est un acte banal pour beaucoup de monde, effectué machinalement pour certains, ou consciemment et mûrement réfléchi pour d’autres. Lorsqu’il s’agit d’élargir cette certification d’identité à l’ensemble de la population, afin qu’elle puisse accéder à des services auxquels tout à chacun à droit, on peut s’interroger sur les moyens mis en œuvre pour cela.
Puisqu’il s’agit de l’administration publique et non d’un service privé, ils devraient reposer sur des outils ouverts et auditables par la société civile, accessibles à toutes et à tous en termes de moyens et sans dépendances exagérées envers des tierces parties.
Sommaire
- Authentifier une personne vis-à-vis de l’administration publique
- Les problèmes posés
- Les solutions officielles
- Des solutions standard, accessibles et ouvertes !
- Des démarches pour alerter
Authentifier une personne vis-à-vis de l’administration publique
Pour valider certaines démarches le choix a été fait d’utiliser une application mobile : France Connect + à ne pas confondre avec « France Connect ». Le service « France Connect » quant à lui, permet l’authentification basique pour des sites administratifs que ce soit sur application mobile ou sur le web. Cette authentification par « France Connect » permet aux personnes d’accéder à des données sensibles le concernant : imposition, patrimoine, santé, etc.
L’application France Connect + est aujourd’hui obligatoire pour les démarches suivantes :
- CPF : Compte personnel de formation, formation ou certains permis ;
- ANTS : l'Agence Nationale des titres Sécurisé, procuration de vote… ;
- INPI : Institut national de la propriété industrielle, guichet unique… ;
- MaPrim'Renov
et exige d’avoir le dernier modèle de Carte Nationale d’Identité, comportant des données biométriques.
La facilité de mise en œuvre d’une application mobile pour l’authentification forte ne va pas sans contreparties qui n’ont pas toutes été prises en compte.
Les problèmes posés
Une application mobile imposée par l’administration aux usagers, devrait être développée pour tous les OS mobiles existants. Aujourd’hui, seuls les OS majoritaires, Android de Google et iOS d’Apple, parfois exclusivement dans leurs dernières versions, sont prises en compte, pour des raisons de coût et de temps.
Ceci exclut toutes les personnes ayant fait un choix différent, volontairement ou par contrainte personnelle : pas de smartphone, smartphone (système et matériel) spécifique adapté à un handicap, smartphone ancien toujours fonctionnel et pas envie d’y consacrer plus d’argent pour obtenir la dernière version du système, OS alternatif, etc.
Ces deux systèmes d’exploitation mobiles majoritaires étant américains, cela remet donc l’authentification pour des démarches officielles entre les mains et les CGV d’entreprises privées, hors d’Europe.
Entreprises dont vous pouvez vouloir ne pas dépendre parce que leurs conditions d’utilisation ne vous conviennent pas :
- obligation de créer un compte sur leur plateforme ;
- obligation de donner des informations personnelles à associer au compte (numéro de téléphone, e-mail de secours…) ;
- elles ont droit de vie et de mort sur vos données hébergées, sur votre compte qu’elles peuvent supprimer pour toute raison qu’elles estiment valable sans aucun recours possible [8] ;
- elles sont connues pour contourner régulièrement les lois sur la vie privée.
Cela pose aussi des problèmes techniques et de sécurité avec une identité validée qui se promène sur un appareil mobile qui peut être volé, perdu ou simplement hors d’usage.
On retrouve dans cette limitation les mêmes problèmes qu’à l’époque des applications PC liées à du matériel et développées uniquement pour le système commercial le plus connu, Windows. Parfois, pour le deuxième plus connu, MacOS, mais pas les autres ; de même que pour la certification DSP2 des banques qui oblige la double authentification forte ; ces dernières ayant choisi de développer chacune une application mobile privée, souvent indiscrète, au lieu d’utiliser les standards existants.
Ainsi, à ce jour, les applications bancaires ne sont disponibles que sur les deux plateformes mobiles déjà citées et leurs versions les plus récentes, laissant de côté de nombreuses personnes.
Les solutions officielles
Certains dossiers CPF peuvent apparemment être transmis par courrier, avec un délai élevé pour leur prise en compte. [2]
L’INPI suggère d’utiliser les services de sociétés tierces [4], payants et difficiles à utiliser [9], parfois hors Europe et demandant aussi l’utilisation d’un smartphone pour certaines.
Cela ne résout donc rien et les sommes demandées peuvent être importantes pour une signature électronique certifiée eiDAS alors que l’application mobile officielle et son utilisation sont gratuites.
Comme le racontent les journaux en lien certaines démarches proposent des alternatives hors France Connect + mais qui demandent quand même un smartphone Android / iOS !
L’identité numérique de La Poste demande aussi un smartphone dans les mêmes conditions, la validation en bureau de poste ou à domicile se fait avec leur application, encore une fois Android et iOS puis l’application France Connect + ; les agents ne sont pas formés pour répondre à des demandes de solutions alternatives hélas.
Des solutions standard, accessibles et ouvertes !
Comme souvent, tout ce que nous souhaitons c’est la possibilité d’utiliser tous ces services officiels et publics avec nos logiciels de choix, accessibles à toutes et tous ; avec tout autant de sécurité et de praticité que les autres solutions.
Il existe déjà des standards pour la double authentification, pas toujours pris en charge hélas. La même chose devrait pouvoir être faite pour l’authentification forte.
L’idéal serait une plateforme standardisée, publique, auditable, qui permettrait d’utiliser des protocoles standards et sécurisés avec le logiciel/matériel de notre choix.
Des démarches pour alerter
Voici un état des lieux assez rapide pour intéresser au sujet et regrouper les témoignages éventuels, des solutions qui fonctionnent ou ne fonctionnent pas.
L’objectif maintenant, en plus d’avoir pour chacune des personnes concernées une solution qui fonctionne rapidement, d’alerter sur cette fracture numérique créée par des décisions politiques ; ce n’est pas une fracture naturelle liée à une différence de générations : celles nées avec le numérique et celles qui ne le sont pas. Il faut la traiter aussi mais ce n’est pas la même chose.
Si vous avez des suggestions pour attirer l’attention sur ce sujet, n’hésitez pas à vous exprimer :)
Aller plus loin
- Bande dessinée (Gee): FranceConnect+ ou GafamConnect+ ? (176 clics)
- Journal: CPF, sans courrier, ni identité numérique, ni smartphone: idées? (80 clics)
- Journal: L'Identité Numérique de la Poste, mal sécurisée mais au moins elle ne marche pas (60 clics)
- Comment obtenir un certificat de signature électronique ? (81 clics)
- Forum: Signature électronique qualifiée (33 clics)
- Podcast: Ça y est, je suis un fracturé du numérique (37 clics)
- Journal: France Connect Plusse (39 clics)
- «Google a fermé mon compte pour avoir partagé des archives historiques [...]» (70 clics)
- Impossible de signer une démarche sur l'INPI sans smartphone (30 clics)
# Erreur concernant ants.gouv.fr et FranceConnect+
Posté par letuxmasque (site web personnel) . Évalué à 6 (+6/-0). Dernière modification le 31 août 2024 à 10:24.
Bonjour,
Je vous signale une petite erreur dans l'introduction concernant la nécessité d'utiliser FranceConnect+ avec ANTS.
L'accès à ants.gouv.fr peut se faire avec un compte créé directement sur la plateforme ou avec FranceConnect (et non FranceConnect+).
Aujourd'hui, l'utilisation de FranceConnect+ est nécessaire lors de :
- Demande de formation sur Mon Compte Formation.
- Démarche de modification ou cessation d’entreprise sur Guichet Unique Entreprise.
- Aide de l’État pour la rénovation énergétique sur MaPrimeRénov’.
Source : https://franceconnect.gouv.fr/franceconnect-plus
[^] # Re: Erreur concernant ants.gouv.fr et FranceConnect+
Posté par Epy . Évalué à 2 (+0/-0).
Merci pour l'info, il me semblait avoir lu que certaines opérations sur le site de l'ANTS (après authentification avec France Connect) demandaient France Connect + pour leur validation.
À revérifier
# internet plutôt que téléphone portable
Posté par pvincent . Évalué à 5 (+7/-3).
Bonjour,
merci pour cet article, je valide pour avoir moi aussi expérimenté le même problème, et toujours pas de solution.
J'attire l'attention sur la phrase :
Selon moi, il ne faudrait pas prôner l'utilisation exclusive d'un OS mobile (besoin d'un orditél). Plutôt proposer une solution qui fonctionne depuis n'importe quel poste Internet (Firefox, navigation privée, ordi quelconque…). Pourquoi vouloir à tout prix nous imposer l'utilisation d'un téléphone portable ? Je ne suis pas capable de le prouver, mais je pense que si l'état (et les services de renseignements) nous astreins ce choix, c'est parce que c'est un outil totalement adapté à la surveillance. Rien de plus facile que de tracer une personne, d'associer le numéro de SIM à l'identité d'une personne et pourquoi pas de l'enregistrer à son insu.
Bref, nous manquons d'esprit critique à ce sujet : un orditél ne devrait pas être nécessaire pour réaliser une démarche administrative.
Par ailleurs, j'ai récemment éprouvé la même difficulté avec les solutions bancaires (bien françaises). Impossible d'avoir accès à certaines fonctionnalités depuis le site web, il faut impérativement installer l'appli mobile signée par les 2 seules entreprises américaines (Android, iOs) et donc posséder un orditel (et une carte SIM valide). Le problème n'est pas technique : la fonctionnalité pourrait exister depuis leur site web. Donc ce choix est délibéré. L'ironie, c'est la réponse de la banque qui justifie par des raisons de sécurité et de normes européennes. [À demi-mot, on comprend que l'OTAN pilote la commission européenne].
Ma suggestion
[^] # Re: internet plutôt que téléphone portable
Posté par Craig77 . Évalué à 8 (+7/-0).
Concernant les banques, elles ne font pas toutes appel à une appli obligatoire. Je suis chez boursobank et je n'ai pas besoin d'appli, le site web fonctionne très bien. J'ai une double authentification, code + sms, parfois triple (+ email), et on peut configurer une clef FIDO.
[^] # Re: internet plutôt que téléphone portable
Posté par tkr (Mastodon) . Évalué à 4 (+5/-2).
par contre, une personne équipée d'ordinateur + internet uniquement, sans aucun tel portable, est foutue :
c'est ça, que je trouve scandaleux.
pire encore :
une personne qui n'a aucun écran chez elle (ça existe, heureusement : c'est encore un droit, une liberté fondamentale), est considérée comme exclue, de facto.
l'informatique/internet doit être considéré comme une technologie alternative, pour accompagner ; pas pour remplacer.
[^] # Re: internet plutôt que téléphone portable
Posté par mrintrepide . Évalué à 4 (+4/-0). Dernière modification le 31 août 2024 à 13:34.
En plus de la validation de l'utilisateur, ça permet théoriquement le non dédoublement.
L'opérateur mobile à déjà la correspondance et doit le fournir l'état depuis toujours.
France Connect et les services étatique l’utilisant savent déjà qui on est, la banque aussi.
Avec a, b et c des nombres, si a≠b alors a=c ?
Source
[^] # Re: internet plutôt que téléphone portable
Posté par Epy . Évalué à 4 (+2/-0).
C'est ce qui est dit dans le paragraphe « Des solutions standard, accessibles et ouvertes ! » ça ne suggère pas l'utilisation obligatoire d'une application mobile justement parce qu'on expose le fait que ça ne fonctionne pas pour inclure tout le monde.
[^] # Re: internet plutôt que téléphone portable
Posté par Aeris (site web personnel) . Évalué à 5 (+4/-0).
2 voire 3 des conditions sont difficilement possibles pour la DSP2 par exemple, et c’est globalement pareil pour les autres besoins
ouvertes : Les obligations de certifications sont assez incompatibles avec ce concept, toute modification du système devant être strictement impossible. Ça rend l’ouverture rapidement inutile ou n’apportant rien réellement au système
standard : L’intégration nécessite un accès privilégié aux SI des banques (2FA dite « contextuelle » nécessitant d’obtenir des informations type action/montant/destinataire), difficile d’y mettre en œuvre des trucs « standard », chacun devant développer sa couche d’intégration et préfère du coup faire du custom à sa sauce que de chercher une interface commune avec tout le monde.
accessibles : Lié au 1er point, la certification des solutions d’authentification coûte (très) chère, en particulier en terme d’assurance (qu’est-ce qu’on doit possiblement payer/rembourser si le système merde vu qu’on en endosse la responsabilité). Du coup double problème pour avoir un système « accessible ». Avoir suffisamment de part de marché pour rendre intéressant de certifier un système par les banques par exemple, et de l’autre côté difficulté à financer la certification pour les systèmes non pris en charge par les précédents.
[^] # Re: internet plutôt que téléphone portable
Posté par Argon . Évalué à 5 (+4/-0).
Un téléphone est plus simple à utiliser et moins cher qu'un ordinateur pour une puissance qui s'est démultiplié au fil du temps. Les applications de téléphones sont plus simples à utiliser que leurs versions web. Reste les personnes âgées qui ont du mal avec un tactile mais là encore des solutions existes plus simple qu'un ordinateur à l'ancienne voilà tout.
Je pourrais même dire que d'une manière générale les téléphones sont plus facilement "sécurisable" qu'un ordinateur pour un utilisateur lambda.
Oui ce que je dis va hérisser le poil de beaucoup mais c'est en fait la réalité de 90% des gens face à un outils informatique/technologique.
de même que nous profitons des avantages que nous apportent les inventions d'autres, nous devrions être heureux d'avoir l'opportunité de servir les autres au moyen de nos propres inventions ;et nous devrions faire cela gratuitement et avec générosité
# Les solutions techniques
Posté par mrintrepide . Évalué à 3 (+3/-0).
Puisque la double authentification avec SMS seul est déconseillée (sim swaping, interception, sécurisation, etc…), email pour raison similaire et le TOTP qui est duplicable, quelles sont les solutions libres connues à ce stade ?
WebAuthn avec FIDO/TPM/TEE ?
[^] # Re: Les solutions techniques
Posté par Aeris (site web personnel) . Évalué à 1 (+1/-1).
Non contextuel, donc non utilisable dans le cadre de la DSP2 par exemple.
[^] # Re: Les solutions techniques
Posté par verdesroches (site web personnel) . Évalué à 2 (+2/-0).
En Belgique ils peuvent s'authentifier avec leur carte d'identité (à puce depuis… 2002) via n'importe quel ordinateur qui dispose d'un lecteur de carte à puce. Ce type de lecteur se trouve pour moins de 20€ sur internet sur ces sites européens.
Rien n'interdirait de faire de même en France, puisque nos nouvelles CNI disposent d'une telle puce (exploitée actuellement via NFC pour les smartphones, la partie puce physique n'est a ma connaissance par exploitable pour un particulier).
# pétition
Posté par tkr (Mastodon) . Évalué à 1 (+0/-0). Dernière modification le 31 août 2024 à 15:12.
ne pouvant pas éditer mon commentaire, ni en rajouter un (les délais et linuxfr……) , je rajoute ici le lien vers mon post de l'époque :
https://linuxfr.org/nodes/134947/comments/1951875
bien qu'il fasse l'objet de quatre "votes positifs", et que la pétition compte une dizaine de signatures, j'ai opté pour un service par les chatons pour sa suite (ayant déjà vu moult exemples de pétitions fermées sur change.org) :
https://pytition.ethibox.fr/petition/user/tkr9/permettre-lusage-du-cpf-sans-passer-par-un-smartphone-ni-le-courrier
attention, celle ci ne concerne que la problématique du CPF.
je signerai volontiers si quelqu'un tentait d'en faire une élargissant à toutes les notions de la vie pratique (ou autre) au quotidien pour une personnen ne souhaitant (ou pouvant) vivre sans aucun appareil électronique au quotidien (oui, c'est une liberté fondamentale) ; soit, sans internet, sans ordi, sans téléphone à titre individuel (pouvant les utiliser dans les espaces publics, type médiathèques par exemple, comme certains font aujourd'hui)
…où dois-je la faire? ;)
autre chose qui me surprend :
il y a moult "avis" publiés relatifs à l'absence de procédure sans smartphone, par rapport aux procédures, sur https://plus.transformation.gouv.fr , cependant, quelque chose très étonnant : une simple recherche ne mène t-elle pas à cette pétition, notamment créée pour cette problématique? j'ai l'impression que très peu l'ont vue (celle change.org diffusée initialement)
[^] # Re: pétition
Posté par Aeris (site web personnel) . Évalué à 2 (+1/-0).
Et propose 2 alternatives (mail et SMS) qui sont de facto non légalement recevable en l’état de la loi (SIM swap et interception mail). Ces 2 moyens ne sont plus reconnus comme des facteurs de possession depuis plusieurs années mais réduit à un facteur de connaissance.
Toute la difficulté est actuellement là : les facteurs de possession nécessitent aujourd’hui des moyens technologiques pour être mis en œuvre (en tout cas dans des délais de vérification pas trop long)
[^] # Re: pétition
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+4/-1).
Je ne suis pas sûr que la Loi précise tel ou tel moyen technique.
Ça me semble osé de mélanger :
Plutôt que d'expliquer pourquoi on a la flemme de faire autrement (que des applis mobiles à la sécurité par obscurité, car privatrices), il vaut mieux imaginer des solutions plus universelles et sécurisées :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pétition
Posté par mrintrepide . Évalué à 1 (+2/-1).
Les smartphones modernes (depuis 10 ans) sont chiffrés par défaut, protégé par un code. On peut bloquer* le téléphone et suspendre immédiatement la ligne chez l'opérateur.
E-mail chiffré utilisable depuis gmail ou n'importe quel webmail de FAI par n'importe qui ?
Il faudrait une clé de chiffrements différents pour chaque compte pour ne pas déchiffrer le mail d'un autre ?
Le mot de passe et la clé/certificat sont subtilisable de la même manière (piratage / fishing) par un tiers depuis la même machine que la connexion. C'est donc le même type authentification faite deux fois.
Voir mon commentaire plus haut.
Moi je suis pour avoir des applications opensource ou autre système ouvert.
[^] # Re: pétition
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0).
Tu parles de SSH ? Normalement tu as une passphrase et ton disque est chiffré !
Encore une fois : essaye de réfléchir à ce qui marche.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pétition
Posté par Aeris (site web personnel) . Évalué à 1 (+0/-0). Dernière modification le 03 septembre 2024 à 19:29.
C’est bien pour ça que le SMS n’est plus reconnu comme valide comme facteur de possession depuis quelques années et que l’authenfication du téléphone nécessite bien souvent un facteur biométrique supplémentaire
Le chiffrement du message ne garantit pas que le détenteur de la clef est bien devant le téléphone. C’est de toute façon exclusivement de la confidentialité et non de l’authentification justement.
Et il n’existe pas d’action réalisable par le destinataire supposé qui ne soit pas réalisable par le destinataire réel. La 2FA est justement là pour se prémunir du 1er, et non pas seulement du 2nd. C’est pour ça par exemple que le facteur de possession de la 2FA bancaire impose des mécanismes obligeant le propriétaire souhaité à faire une action dont il doit forcément avoir conscience, y compris en cas de man-in-the-middle physique.
Et c’est très difficile à faire dans un environnement décentralisé sans point central comme peut l’être une banque.
Si les banques se sont repliés vers les téléphones mobiles, c’est pas vraiment pour rien, et surtout après s’être fait dégommé la totalité des autres moyens d’authenfication par l’EBA…
On s’attaque réellement à des problèmes durs dont il n’y a pas de solution simple à mettre en œuvre, et dans un contexte « libre, décentralisé, etc » la difficulté est au moins de 2 voire 3 ordres de grandeur supplémentaires (qui est responsable en cas de merde, les certifications, l’interdiction de modification d’un système certifié, tiers de confiance, etc)
[^] # Re: pétition
Posté par Pol' uX (site web personnel) . Évalué à 6 (+4/-0).
Il y a 20 ans le CIC en suisse avait confié à un ami un générateur pseudoaléatoire à l'ouverture de son compte en banque. C'était un porte clé avec un LCD à quelques digits. À utiliser en complément d'authentification. Je ne vois pas bien en quoi c'est compliqué et coûteux à généraliser ; ni en quoi ça ne répond pas au problème. Mais peut être ais-je loupé quelque chose ?
Adhérer à l'April, ça vous tente ?
[^] # Re: pétition
Posté par Aeris (site web personnel) . Évalué à 2 (+2/-1).
La DSP2 impose dorénavant une authentification dite contextuelle. C’est-à-dire que techniquement, celui qui va valider l’OTP ne doit avoir aucun moyen d’ignorer l’action réalisée (s’authentifier, payer, ajouter un bénéficiaire…), le montant et le destinataire éventuel. Et le système doit être robuste à un « man-in-the-middle physique » par ton voisin de bureau (en gros éviter qu’il soit facile de dire « eh Truc, tu peux valider/me donner ton OTP pour 20€ chez la FNAC » alors que c’est un achat de 1000€ chez AliExpress).
Les moyens offline ne le permettent pas ou vraiment pas facilement, et les systèmes matériels dédiés deviennent trop coûteux (scan d’un qrcode, connexion bluetooth ou wifi pour récupérer l’info, écran plus avancé qu’un afficheur 6× 7 segments, etc). Tu passes de machin débile avec 3 transistors qui se battent en duel à moins de 10€ pièce à des mini-PC avec RAM, puce wifi/caméra et OS à plus de 100€ l’unité.
D’où le recours aux téléphones, qui coûtent pas cher aux banques, dispo partout, facilement mettable à jour…
[^] # Re: pétition
Posté par Pol' uX (site web personnel) . Évalué à 2 (+0/-0). Dernière modification le 11 septembre 2024 à 23:34.
Merci de la précision.
Enfin, excepté partout où ils ne le sont pas. :)
Adhérer à l'April, ça vous tente ?
[^] # Re: pétition
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0).
Que font ces fameuses applis ? Elles génèrent une clef et la stockent.
Qu'est-ce qu'on voudrait comme solution qui n'oblige pas d'installer une appli privatrice dépendante de quelques OS ? Une appli web qui génère une clef et la stockent.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pétition
Posté par Aeris (site web personnel) . Évalué à 1 (+1/-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)…
[^] # Re: pétition
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
A mon humble avis, tu surinterprètes les règlements.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pétition
Posté par Aeris (site web personnel) . Évalué à 1 (+0/-0).
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.
[^] # Re: pétition
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
Ça ne dit à aucun moment qu'il faut une appli mobile privatrice, ni un OS certifié, ni même un téléphone…
Le texte semble même prévoir un garde fou pour éviter de se retrouver uniquement avec une telle solution : https://linuxfr.org/news/demarches-administratives-et-fracture-numerique#comment-1968749
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pétition
Posté par Aeris (site web personnel) . Évalué à 1 (+0/-0). 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 devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 13 septembre 2024 à 12:03.
Tu fais dire au texte ce que tu as envie/compris.
La BNP propose toujours le MFA par SMS + code secret, donc non toutes les solutions ne sont pas hors jeux.
Je vois aussi que certaines banques proposent des alternatives :
https://www.cic.fr/fr/particuliers/comptes/authentification-forte-digipass.html
https://www.banquepopulaire.fr/votre-banque/securite/pass-cyberplus/
Bien sûr c'est fort dommage de ne pas utiliser webauthn, TOTP ou un mécanisme équivalent…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pétition
Posté par Aeris (site web personnel) . Évalué à 2 (+1/-0). 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 devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 13 septembre 2024 à 13:15.
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.
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 ?
Je le répète : si les banques aiment les applis mobiles, ce n'est pas pour la sécurité.
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 post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pétition
Posté par Aeris (site web personnel) . Évalué à 1 (+1/-1).
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 devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
Je suis client, je m'en balec de l'avis de la banque :-)
Tu vas faire quoi si la banque impose un prélèvement ADN à chaque authentification ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pétition
Posté par Aeris (site web personnel) . Évalué à 1 (+1/-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 devnewton 🍺 (site web personnel) . Évalué à 3 (+1/-1).
On peut tourner en boucle comme ça longtemps, mais tu ne fais que tenter de justifier l'existant sans réfléchir à ce qui pourrait (bien) fait.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pétition
Posté par Aeris (site web personnel) . Évalué à 1 (+1/-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) . Évalué à 0 (+0/-1).
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 devnewton 🍺 (site web personnel) . Évalué à 2 (+0/-1). Dernière modification le 13 septembre 2024 à 15:55.
Je ne comprends toujours pas : avec TOTP la clef est générée côté serveur et les codes sont validés côté serveur.
Le dev qui fait la génération ou la validation dans une appli qui tourne côté client (même closed source, signé, sur un OS certifié non rootable secure boot genuine of my official ass…) est au mieux incompétent.
Et tout l'argumentaire sur les applis clientes et les terminaux "de confiance" tombe à l'eau dès qu'on regarde deux secondes les horreurs qu'on trouvent sur les store google/apple (sans compter les gens qui acceptent des stores alternatifs de jeux chinois).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pétition
Posté par Aeris (site web personnel) . Évalué à 1 (+1/-1).
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) . Évalué à 1 (+1/-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 Faya . Évalué à 3 (+1/-0). Dernière modification le 13 septembre 2024 à 17:09.
Et ton 2 dit "Google ou Apple" donc en fait ta réponse à la question "Pourquoi pas autre chose que Google ou Apple" c'est "Parce que Google ou Apple". Effectivement avec ces conditions tu ne peux qu'avoir raison.
[EDIT] Dit autrement, n'y a-t-il aucun moyen fiable de certifier une communication/application hors Google ou Apple ? Avec une combinaison de standards (TOTP + x + y) ?
[^] # Re: pétition
Posté par Aeris (site web personnel) . Évalué à 1 (+1/-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 devnewton 🍺 (site web personnel) . Évalué à 2 (+0/-1). Dernière modification le 13 septembre 2024 à 22:36.
C'est quand même de la grosse branlette façon tiers de pas confiance ou rêve humide de RSSI en manque cette histoire.
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.
Malheureusement certains semblent s'être laissé convaincre qu'un téléphone lowcost chinois avec un Android bourré de crapwares constructeur et d'applis privatrices est plus sécurisé qu'un PC normal avec Debian.
Parce que Google envoie des consultants en consulting avec de belles cravates?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pétition
Posté par Aeris (site web personnel) . Évalué à 1 (+1/-1). 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 devnewton 🍺 (site web personnel) . Évalué à 2 (+0/-1).
Le chiffrement type TLS est utilisable avec des logiciels libres (largement majoritaire d'ailleurs), on peut installer ses propres certificats… Bref c'est exactement la logique inverse de la chaîne de pas confiance dont on parle :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pétition
Posté par Aeris (site web personnel) . Évalué à 1 (+0/-0). 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 Jean Roc Morreale . Évalué à 4 (+3/-0).
Ce n'est pas un avis universel, voici le nouveau parcours d'identification à impots.gouv.fr :
Et comme l'identification de ce site peut servir à valider une connexion france connect sur un site tiers, ça compte triple :)
[^] # Re: pétition
Posté par Aeris (site web personnel) . Évalué à 1 (+0/-0).
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
# cyclistes
Posté par tkr (Mastodon) . Évalué à 1 (+2/-2). Dernière modification le 14 septembre 2024 à 18:26.
un court extrait, de nos amis cyclistes non informaticiens :
à méditer..
# Piratage MaPrimeRénov’
Posté par Le Monolecte (site web personnel) . Évalué à 2 (+2/-0).
Cela fait longtemps que MaPrimeRénov’ est derrière FranceConnect+ ?
Parce que quelqu’un a créé pépouse un compte avec mon nom et mon n° fiscal sur le site de l’ANAH qui gère en fait les dossiers MaPrimeRénov’ et je ne laisse pas du tout trainer mes données personnelles à tous vents.
Parce que là, ça signifierait qu’en fait, c’est mon compte FranceConnect+ qui serait compromis ?
Déjà, l’ANAH ne respecte pas le RGPD.
J’ai porté plainte pour usurpation d’identité, mais si le soucis vient de FranceConnect+, c’est la méga merde.
# INPI
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 9 (+7/-0).
Juste pour dire que j'ai trouvé une solution, pour une cessation d'activité, par pur hasard, après des heures de galère et alors que j'étais sur le point d'envoyer un recommandé en désespoir de cause, cf. mon fil : https://mamot.fr/@bohwaz/113073146024201834
Il faut signer le PDF fourni par l'INPI avec le site "Lex Community" en choisissant "signature avancée auth. France Connect" comme décrit dans ce tuto trouvé par hasard : https://lesbases.anct.gouv.fr/download/legacy/7d5ff509-85a_Tutoriel_signature_%C3%A9lectronique.pdf
Ensuite ça marche, le site de l'INPI accepte le PDF signé.
J'ai l'impression que c'est une "faille" du site de l'INPI car normalement il doit demandé une signature qualifiée (niveau 3) et là on lui fourni une signature avancée (niveau 2), et il l'accepte.
Est-ce que ça suffirait pour le CPF et autres ? Je sais pas.
Mais si ça peut servir à des gens…
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: INPI
Posté par tkr (Mastodon) . Évalué à 1 (+1/-1).
ce qui servirait, c'est que chaque procédure administrative, ou pratique, puisse se faire sur la plateforme de son choix (navigateur web) au même titre que sans aucun appareil.
à la fois pour les personnes réfractaires aux appareils électroniques, mais aussi parce qu'un ordi/tel, ca peut se faire perdre/voler/casser et devenir indispo, pas envie d'un blocage en l'absence de guichet.
[^] # Re: INPI
Posté par tkr (Mastodon) . Évalué à 1 (+0/-0).
bonjour,
le lien suivant met à dispo une adresse email "france-identité //gouv __fr" pour les plus curieux d'entre nous ;)
https://aide.france-identite.gouv.fr/kb/guide/fr/faire-certifier-mon-identite-numerique-XVchrbIJX3/Steps/2933113,2933612,2933235
# j'ai essayé ceci..
Posté par tkr (Mastodon) . Évalué à 2 (+1/-0).
bonjour,
j'ai tenté comme cela, je vous invite à vos avis :
https://pytition.ethibox.fr/petition/user/tkr9/appel-au-respect-de-la-liberte-individuelle-a-pouvoir-vivre-et-effectuer-des-demarches-administratives-et-pratiques-sans-aucun-appareil-connecte-du-tout-completer-sans-jamais-remplacer
pour moi ce n'est pas du tout qu'un combat du "dégooglé", mais surtout le combat de pouvoir faire sans appareil électronique. Accompagner, sans jamais remplacer. L'INPI est la symbolique de notre naufrage administratif.
# Borne libre service
Posté par jido . Évalué à 0 (+0/-0).
C'est un problème qui mérite certainement d'être adressé.
Je ne suis pas sûr qu'un porte-clé générateur de codes soit vraiment une solution. Ce qu'il manque vraiment c'est un appareil capable de:
La plupart des portables en sont capable. Mais justement tout le monde n'a pas le bon portable ou un portable tout court.
Alors il faudrait pouvoir se rendre au bureau de poste ou à la librairie où nous attend l'appareil nécessaire en libre-service. L'appareil aura aussi besoin d'une connexion internet pour pouvoir compléter la démarche.
A l'époque, le minitel était un appareil de ce genre…
# vivre sans téléphone portable
Posté par Marc Quinton . Évalué à 2 (+0/-0). Dernière modification le 11 septembre 2024 à 09:49.
Rolland Lehoucq, astrophysicien de métier, parvient, non sans gageur, à vivre sans téléphone portable et nous l'explique avec beaucoup d'humour.
bravo pour la performance !
# Carte d'identité numérique dans France Identité
Posté par Zorro (site web personnel) . Évalué à 1 (+0/-0).
Je me suis créé une carte d'identité numérique dans France Identité, toute bien validée et authentifiée en mairie et tout. J'y ai aussi importé mon permis de conduire.
Tout ceci est assez long, pas très compliqué, mais assez planqué, ça demande de la motivation et de la compréhension, et ça me semble complètement inaccessible à la majorité des gens.
J'avais fait ça, pour le plaisir de geeker, au moment de faire une procuration pour les législatives 2024.
Ça peut remplacer les photocopies ou les scan mal faits et c'est plus propre à présenter, pour les fois où un simple contrôle rapide d'identité suffit (don du sang, entrée dans un lieu sur contrôle, par ex.). J'ai appris que depuis peu, ça pourrait suffire aux contrôleurs SNCF.
Mais ça n'est pas une "vraie" carte d'identité pour autant : quand on veut s'authentifier par QR Code en ligne, il faut quand même passer la vraie carte en lecture NFC à l'arrière du tél, donc on est obligé d'avoir la vraie carte avec soi, l'appli n'est qu'un "pont" entre la vraie carte et le site web qui demande l'authentification.
En fait, pour avoir utilisé une ou deux fois cette authentification en ligne, un doute commence à m'habiter : je pense que cette appli de carte numérique est un premier pas vers la vérification de l'âge forte que demandent les politiciens depuis longtemps aux éditeurs de sites pornos, et qui semble (semblait ?) impossible à mettre en place correctement depuis des années. C'est une bonne chose.
# Extrait de la DSP2
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0).
Lorsqu’elle fixe lesdites exigences, l’ABE devrait accorder une attention particulière au fait que les normes à appliquer doivent permettre d’utiliser tous les types de dispositifs courants (tels que les ordinateurs, tablettes et téléphones mobiles) pour assurer différents services de paiement.
Wikipedia indique d'ailleurs qu'un engagement a été pris dans ce sens https://fr.wikipedia.org/wiki/Directive_sur_les_services_de_paiement#cite_note-7
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# aeris
Posté par mahikeulbody . Évalué à 4 (+2/-0). Dernière modification le 13 septembre 2024 à 19:31.
Je trouve que c'est dommage de moinser quelqu’un parce qu'il acte le fait qu'il est très compliqué de faire autrement qu'avec un ordiphone. Forcément, sur linuxfr, c'est énervant de s'entendre dire qu'il n'y pas de solutions libres ne nécessitant qu'un pc sous Linux et un navigateur libre. De ce que je comprends, ce n'est même pas un problème de législation (à moins d'en faire une qui impliquerait une régression sur la sécurité des transactions). Bref, tirer sur le messager juste parce que le message est une pilule dure à avaler ne me semble pas l'objectif du système de karma. En l’occurrence, ça aurait pu me faire passer à coté de réponses claires et détaillés sur le sujet (bravo et merci à lui pour sa patience) et a priori factuellement justes (n'étant pas un expert du sujet, je me suis peut-être laissé embobiner mais c'est pas l'impression que j'ai au vu des commentaires de ses contradicteurs).
Je pense que ce sujet, qui est un des volets d'une société où on devient de plus en plus lié à un ordiphone sans alternatives simples pour ceux qui n'en veulent pas, mériterait une dépêche reprenant les explications de @aeris ainsi que les éventuelles propositions techniques ou législatives connues pouvant améliorer (au sens où on l'entend sur linuxfr) le système actuel sans dégrader la sécurité des transactions ni augmenter significativement le coût du service bancaire associé.
PS. Non Ysabeau, je ne me porte pas volontaire :-)
[^] # Re: aeris
Posté par Faya . Évalué à 2 (+0/-0). Dernière modification le 14 septembre 2024 à 17:00.
Sur 18 messages, il a une note moyenne de 1,33. Donc il est majoritairement (légèrement) plussé et pas moinssé… Et la discussion est restée calme. "Tirer sur le messager" c'est très exagéré.
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.