PyPI (de l’anglais « Python Package Index ») est le dépôt tiers officiel du langage de programmation Python. Son objectif est de doter la communauté des développeurs Python d’un catalogue complet recensant tous les paquets Python libres.
Google, par l’intermédiaire de l’Open Source Security Foundation (OpenSSF) de la Linux Foundation, s’est attaqué à la menace des paquets malveillants et des attaques de la chaîne d’approvisionnement des logiciels open source. Elle a trouvé plus de 200 paquets JavaScript et Python malveillants en un mois, ce qui pourrait avoir des « conséquences graves » pour les développeurs et les organisations pour lesquelles ils écrivent du code lorsqu’ils les installent.
PyPI déploie le système 2FA (pour double authentification ou authentification à deux facteurs) pour les projets critiques écrits en Python.
Ainsi, comme il est possible de le lire sur le compte twitter de PyPI (version nitter fdn.fr ou censors.us), le dépôt va implémenter le 2FA obligatoire pour les projets critiques écrits en Python.
Nous avons commencé à mettre en place une exigence 2FA : bientôt, les responsables de projets critiques devront avoir activé 2FA pour publier, mettre à jour ou modifier ces projets.
Pour s’assurer que ces mainteneurs puissent utiliser des méthodes 2FA fortes, nous distribuons également 4000 clés de sécurité matérielles !
Les 4000 clés de sécurité matérielles sont des clés de sécurité Google Titan. Ces clés seront distribuées aux responsables de projets, avec l’aide de l’équipe de sécurité open source de Google.
Vente autorisées, mais pas partout
La vente des clés Titan n’est autorisée que dans certaines régions géographiques. Ainsi, seuls les développeurs d’Autriche, de Belgique, du Canada, de France, d’Allemagne, d’Italie, du Japon, d’Espagne, de Suisse, du Royaume-Uni et des États-Unis peuvent en recevoir une gratuitement.
Le 2FA en progressions
Il y a déjà un certain nombre de développeurs qui ont activé le 2FA, ainsi, et en toute transparence selon PyPI, le dépôt publie les données sur les comptes 2FA.
Selon PyPI, il y a déjà plus de 28 600 utilisateurs avec 2FA activé, dont près de 27 000 utilisant une application TOTP (par exemple FreeOTP+ sur mobile Android ou via KeepassXC sur un ordinateur).
La PSF (Python Software Foundation) indique qu’elle considère comme critique tout projet figurant dans le top 1 % des téléchargements au cours des six derniers mois. Actuellement, il y a plus de 350 000 projets sur PyPI, ce qui signifie que plus de 3 500 projets sont considérés comme critiques. PyPI calcule ce chiffre quotidiennement, de sorte que le don de Titan devrait permettre de couvrir une grande partie des mainteneurs clés, mais pas tous.
Bien que la plupart des développeurs soient familiers avec le système 2FA, cette exigence pourrait créer des difficultés de connexion.
En effet, si, par exemple, un utilisateur perd sa clé 2FA et qu’il n’a pas configuré d’autres options 2FA, il risque de perdre l’accès à son compte et donc la nécessité de récupérer entièrement un compte, ce qui est lourd et prend du temps à la fois pour les mainteneurs et les administrateurs de PyPI. Il serait donc préférable d’avoir plusieurs méthodes 2FA pour réduire les perturbations potentielles si l’une d’entre elles est perdue.
Conclusion
Est-ce que le 2FA va réellement sécuriser les projets Python ? C’est l’avenir qui le dira. En attendant, il semblerait que PyPI et plus globalement la PSF ait décidé de prendre les choses en main quant à la sécurité des projets Python.
N. D. M. : voir aussi le journal PyPI et les projets critiques sur le même sujet, abordant notamment l'ajout de contraintes supplémentaires (complexité, temps, éventuel coût matériel, vérification régulière du 2FA à effectuer, etc.) pour les passionnés/hobbyistes.
Aller plus loin
- Annonce implementation 2FA (102 clics)
# Oui, mais
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 6.
L'authentification à facteurs multiples protège bien contre les tiers, et c'est donc une bonne idée que d'encourager son déploiement mais elle ne protège pas contre un développeur malveillant ou négligent (par exemple parce qu'il accepte des patches sans les lire). Donc, c'est bien, mais ce n'est pas suffisant.
Il n'y a pas de solution simple au problème des développeurs malveillants. Il n'est évidemment pas question d'auditer/certifier les développeurs de logiciels libres (qui aurait la légitimité de le faire, et selon quels critères ?)
[^] # Re: Oui, mais
Posté par barmic 🦦 . Évalué à 5.
Ou des failles indépendantes de la volonté du développeur ou si le développeur est victime d'une suply attack ou si le projet du développeur en question reçoit des contributions malveillantes ou si l'infra du projet est fragile et subit des injections de code par exemple, PyPI eux même pourraient se faire attaquer pour remplacer des paquets par exemple, ça ne résoud pas non plus les faux paquets comme requests vs request…
Il n'y a pas de silver bullet et personne be l'a affirmé. PyPI parle d' améliorer la sécurité rien de plus.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Oui, mais
Posté par FantastIX . Évalué à 4.
C'est hors contexte mais le dépôt Savannah le fait — bon, ce sont des humains derrière qui auditent mais l'idée est là. Je ne dis pas que c'est une bonne idée ou qu'il faut le faire, juste qu'il y a au moins un antécédent. Pour une autre raison mais un antécédent quand même.
# Titre trompeur
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 8.
La dépêche le dit mais le titre est trompeur : PyPi a 2FA depuis très longtemps. Il est déjà déployé, il s'agit juste de l'encourager.
--
Stéphane, développeur sur PyPi et ayant activé 2FA il y a des années :-)
[^] # Re: Titre trompeur
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
# Je vois pas le rapport!
Posté par FantastIX . Évalué à 4. Dernière modification le 17 juillet 2022 à 10:29.
Quelqu'un peut m'expliquer le raisonnement de fond (de Google) selon lequel 2FA réduira (ce que je suppose) la quantité de projets malveillants? Parce que là, je vois vraiment pas le rapport.
En revanche, si Google avait décidé de tout faire pour collecter les informations personnelles et de déployer tous les moyens possible et imaginables pour qu'il soit possible d'identifier avec 100% de certitude une personne (à l'échelle individuelle, donc) en fonction des paramètres collectés, je ne vois pas un meilleur prétexte que la "sécurité"…
Mais tout ceci n'est que de la spéculation, n'est-ce pas?
/mode sarcasm off
[^] # Re: Je vois pas le rapport!
Posté par FantastIX . Évalué à 1.
hmm… entre possible et possibles… -_-
[^] # Re: Je vois pas le rapport!
Posté par barmic 🦦 . Évalué à 3.
Tu ne vois vraiment pas en quoi réduire les risques de vol de compte augmente la sécurité ? Vraiment vraiment ?
On appel ça un procès d'intention. Aujourd'hui tu as ton compte pypi qui n'a pas à être relié à un compte google, le 2FA demande d'avoir une clef d'authentification (tu peut prendre celle qu'ils proposent ou d'autres qui n'ont aucun rapport avec google) ou tu peux utiliser des solutions purement logiciel qui utilisent uniquement du LL comme oathtool.
Parfaitement, mais tu as peut être d'autres arguments que "Y A GOOGLE !!!!!".
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je vois pas le rapport!
Posté par FantastIX . Évalué à 1.
Il y a des tas de projets avec des dépôts en ligne, non? Qu'en est-il de ceux-là? Ils sont plus sécurisés? Moins? Quels sont les moyens de réduire les probabilités de projets malveillants? En ont-ils déployé? A-t-on constaté des résultats? Quels sont-ils? Peut-on en déduire quelque chose? Si oui, quoi?…
Bref, t'as pas répondu à ma question.
Aha? Vraiment? Parce que c'est bien connu que Google ne cherche pas à collecter des données personnelles? Parce c'est bien connu qu'ils ne le font pas? Et les sujets défendus par Mental Outlaw, Naomi Brockwell, Braxman Tech (il y en a d'autres, ce ne sont pas les seuls), ce sont des idées, peut-être?
Tu appelles ça comme tu veux, moi j'appelle ça un prétexte.
Puisque tu prétends "savoir" ce qu'est un troll, as-tu remarqué que tu me demandes des arguments alors que non seulement tu ne réponds pas à ma question mais qu'en plus tu n'en donnes pas un sur le sujet?
[^] # Re: Je vois pas le rapport!
Posté par barmic 🦦 . Évalué à 6.
Github s'y met aussi, npm aussi. L'authentification 2 facteurs est un mouvement de fond. On considère de moins en moins qu'un mot de passe suffit.
Ça ne concerne pas les projets malveillants, mais les projets qui se font voler leur compte pour déployer du code malveillants. Il y a des cas documenté chez pypi et npm depuis plusieurs années.
Ils augmentent le niveau de garantie que le code que tu télécharge vient bien de l'auteur du code. Il n'y a pas besoin de faire une thèse pour simplement mettre en place une démarche déjà amplement industrialisée.
Pipy n'est pas Google. Et encore une fois ici la seule info que Google peut avoir c'est de connaître quelle clef privée ils ont envoyé à qui. Ils ne savent pas quel compte pipy l'utilise, ils ne savent pas quand est utilisée, l'authentification ne passe pas par chez eux.
Parce qu'une majorité des arguments consiste simplement à lire la nouvelle, c'est bien pour ça que c'est du troll. Tu as semblé être matrixé par le mot google au point de préférer :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je vois pas le rapport!
Posté par FantastIX . Évalué à 4. Dernière modification le 20 juillet 2022 à 09:44.
Je te remercie.
Juste un détail: il n'y a pas que des trolls, il y a aussi des gens qui comprennent mal et qui ne sont pas animés d'intentions malveillantes ou dont la seule intention est d'envenimer un débat déjà houleux. J'ignore le encore le seuil selon lequel tu classes une personne en tant que troll. Tout ce que je peux te suggérer, c'est d'éviter la classification binaire troll/pas troll…
Du reste merci encore pour tes clarifications.
[^] # Re: Je vois pas le rapport!
Posté par barmic 🦦 . Évalué à 4.
Il est très rare que je présume que quelqu'un est un troll. Mais un message peu l'être. C'est très différent de mon point de vu.
Par contre, il ne faut pas voir ça comme une disqualification de ma part.
Déjà tu remarquera que je n'ai même pas utilisé le mot pour te répondre.
Mais surtout, le trolling n'est pas systématiquement mauvais. Ça peut faire parti d'un foklore et ça peut même amener des discussions intéressantes1.
La réaction me paraissait épidermique voila tout.
petit journal il y a 8 ans déjà ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je vois pas le rapport!
Posté par FantastIX . Évalué à 2.
Tu sais, on ne contrôle pas toujours la manière dont on sera perçu ou pas. C'est à celui qui reçoit le message que cette responsabilité incombe. Que tes intentions soient louables ou pas, c'est uniquement la sensibilité (et les émotions, qui sont parfois variables) de celui à qui tu t'adresse qui vont déterminer le ton de l'échange. Et si aucun des deux intervenants ne prend du recul, c'est la bagarre assurée.
Pour ma part, ma perception du mot "troll" n'est ni positive, ni encourageante, contrairement à la tienne — et c'est très bien, hein, pas de malaise à ce niveau, il n'y a pas de bonne ou mauvaise perception, juste des sensibilités qui s'entrechoquent. Je tâcherai de me rappeler ton billet la prochaine fois que je démarre au quart de tour ;-) .
[^] # Re: Je vois pas le rapport!
Posté par barmic 🦦 . Évalué à 3.
Ma nouvelle signature t'aidera peut être
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je vois pas le rapport!
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
C'est sûr que si ça passe par G..gl. ça met cette entreprise dans la position d'un état par rapport aux cartes nationales d'identité. Du coup, on peut comprendre ton questionnement et y répondre par le fait qu'ici plusieurs solutions/fournisseurs sont possibles : pas de centralisation G..gl. possible donc, sauf si tout le monde décident de faire ce choix (qui n'est pas imposé par PyPi qu'on s'entende.)
Maintenant, pour la sécurité, il faut voir/comprendre le problème actuel de l'authentification classique : quand une personne malveillante arrive à capter le mot de passe d'une autre personne bienveillante, malveillante peut commettre des exactions au nom de bienveillante ; et malheureusement on a eu beaucoup de cas qui font que ce scénario n'est plus de faible probabilité mais avéré.
Si pour accéder à tes opérations bancaires, il te fallait juste le code de ton espace client (ou de ta carte bancaire) ça sécurise …mais cette sécurité vole en éclat si quelqu'un arrive à avoir ce code. On a vu entre temps des systèmes consistant à demander plusieurs mots de passes mais avec l'inconvénient que ça multiplie les mots de passes au lieu de résoudre le vrai problème (plus les gens en ont, plus on a tendance à les noter ou à réutiliser les mêmes, au mieux certaines personnes utiliseront un gestionnaire de mot de passes mais quand c'est le gestionnaire qui est devenu accessible alors on a juste repoussé le souci et quand ça merde ça fait encore plus mal.) L'autre approche est celle des systèmes qui génère un jeton temporaire qui fait que si on arrive à attaquer une session ça ne vaudra que pour cette session et pas d'autres.) Ce n'est pas le panacée mais c'est déjà beaucoup plus sécure, sachant que les jetons ne sont pas stockés avec le mot de passe mais dynamiquement et via un autre canal : on a donc 2 facteurs qui se valident. L'idée générale est d'associer ce que le/la propriétaire légitime connait (le mot de passe) et ce que il/elle possède (par exemple, le téléphone sur lequel on va envoyer un sms contenant un code), ce qui est forcément plus sécure (bon, dans cet exemple si tu te fais voler le téléphone en même temps que les mots de passe par la même personne on revient au point de départ, sinon comparé à avant la casse est limitée) Pour en revenir à l'exemple initial, pour accéder à tes opérations bancaires, il te faut maintenant aussi bien connaître le code et présenter par exemple une pièce d'identité avant d'accéder à la salle des coffres de la banque : c'est beaucoup plus sécurisé qu'une/un simple consigne/box non ?
Il est là le rapport que tu cherches. L'accès étant plus sécurisé, il y aura moins de code malveillant venant de tierces (cela n'empêche pas le sabotage volontaire ; mais entre une personne qui saborde son npm, comme on l'a vu y a pas longtemps, et la même personne qui serait victime de bots/crackers y a un plus grand fossé.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Je vois pas le rapport!
Posté par barmic 🦦 . Évalué à 4.
Tu ne peux pas t'authentifier sur pypi avec autre chose qu'un compte pypi (ils n'ont pas de délégation). Si tu utilise une clef d'authentification que ce soit google ou un autre, si j'ai bien compris le fonctionnement, il peut faire le lien entre une clef et toi (il sait à qui il a envoyé quoi), mais il n'a aucun contrôle sur où est-ce que tu t'en sert, avec quel compte, quand, etc.
C'est une info effectivement, mais tu n'y est pas contraint et pypi ne maintiens aucune dépendance envers google. Ils peuvent demain leur dire d'aller se faire cuir un œuf sans que ça ne change quoi que ce soit.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je vois pas le rapport!
Posté par gouttegd (site web personnel) . Évalué à 6.
[Référence nécessaire]
On a des cas de contributeurs à PyPI ou à NPM dont les mots de passe ont été captés par des acteurs malveillants qui les ont ensuite utilisé pour publier du code malveillant au nom de ces contributeurs ?
La dépêche fait référence (sans lien d’ailleurs, ce qui est dommage) à une étude de l’Open Source Security Foundation qui a trouvé « plus de 200 paquets Javascript et Python malveillant ». Il s’agit de ce projet, dont le résumé dit clairement
(L’emphase est de moi.) Les attaques par « confusion de dépendances¹ » et « typosquattage » ne nécessitent aucunement de capturer les identifiants et mots de passe de qui que ce soit. L’attaquant publie les paquets malveillants avec un compte qu’il a créé lui-même et donc qu’il contrôle déjà entièrement. C’est justement un des intérêts de ces attaques que de ne pas nécessiter un quelconque acte de « piraterie » pour être mis en œuvre.
L’authentification à deux, trois, ou douze facteurs n’a strictement aucun effet sur ce genre d’attaques.
L’étude ne mentionne explicitement aucun cas de code malveillant publié avec le compte d’un contributeur légitime qui se serait fait pirater son compte. Je pense que s’ils avaient détecté un tel cas, ç’aurait été suffisamment notable pour mériter une mention.
Donc non, il n’y a pas de rapport entre « tout le monde peut publier sur NPM ou PyPI, du coup il y a des paquets malveillants » et « désormais les projets critiques doivent utiliser l’authentification à deux facteurs ». Le second n’est pas une solution au premier, c’est une solution à un tout autre problème,² et jusqu’à preuve du contraire un problème beaucoup moins répandu que le premier.
¹ En gros, l’attaquant apprend, d’une manière ou une autre, que la cible utilise des paquets PyPI ou NPM privés (hébergés sur un dépôt interne), et du coup publie un paquet avec le même nom sur PyPI ou NPM, ce qui « masque » les paquets hébergés sur le dépôt privé et conduit la victime à télécharcher le paquet fabriqué par l’attaquant plutôt que le paquet hébergé en interne.
² Non pas que ce soit une mauvaise solution (perso j’accueille favorablement toute initiative en faveur de la généralisation de l’authentification à deux facteurs, que j‘utilise moi-même partout où elle est disponible, y compris sur PyPI).
[^] # Re: Je vois pas le rapport!
Posté par gouttegd (site web personnel) . Évalué à 7.
Je me réponds tout seul : il y a un cas documenté, un attaquant a pris le contrôle du compte responsable du paquet
ctx(manifestement abandonné depuis plusieurs années), en profitant du fait que le titulaire du compte avait laissé son nom de domaine expirer (permettant à l’attaquant de récupérer le nom de domaine, et partant de recevoir le mail de réinitialisation de mot de passe).Il me semble probable que ce soit ce cas précis, survenu il y a quelque mois à peine, qui ait décidé les responsables de PyPI à forcer l’utilisation de l’authentification à deux facteurs, bien plus que l’étude de la OpenSSF qui concerne un problème complètement différent.
Mais un cas, donc. On reste loin du « on a eu beaucoup de cas qui font que ce scénario n'est plus de faible probabilité mais avéré ».
[^] # Re: Je vois pas le rapport!
Posté par barmic 🦦 . Évalué à 4.
Tu as aussi 2 paquets npm
eslint-*qui ont subit ce genre de problème, si j'ai bien compris (il y a 4 ans…).https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes/
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Je vois pas le rapport!
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Oui, un cas isolé ici. Mais ma réponse était globale, pour répondre par rapport à l'apport du MFA, et ne ciblait pas (que) PyPi.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Je vois pas le rapport!
Posté par FantastIX . Évalué à 2.
Merci pour ton explication. C'est en effet plus pertinent que je ne l'aurai compris.
Ceci dit, deux choses: je me rends compte que, pour une raison que j'ignore, focalisé sur le fait qu'il s'agirait de passer par les serveurs de Google pour l'authentification… ce qui est visiblement faux. Je ne sais ce que j'ai lu mais c'est visiblement ce que j'ai compris :-D . À tort, évidemment. Et comme le tort t… bref.
La deuxième chose c'est que ce n'est pas le seul projet à voir certains de ses comptes se faire pirater — un des derniers que j'aie en tête est Gentoo (que j'aurai bien soin de ne pas résumer ici). Donc qu'est-ce qui fait de PyPy qu'on en parle autant… enfin je veux dire d'en faire une dépèche? Potentiellement, tous les dépôts libres et open source du monde entier, planétaire sont soumis aux mêmes risques, non?
De plus, le 2FA ne prend en charge que le piratage des comptes en protégeant ces derniers. Rien n'empêche, en revanche, un "vilain" d'altérer un projet suffisamment peu surveillé et de le contaminer avec du code malveillant. Et ça, aucune solution technique n'existe pour s'en protéger.
[^] # Re: Je vois pas le rapport!
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
On fait tous et toutes des raccourcis bon ou mauvais ; le courage set d'oser poser des questions… (beaucoup, y compris parmi les gens qui se moquent, ne sont pas plus avancés/avancées)
Python est transversal et utilisé par plusieurs distributions, c'est plus gros (que Gentoo par exemple) avec des impacts plus visibles. En plus de cela, ce sont les commentaires sur un autre journal qui ont justifié cette dépêche, te permettant de poser tes questions (visiblement ce n'était pas clair pour tout le monde)
https://linuxfr.org/users/serge_ss_paille/journaux/pypi-et-les-projets-critiques
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Je vois pas le rapport!
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 7.
Il faut lire l'article avant : l'authentification a deux facteurs n'impose pas de passer par Google, elle se fait avec TOTP, une norme ouverte (RFC 6238) et pour laquelle il existe plein de mises en œuvre en logiciel libre.
[^] # Re: Je vois pas le rapport!
Posté par FantastIX . Évalué à 2.
Supposition gratuite ;-) . Bien sûr que je l'ai lu. Mal, de toute évidence.
[^] # Re: Je vois pas le rapport!
Posté par flan (site web personnel) . Évalué à 6.
C'est en effet de la spéculation.
# Un débat enflammé (en)
Posté par Samuel (site web personnel) . Évalué à 8.
Certains, comme Armin Ronacher se sont élevés de façon véhémente contre cette nouvelle obligation imposée aux développeurs bénévoles, qui se voient "punis" d'avoir partagé gentiment leur création.
James Bennett lui répond qu'il faut être singulièrement asocial pour refuser un geste simple qui permet de limiter les risques pour tout le monde.
Le débat n'est pas sans rappeler d'autres controverses politiques actuelles, avec peu ou prou les mêmes questions en toile de fond (qui doit imposer quoi ? au bénéfice de qui ? qui est "nous" ?)
# Mauvais facteur
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Les systèmes à deux facteurs qui se basent sur un objet physique ou la saisie de code sont pénibles.
Pourquoi pas un simple enrôlement du périphérique ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais facteur
Posté par FantastIX . Évalué à 3.
En général, un renforcement de la sécurité s'accompagne d'un certain inconfort et c'est normal. Qu'entends-tu par pénible et quel cas soulèves-tu exactement? De quel enrôlement du périphérique s'agirait-il, en outre?
[^] # Re: Mauvais facteur
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Non ce n'est pas normal :-)
Saisir 42 mots de passe / clef / code par jour, c'est un tel inconfort que les gens préfèrent contourner les systèmes de sécurité plutôt que les utiliser.
L'enrôlement du périphérique veut dire déposer une "clef" sur le PC/téléphone/tablette/terminal/… de l'utilisateur. Cette "clef" est le second facteur en plus du mot de passe.
Les avantages par rapport aux codes OTP par SMS / PUSH mobile :
Comme implémentations de concept, il y a:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais facteur
Posté par FantastIX . Évalué à 3.
Au risque de te contredire encore une fois: si, c'est normal.
Ce que tu exposes là relève d'un autre autre phénomène. Cela ne change en rien qu'accroître la sécurité d'un système causera un certain inconfort d'utilisation pour ce système. Par exemple, dans une banque ou un data center, en fonction des endroits où tu te rendras, tu devras montrer patte blanche en fournissant une ou plusieurs pièces d'identité, badger à plusieurs reprises pour passer dans des sas de sécurité, attendre que les portes soient disponibles, que les locaux à visiter soient vides de tout personnel, suivre des couloirs précis, peut-être même revêtir un équipement spécifique…
Ce que tu décris est la situation d'une personne qui passe d'une banque (ou d'un data center) à l'autre, plusieurs fois par jour et que ça gonfle de se plier aux mesures, justifiées, de la sécurité. Alors, je suis au regret de te dire que, à cela, il n'y a pas de solution technique. C'est un problème humain.
Alors, non.
Tout simplement parce que si le téléphone/périphérique/terminal/autre est compromis et que toute la sécurité repose dessus, toute l'efficacité du dispositif s'effondre, notamment en raison de ce que, dans ce cas précis, il est préférable de "ne pas mettre tous ses œufs dans le même panier". Ce simple cas peut te paraître trivialement peu probable (ce qui reste à démontrer et la réalité te donnerait tort) mais c'est bien là le problème: il suffit d'une fois pour que toute intrusion, réussie, provoque des dégâts colossaux.
Le but du 2FA est d'exiger, justement, une deuxième mesure d'authentification, sur base de ce que la première n'est pas assez robuste. Tu comprendras aussi aisément que confier une mesure d'authentification à un ordinateur multi-usages, qui sert aussi de téléphone et, par voie de conséquence, tout aussi "compromissible"¹, n'est qu'une façon de multiplier les surfaces d'attaque. Le périphérique impliqué dans la seconde mesure d'authentification, pour être le plus sûr possible, ne devrait être conçu que pour remplir cette tâche, comme les périphériques Yubikey, par exemple.
Ça ne signifie en rien qu'une telle clé est impossible à compromettre. En revanche, les moyens à déployer pour le faire devraient, par la conception de ce système, être beaucoup plus… inconfortables pour les contrevenants que s'il s'agissait d'un ordinateur, qui plus est connecté à internet.
¹ Je viens de l'inventer…
[^] # Re: Mauvais facteur
Posté par devnewton 🍺 (site web personnel) . Évalué à 4. Dernière modification le 20 juillet 2022 à 17:47.
L'enrôlement du périphérique est un second facteur (quelque-chose que je possède). Le premier est par exemple ton couple login + mot de passe (quelque-chose que je connais).
Attention le multi-facteur ne protège pas contre la compromission du périphérique, y compris avec des code SMS ou Push. Exemple: beaucoup de gens font leurs achats avec leur téléphone.
Si tu veux du multi-facteur résistant au vol de terminal, il te faut trouver un moyen de forcer les utilisateurs à utiliser :
Le top serait d'avoir un mini terminal dédié à l'authentification / autorisation. Au niveau protocole, c'est l'idée d'OpenID CIBA: https://industriels.esante.gouv.fr/produits-et-services/pro-sante-connect/openid-ciba
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais facteur
Posté par FantastIX . Évalué à 2. Dernière modification le 20 juillet 2022 à 19:07.
On ne doit pas avoir la même notion d'un 2FA, dans ce cas. Un 2FA qui est compromissible (sic) ne vaut pas mieux que le premier et, plus grave encore, renforce potentiellement l'illusion de sécurité. Un tel système est, AMHA, tout simplement à foutre au bac, une mauvaise idée qui aurait dû rester sur le coin du napperon.
Et en voilà encore un de pas fiable comme canal. Les cartes SIM sont, en outre, encore une couche informatique (lire: un ordinateur) de plus dans la chaîne, tout aussi "piratable", qui plus est, à l'insu du porteur (l'utilisateur), ce qui l'affaiblit davantage (la chaîne, pas le porteur). Parce que, contrairement à ce qui serait d'usage, le SMS n'est pas un vecteur sûr pour le multi-facteur¹.
Perso, moi? Je ne veux rien. Mais si tu insistes…
À la bonne heure, voilà, on y est! C'est ce que je disais: les périphériques style YubiKey.
Ou pas:
Le top? Mais… pour qui?
Et pourquoi, fichtre, sembles-tu tellement focalisé sur/obnubilé par l'utilisation d'un ordinateur comme deuxième agent? Entre une clé matérielle, spécialisée, dédiée, et un appareillage informatique générique, complexe et compliqué, connecté, avec ou (bien pire) sans surveillance, de pas portable à pas transportable, qui a besoin d'électricité pour fonctionner et qui demande sans doute des mises à jour système pour éviter de se faire plomber, qui est probablement en fonctionnement 24/7… franchement, y a pas photo, si?
Honnêtement, j'ai beau faire un effort, je comprends pas et j'ai l'impression de pisser dans un violon. Et ça me gène pour les musicos, vraiment, j'te jure c'est pas bien. Pardon pour eux.
¹ Déjà rien qu'en raison du sim-swapping mais ça n'est pas la seule raison.
[^] # Re: Mauvais facteur
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
C'est envisagé dans la santé, car les CPS sont insatisfaisantes et surtout on veut gérer des autorisations en plus de la simple authentification.
Exemple :
Cela pourrait s'appliquer à bien d'autres domaines.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais facteur
Posté par FantastIX . Évalué à 3. Dernière modification le 21 juillet 2022 à 22:39.
Je comprends pas trop ton exemple. Que l'utilisation d'un ordinateur multi-usage à des fins d'authentification se fasse dans le cadre d'un hôpital ne rend pas la chose plus pertinente, que du contraire. Perso, j'aurais tendance à me barrer d'un hosto qui applique cette méthode.
Mais hélàs, ça pourrait bien signifier qu'un jour je doive finir par m'amputer la jambe tout seul…
Parfois je me dis que l'humain est tellement con que si un jour on sortait une app pour pouvoir pisser sans ouvrir sa braguette ni se lever de son canapé, sûr qu'y en a qui achèteraient en masse…
Je vais m'faire un bon rhum/cognac, ça me détendra.
[^] # Re: Mauvais facteur
Posté par barmic 🦦 . Évalué à 4.
Si, bien sûr sinon ce n'est pas de l'authentification multi facteur1. Toi tu parle de compromission du périphérique et du mot de passe.
C'est comme dire que les mots de passe ne protègent pas du mot de passe
azerty.Si l'utilisateur fragilise activement son authentification, il n'y a pas des masses de protocoles pour l'en protéger.
Si un objet permet à lui seul de t'authentifié ce n'est pas une authentification 2 facteurs. D'ailleurs même si 2 objets différents le permettent ça ne l'est pas non plus.
c'est la définition du multi facteur quelque soit les reproches que tu peux ensuite avoir sur les différentes implémentations du multifacteurs ou des facteurs en eux même. Les facteurs doivent être distincts sinon ça n'en est qu'un seul. Si on prend la description faite par le nist, il est bien dit que tu dois avoir 2 facteurs différents parmi décrivant : ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mauvais facteur
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Je le répète: le multifacteur ne protège pas contre la compromission du terminal.
C'est fait pour limiter les dégats en cas de compromission d'un facteur (on récupère ton login/password).
Si on installe un rootkit sur ton PC ou ton mobile, tu es foutu.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais facteur
Posté par barmic 🦦 . Évalué à 3.
D'un côté tu parle de vol de périphérique (ce que j'ai compris par comme l'un de des 2 facteur) et de l'autre tu parle de compromission du terminal.
Tu parle donc d'une replay attaque ce qui n'a rien avoir avec le vol de ton téléphone et toutes les 2FA ne sont pas protégées contre ça effectivement parmi les 3 facteurs possibles seul celui qui prouve que tu possède quelque chose (avec TOTP par exemple) interdit le rejeu.
Par contre :
Aucun facteur n'est suffisant pour t'authentifier sinon ce n'est plus de l'authentification multifacteur. Si ce principe n'est pas respecté ce n'est pas du 2FA. Si je dessine un carré avec 5 côtés ce n'est pas un carré.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mauvais facteur
Posté par devnewton 🍺 (site web personnel) . Évalué à 3. Dernière modification le 21 juillet 2022 à 11:51.
Il y a beaucoup de combinaisons d'attaques / facteurs / mitigations. Difficile de tout résumer, mais je le répète : croire que le MFA protège en cas de vol / hack d'un terminal / périphérique est une erreur.
Selon les facteurs, cela peut réduire les impacts, mais ce n'est pas fait pour ça.
Exemple :
Cet exemple est bien sûr fictif, toute ressemblance avec des personnages et des sociétés réels ou imaginaires ne seraient que vraiment pas de bol.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais facteur
Posté par barmic 🦦 . Évalué à 6.
Ça c'est une faille d'implémentation. L'authentification 2 facteur est un principe.
Encore une fois c'est comme dire que le mot de passe ne protège pas parce qu'il est toujours possible d'écrire son login et mot de passe sur sa bio twitter.
Un service qui renvoie ce genre de données sans s'être assuré de la personne qui était en face commet une faute au même titre que quand debian casse openssl.
Le principe reste valide et ce n'est pas le fait que certains l'implémentent avec les pieds qui va changer ça.
Et le principe dis explicitement que tu ne dois pas relier les facteurs entre eux. Dire "le 2FA ne protège pas du vol d'un facteur" c'est faux, par contre dire que certains pensent implémenter un 2FA mais le font tellement mal que ça n'en est pas un, c'est tout à fait légitime.
Et ça n'est pas un détail parce que tu te sert de ces problèmes pour remettre en cause le principe. C'est comme dire que tu en a marre des mots de passe alors qu'on sait très bien que des gens les écrivent sur papier.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mauvais facteur
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Relis bien le thread, mais en résumé je dis:
La sécurité, c'est by design par by what could go wrong.
A propos, est-ce que quelqu'un a vu mon post-it avec marqué "root pwd : ***" dessus ? J'en ai besoin pour faire une mep.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais facteur
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Mauvais facteur
Posté par barmic 🦦 . Évalué à 3.
Non tu as dis et répété que 2FA n'est pas fait pour survivre à la compromission d'un seul des facteurs. Et je te dis que si un seul facteur permet l'authentification ce n'est pas du multifacteur. Après tu maintiens du flou entre les attaques par rejeu (ce à quoi tous les 2FA ne sont pas protégés) et la prise de contrôle d'un des facteurs (ce pour quoi le 2FA existe).
Que le 2FA ne soit pas suffisant c'est une évidence, qu'il faille resté vigilent c'est toujours le cas, il n'existe pas de silver bullet. Mais il ne faut pas pour autant jeter le bébé avec l'eau du bain.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mauvais facteur
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Tu veux m'attribuer une position qui n'est pas la mienne juste pour le plaisir d'avoir raison ? :-)
Si non, essaye de relire le résumé: https://linuxfr.org/news/pypi-deploie-le-systeme-2fa-pour-les-projets-critiques-ecrits-en-python#comment-1896454
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais facteur
Posté par barmic 🦦 . Évalué à 4.
Je reprends sans coupe ton commentaire en lien :
La phrase qui m'interpelle (et que j'avais déjà cité c'est :
L'authentification à 2 facteurs consiste à devoir prouver 2 choses parmi :
Si on te vol l'objet que tu as et qui te sert pour le point 1 dans une implémentation correct de la 2FA ça ne devrait pas pouvoir prouver :
Hors le nist dont j'ai donné le lien un peu plus haut affirme :
Au risque de me répéter si tous tes facteurs que tu en ai 1, 2 ou 1000 entrent tous dans « ce que tu possède », même s'il s'agit d'un objet différents pour chacun de tes 1000 facteurs, ça ne devrait pas être considéré comme du multifacteur.
J'affabule ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mauvais facteur
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Non, mais tu confonds facteur et terminal :-)
C'est comme si tu disais que l'utilisation d'une clef et d'un lecteur d'empreinte pour démarrer ta voiture protège contre le vol de la voiture, l'installation d'un tracker dessus ou le vol de la carte grise dans la boite à gant ou [insérer ici une des centaines de saletés qui peuvent arriver avec une bagnole].
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais facteur
Posté par barmic 🦦 . Évalué à 0.
[Tu parle donc d'une replay attaque ce qui n'a rien avoir avec le vol de ton téléphone et toutes les 2FA ne sont pas protégées contre ça effectivement parmi les 3 facteurs possibles seul celui qui prouve que tu possède quelque chose (avec TOTP par exemple) interdit le rejeu.]'https://linuxfr.org/news/pypi-deploie-le-systeme-2fa-pour-les-projets-critiques-ecrits-en-python#comment-1896446)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Mauvais facteur
Posté par FantastIX . Évalué à 3.
Disclaimer: je n'ai pas pertinenté ce message, pas parce que je ne suis pas d'accord avec cette phrase (je suis relativement d'accord) mais à cause de l'argumentation, centrée sur une mise en œuvre impliquant uniquement des maillons faillibles. Je [re]développe dans mon message, plus bas.
[^] # Re: Mauvais facteur
Posté par gouttegd (site web personnel) . Évalué à 5.
Pourquoi pas les deux ? Authentification à deux facteurs et enrôlement de la machine ?
C’est justement ce que fait PyPI. Tu peux avoir une authentification à deux facteurs (que ce soit via une application TOTP ou via une clef FIDO U2F) pour te connecter à ton compte PyPI et utiliser un jeton (token) propre à chaque machine pour télécharger des paquets sur le serveur via l’API.
Le jeton te permet d’utiliser l’API de PyPI indépendamment de ton mot de passe (et de l’authentification à deux facteurs qui y est éventuellement associée) et a plusieurs avantages par rapport à un mot de passe :
Du coup, il devient acceptable de faire avec le jeton ce qu’il ne faut jamais faire avec un mot de passe, à savoir l’écrire quelque part dans un fichier de configuration — typiquement, le fichier de configuration de twine, utilisé pour télécharger des paquets vers PyPI depuis la ligne de commande.
Ça te permet donc de télécharger des paquets aussi souvent que tu en as besoin sans jamais avoir besoin de saisir ni mot de passe ni code de vérification. Si jamais ta machine venait à être compromise, il te suffit de te connecter à ton compte via l’interface web (où là tu auras besoin de ton mot de passe et du second facteur associé) et de révoquer le jeton incriminé.
Avec cette configuration, la « pénibilité » de l’authentification à deux facteurs est considérablement réduite, puisque j’ai beaucoup plus souvent besoin de télécharger un paquet via twine (ce qui ne nécessite aucun mot de passe, le jeton est suffisant) que de me connecter à mon compte sur PyPI (la dernière fois que j’ai eu à faire ça, c’était justement pour générer un nouveau jeton pour enrôler une nouvelle machine).
[^] # Re: Mauvais facteur
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
C'est sans doute le bon compromis: selon le type d'opération que tu dois faire, tu as besoin de plus ou moins de facteurs.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvais facteur
Posté par FantastIX . Évalué à 3. Dernière modification le 22 juillet 2022 à 10:33.
Parce que la sécurité d'une chaîne se mesure à la robustesse du maillon le plus faible. Si un des maillons d'authentification est plus faible que les précédents (exemple de la compromission ou du piratage) c'est lui qui détermine la robustesse de la chaîne.
En gros: il ne suffit pas d'ajouter un maillon pour augmenter le niveau de protection.
Si un des maillons est aussi compromissible que les autres, la chaîne n'est pas plus sûre que si ce maillon était tout seul. Un téléphone est à voir comme un ordinateur généraliste, c-à-d tout aussi faillible. Le nombre de rapports de piratage, plus le nombre de cas de systèmes d'espionnage silencieux exploitant des vulnérabilités non documentées des téléphones portables (si encore il n'y avait que ça) devrait peser en la défaveur de l'utilisation de quelque ordinateur, généraliste, que ce soit comme maillon supplémentaire. Et il n'est pas nécessaire de voler un téléphone portable pour le compromettre; la réalité (spectre, pegasus) démontre à quel point cette idée, reçue, est totalement fausse.
Plus un système a de couches, plus il est attaquable et, par voie de conséquence, potentiellement vulnérable. Un ordinateur est un empilement de couches logicielles et matérielles, chacune d'elles possédant des failles, plus ou moins exploitables et réparables (ce n'est pas toujours le cas). Un téléphone est un ordinateur, cloisonné mais tout aussi généraliste et vulnérable, donc pas le meilleur candidat pour le multi-facteur.
Dans un téléphone portable, il y a jusqu'à trois ordinateurs: le CPU et son système, le chipset baseband et la carte SIM. Tous les trois sont attaquables et vulnérables avec des démonstrations validées et reproductibles.
Une clé matérielle, dont l'architecture a été simplifiée pour ne prendre en charge que la tâche de génération des codes d'accès (sans système d'exploitation, ou tout autre couche logicielle faillible) offre donc un niveau de protection plus élevé que n'importe quel ordinateur. Les cas défavorables qui ont été discutés relèvent principalement de l’ingénierie sociale et du phishing. Pour s'en protéger, il est possible de relever le niveau de protection au maximum mais il y aura toujours une limite basse, dépendant largement du comportement de l'utilisateur.
La clé matérielle, utilisée sur un ordinateur, correspond exactement au cas que tu soulèves mais sans téléphone.
On pourra objecter qu'une clé qui est branchée sur un maillon compromis n'offre pas plus de protection qu'un téléphone non compromis. C'est pas faux. À ceci près que la clé matérielle n'est pas destinée à empêcher la compromission du maillon mais du compte dans l'identification duquel les maillons interviennent. Cette dernière phrase est lourde de sous-entendus…
[^] # Re: Mauvais facteur
Posté par gouttegd (site web personnel) . Évalué à 2.
Tout ça c’est bien joli, mais à ma connaissance l’enrôlement de la machine sur laquelle tu utilises twine est le seul moyen de pouvoir continuer à utiliser twine une fois que tu as activé l’authentification à deux facteurs. La vérification du second facteur n’est pas possible avec l’API !
Refuser de permettre l’enrôlement de machine sur PyPI, au motif que tu affaiblirais la sécurité en introduisant un maillon soi-disant plus faible, ce serait conduire tous les utilisateurs qui le peuvent (c’est-à-dire, tous sauf ceux responsables du 1% de projets « critiques » qui n’ont désormais plus le choix) à rejeter purement et simplement l’authentification à deux facteurs, parce qu’elle rend l’outil de téléchargement de paquets tout simplement inutilisable…
Et ce n’est pas valable que pour PyPI. C’est la même histoire chaque fois que tu as besoin qu’un outil se connecte à un compte de manière non-interactive (incompatible avec le besoin de vérifier un second facteur, qui quasiment par définition impose une interaction avec le titulaire du compte).
Je n’aurais jamais activé l’authentification à deux facteurs sur mes comptes mails si je n’avais pas pu, dans le même temps, enrôler ma machine qui fait tourner un démon fetchmail pour automatiquement collecter mes mails depuis tous mes comptes. Je n’aurais jamais activé l’authentification à deux facteurs sur mon compte Nextcloud si je n’avais pas pu enrôler toutes les différentes machines sur lesquelles je veux que mes contacts, agenda, photos, etc. soient synchronisés en arrière-plan.
C’est pour ça que l’enrôlement de machine n’est pas une alternative à l’authentification à deux facteurs, et encore moins un « maillon plus faible ». Bien au contraire, c’est ce qui rend l’authentification à deux facteurs possible au-delà du cas basique de l’utilisateur devant un navigateur web (qui est, faut-il le rappeler, juste une petite facette de l’Internet).
[^] # Re: Mauvais facteur
Posté par FantastIX . Évalué à 3. Dernière modification le 22 juillet 2022 à 23:01.
Qui parle de refus, ici? Il s'agit plus de de tenir compte de la situation dans son intégralité que de refuser quoi que ce soit. Ce n'est pas ce que j'ai écrit non plus. Il y a aussi une différence, pas très subtile, entre "peser en la défaveur de" et "refuser".
Relis encore, ce n'est pas ce que j'écris. Je ne parle pas de "maillon plus faible" en ce qui concerne un téléphone par rapport à un ordinateur; je les traite tous les deux sur le même pied d'égalité donc avec le même degré de faiblesse (ou de vulnérabilité). S'il y a affaiblissement, selon mes propos, c'est à cause de l'augmentation de la surface d'attaque (téléphone plus ordinateur au lieu de seulement l'ordinateur), pas à cause d'une augmentation de la faiblesse.
Tu fais exactement le même raccourci, fallacieux, que mes étudiants: il ne s'agit pas de rejeter le 2FA (tout court) mais de prendre conscience qu'un ordinateur, comme maillon additionnel dans une chaîne d'authentification, est aussi vulnérable que le premier et que c'est à ça qu'il faut faire attention.
Et dans ce cas du 2FA avec un téléphone, tu as un nouveau problème sur les bras: sécuriser deux maillons au lieu d'un seul et empêcher qu'ils soient tous les deux compromis. Si le comportement de l'utilisateur est le problème, il est plus que probable que, si l'ordi est compromis, le téléphone l'est aussi (et vice-versa). Le 2FA n'apporte alors rien de plus.
Je ne dis pas que c'est forcément le cas pour tout le monde, simplement qu'il faut réfléchir et considérer l'entièreté des possibilités. En plus du cas que je viens de soulever, les spywares du type Pegasus sont la réalité. Combien de temps faudra-t-il pour qu'on retrouve, dans des outils comme metasploit, les tactiques de pénétration de téléphones portables, tout comme ça s'est produit pour les ordinateurs avec les outils de la NSA, rendant une intrusion aussi facile qu'un clic de souris pour la fameuse Madame Michu (l'adepte favorite de LinuxFr)?
Tu peux trouver confortable la situation dans laquelle tu te trouve; perso, je m'en fous, tu fais ce que tu veux avec tes machines. Si tu es conscient du compromis que tu fais, alors tant mieux. Mon objectif est la prudence et de rappeler qu'un téléphone est aussi un ordinateur, avec tous les risques que ça comporte. Pour ma part, c'est juste hors de question d'utiliser un truc pareil. Mais ça, ça ne regarde que moi et je ne prétends pas imposer mon mode d'utilisation aux autres (l'idée de "refuser").
Je ne prétends pas non plus être un expert — tu sais, le pas-expert qui a une opinion sur tout… Je ne partage juste pas l'enthousiasme généralisé autour des téléphones portables et cette tendance nauséabonde à le mettre à toutes les sauces sans discernement. Je ne réagis ici qu'au contexte de la sécurité.
[^] # Re: Mauvais facteur
Posté par gouttegd (site web personnel) . Évalué à 3.
OK, je viens de comprendre. Dans le contexte de la discussion j’ai cru que c’était le principe de l’enrôlement de machine que tu critiquais, au profit de la seule authentification à deux facteurs. My bad.
Je partage ton point de vue concernant le téléphone. Mes seconds facteurs ne sont pas stockés sur mon téléphone, sur lequel par principe je stocke le minimum d’information possible, et surtout pas des clefs ou des mots de passe (les seuls mots de passe enregistrés sur mon téléphone sont des jetons spécifiques à ce périphérique, révocables à tout moment).
[^] # Re: Mauvais facteur
Posté par FantastIX . Évalué à 3.
Même si c'est hors-sujet, ça fait plaisir qu'on se comprenne :-) .
[^] # Re: Mauvais facteur
Posté par Storm . Évalué à 1.
Tu stockes comment tes seconds facteurs alors? Clé FIDO/U2F?
# L'étape suivante
Posté par Benjamin Henrion (site web personnel) . Évalué à -4.
L'étape suivante voulue par Google et les gouvernements c'est de signer ses commits avec sa carte d'identité numérique, sinon on ne peut plus contribuer/publier.
J'ai vu passer quelque chose du style chez Google, mais je n'arrive pas à retrouver le lien.
[^] # Re: L'étape suivante
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Non, ici Google est un prestataire parmi d'autres :-)
voir les discussions plus tôt/haut
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.