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 Gil Cot ✔ (site web personnel, Mastodon) . En réponse à la dépêche PyPI déploie le système 2FA pour les projets critiques écrits en Python. É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