Pour tester sa sécurité, l'Organisation européenne pour la recherche nucléaire mène régulièrement des campagnes d'envergure, notamment via 23 000 emails piégés à son personnel. Signalons aussi des tentatives de vol via de fausses factures. Le CERN, habitué à publier des articles sur la cybersécurité, vient de franchir une étape avec son dernier billet : « Sécurité informatique : réflexions sur les mots de passe ».
Omniprésents, les mots de passe sont la nouvelle cible du CERN dans sa dernière communication : « La perte, la découverte ou le vol de votre mot de passe auraient de graves conséquences pour les accélérateurs, les expériences et les infrastructures informatiques du CERN. Il est donc vital qu’il soit le mieux protégé possible ». Dès le début du mois prochain, de nouvelles mesures sont ainsi mises en place.
- CERN : « nous devons réfléchir au véritable sens du mot "libre" et à ses limites »
- Cybersécurité au CERN : plus de 1 800 personnes sont tombées dans le piège d’un faux email
Partage de mot de passe : le CERN dit « NON »
Irréductibles, les utilisateurs qui se partagent encore des mots de passe vont déchanter : « un message vous informera, par exemple, que tel mot de passe est déjà utilisé par « stefan24 ». Vous serez alors prié d'en utiliser un autre ». Cela signifie par contre que le CERN a, d’une manière ou d’une autre, accès aux mots de passe en clair, ce qui est contraire aux règles élémentaires de sécurité. Sans compter que l’utilisateur pourra accéder au compte de son confrère ; on espère que les deux seront obligés d’en changer !
Surveillant de près la complexité du mot de passe, leur création doit s'appuyer « sur MathGPT de Microsoft afin d'identifier les mots de passe faibles (« n → p + e - + v ») et forts (« Δ 0 → p + π -») ». Le choix d’une solution Microsoft peut surprendre avec le projet Microsoft Alternatives (MALt) lancé en 2019 – renommé depuis Microservice Architecture on Libre Technology (MALT) – et la réflexion sur le sens du mot libre lancée l’année dernière. Au début de l’année, nous avions contacté le CERN, avec pour seule réponse : « Malheureusement, nous n’avons trouvé personne de disponible pour répondre à vos questions », renvoyant simplement vers un billet de blog.
- CERN : « nous devons réfléchir au véritable sens du mot "libre" et à ses limites »
- Le CERN revient sur son projet Microsoft Alternatives (MALt) pour passer sur des solutions open source
Surprenant, surtout quand on connait l'histoire des polices, le CERN impose « que les mots de passe soient écrits uniquement avec les polices de caractères « Courier New » ou « Comic Sans MS », ce qui les rend plus difficiles à utiliser pour des tentatives d’hameçonnage ». Aucune étude ne confirme cette affirmation, mais le Comic Sans MS et le CERN entretiennent une longue histoire d’amour.
Deux facteurs obligatoires pour certains, bientôt trois et quatre ?
On enchaine avec « l'authentification à deux facteurs à tous ceux qui sont tombés dans le piège de la campagne de sensibilisation à l'hameçonnage 2020, 2021 ou 2022 ». Il aurait été plus simple de l'imposer à tout le monde, un choix étrange d’autant que la double authentification est déjà possible depuis 2021.
Nonobstant, la suite nous semble aller trop loin : « Il est également envisagé de leur interdire à perpétuité l'accès à toutes les ressources informatiques du CERN ; cette mesure fait l’objet de discussions au niveau de la Direction ». Ne comprenant pas trop où le CERN veut aller avec le point suivant, nous vous le livrons tel quel : « mettre en place un système d’authentification à deux facteurs supplémentaire qui exigerait de se connecter simultanément à Google Workspace et à Azure AD de Microsoft dans un délai d'une minute (à confirmer) ». On a du mal à comprendre alors que l'Organisation cherchait il n'y a encore pas si longtemps à se débarrasser intégralement des outils de Microsoft et Google.
Avec l'unité HSE et, en particulier, avec le Service médical, le CERN étudie « la possibilité de déployer l'authentification à trois facteurs ». L’histoire récente nous montre en effet que même une authentification à deux facteurs peut être contournée, Microsoft en a récemment fait les frais. S’ajoute à cela les failles autours des protocoles de communications sur les SMS. Et que ce passera-t-il ensuite pour les derniers récalcitrants ? Une obligation de passer à quatre facteurs ?
- Une vaste campagne de phishing contre des clients Microsoft 365 contourne l'authentification multifacteurs
- SS7 : après des interceptions de SMS, la sécurité des réseaux mobiles en question
API CQCB, ZoomID pour éviter des actes malveillants
Vient ensuite une nouvelle « API CQCB à haut débit capable de faire face à un très grand nombre de demandes d'accès à distance, qui sont gourmandes en ressources, pour éviter le déni et le blocage de service comme cela est arrivé par le passé ».
Reste un dernier point : ZoomID. Cette fonctionnalité sera rattachée au portail d’authentification du CERN afin de « permet de vous connecter à l’aide de la reconnaissance faciale (comme Face ID sur les appareils Apple) ».
Impassible, le CERN rappelle les enjeux : protéger à la fois le travail des chercheurs, mais aussi « les accélérateurs, les expériences, l'infrastructure informatique et les données de l'organisation ». Imaginez qu’une personne malintentionnée prenne le contrôle de l’accélérateur !
La temporalité de cette annonce ne doit probablement rien au hasard : le Grand collisionneur de hadrons vient de sortir de son deuxième long arrêt technique et les expériences sont en train de reprendre doucement. Fin 2022, un « incident » était venu jouer les troubles-fête. Si les expériences ont repris, la cause n’était pas formellement identifiée, mais un problème de cybersécurité pourrait expliquer ce revirement de situation et le billet de blog du jour. L’urgence de la situation explique peut-être le côté brouillon de certains points. Dans tous les cas, un portail dédié sera bientôt mis en place.
- Le Grand collisionneur de hadrons donne satisfaction malgré un « incident »
- Le CERN va pouvoir améliorer le LHC, les travaux pour la haute luminosité sont terminés
- Au CERN, le Grand collisionneur de Hadrons s’améliore avant de reprendre du service
Commentaires (68)
#1
Sauf si je dis une connerie, ils n’ont pas besoin de stocker le mot de passe en clair pour savoir s’il est déjà utilisé par quelqu’un d’autre.
Suffit de comparer les hashs et si un autre utilisateur donne le même hash, c’est qu’ils utilisent tous les deux le même.
#1.1
J’aurai tendance à être d’accord avec toi.
À moins qu’il soit salé avec une information unique a chaque utilisateur..
#1.2
ta remarque manque un peu de sel #jesors
#2
” le Grand collisionneur de hadrons vient de sortir de son deuxième long arrêt technique et les expériences sont en train de reprendre doucement. Fin 2022, un « incident » était venu jouer les troubles-fête. Si les expériences ont repris, la cause n’était pas formellement identifiée, mais un problème de cybersécurité pourrait expliquer ce revirement de situation et le billet de blog du jour.”
A quand un “LHC as a Service ” au CERN ?
#3
On est déjà le 1er avril ?
#3.1
Même réaction à la moitié de l’article
#3.2
Vu que je me suis fait renvoyer sur http://aprilfool.web.cern.ch/index.shtml par un des liens oui.
Merci de nous faire perdre notre temps.
#3.3
Le premier avril Guillaume de Baskerville annoncera ses découvertes.
#4
J’espère que cet article est une blague ? Le billet du CERN en est clairement une, en tout cas:
Bref…
#4.1
Bien vu d’ailleurs la version française est plus explicite :
#5
Je passe le caractère trollesque de l’article avec quelques jours d’avance (bande de coquinoux !!!),
nul besoin d’avoir le mot de passe en clair pour dire qu’il est utilisé par un autre utilisateur. Il faut simplement qu’il soit hashé sans sel (ou un sel commun à tout le monde, ce qui perd un peu de son intérêt mais en présente un quand même).
Par contre, ça c’est tellement gros ! En gros, ça donne l’accès du collègue. Bonjour l’usurpation de compte. C’est sympa ça
#6
Publication d’article 10 jours trop tôt, donc ? :)
#7
UN chouilla trop tôt non ?
#8
Dans un autre billet du CERN, on apprend que les facteurs seront:
A. Le facteur premier
C. le facteur (always rings) twice
B. le facteur cheval
D. le facteur D
#8.1
Pas mal !
…auraient pu mieux faire néanmoins, ils devraient venir ici plus souvent… 
Bon ceci dit, au-delà de la farce, ce serait bien de continuer à réfléchir à de nouvelles méthodes d’ID : et AMHA cela commencerai… par la suppression pure et simple des mots de passe, au profit d’autres méthodes, telles que biométrie, clés matérielles, RFID ou autres.
Lorsque je parle de clés matérielles, je pense notamment à des sortes de dongles qui se brancheraient sur un port spécial, incompatible avec tout ce qui existe (développé en interne). Les clés en question resteraient au sein du CERN, dans un endroit sécurisé, et seraient récupérées chaque jour par les employés, chercheurs et même invités.
Deuxième sécurité, ces clés comporteraient un lecteur d’empreintes. Et enfin troisième sécurité, elle incluraient toutes un code RFID qui serait scanné avant toute utilisation, entrée ou sortie des locaux.
Enfin bon, c’est juste une idée, ce qui est important pour moi, c’est qu’on en finisse une bonne fois pour toutes avec les mots de passe, qui sont source d’erreurs et de fuites de toutes sortes.
#9
Sûrement un outil de publication automatique avec un mot de passe faible. Un petit farceur a changé la date.
#10
Le problème d’un hashage sans sel, c’est qu’il est beaucoup moins gourmand en temps de calcul de faire de la recherche brute force sur des données non salées, et que c’est plus fragile pour les attaques arc-en-ciel. Par contre, on peut imaginer qu’il y ait un hashage non salé d’une information partielle ou d’une information résiduelle par rapport au mot de passe en clair (ce qui n’est pas une solution parfaite, mais tout de même plus sûre). Bon, vu le potentiel trollesque de l’article, c’est clair qu’il ne faut pas dire que le mot de passe est partagé par telle ou telle personne, mais qu’un mot de passe similaire a déjà été utilisé
Cela dit, tout ça n’a pas vraiment d’intérêt : en général, les gens ne partagent pas un même mot de passe entre deux comptes, ils s’échangent carrément leurs couples id/pass :3
#11
Youhou !!!! Une API à mon nom !!!!
#12
Sur le billet indiqué par Tandhruil, il est dit :
le troisième facteur serait « quelque chose qui vous constitue », et serait basé sur un échantillon de votre ADN ou de votre sang
Le troisième facteur est donc un pacte signé de notre sang !!!
…C’est moi où il y a une odeur de poisson ?
#13
Il ne faut pas haïr les mots de passe en général. Dans la très grande majorité des cas, ils font très bien l’affaire. La sécurité doit être proportionnée au risque. Je n’ai pas envie d’utiliser de l’authentification à deux facteurs pour mes comptes sur des boutiques en ligne ou sur des forums spécialisés qui ne présentent quasiment aucun intérêt pour un attaquant.
#14
#15
Régime avec sel, à chaque appel un résultat différent:
mkpasswd -m sha-512 MonPassSalé
\(6\)pgVXRGi1DCXc84OC$YkiJvi16yCTUcREosnGOkEbxiPZeiiH1uG0HHmCUckq6qmQbMjHePHO7wyV75n8ll0/YB5aqyCjZBgyaMdqWy/
mkpasswd -m sha-512 MonPassSalé
\(6\)ObZkwnpLhoHoccge$fvvY2uHf.AchWLR2h3mg/lWgDRvx7V3NV7tOIMR4dfpaccSHFkuSZmXI6/civOi9ATEy3SpSweTH/Gc7TKO3Y0
Régime sans sel (ici imposé), a chaque appel on a alors le même hash:
mkpasswd -m sha-512 MonPassRegimeSansSel -S “BEEFBABE”
\(6\)BEEFBABE$KU/4/JXYZQplA2Scb623nG4nZ5cZ54jyT71Rp50UA7sFaUxRPG1TGv3rXK64A/IQtj8gPi.5ZIEdIsEGemxGo0
On remarque que la BEEFBABE se retrouve avant le hash. Idem avec la version salage au dessus, mais par défaut aléatoire. Avec un hash qui ne sera jamais le même.
#15.1
Attention, un régime avec une pincé de sel identique pour tout le monde n’est pas la même chose qu’un régime sans sel.
Dans le premier cas, une attaque par table arc-en-ciel n’est pas possible (enfin si, mais il faut la construire soi-même, ce qui demande quand même pas mal de temps). Dans le second, il suffit de prendre la première que l’on trouve sur le net.
Pour le premier cas, à noter également que la taille de l’entreprise joue. S’amuser à générer une table arc-en-ciel pour une entreprise de 2 personnes, ce n’est pas très utile. Pour une entreprise de la taille du CERN (plus de 17000 personnes) cela commence à valoir le coup/coût.
#15.2
En fait, même si tu as un sel différent par personne, tu peux tester si deux personnes ont le même mot de passe, au moment où l’un des deux le saisit. Il suffit de le tester avec le sel de chaque utilisateur, et de vérifier si le hash correspond. Ce n’est pas le même problème que, à partir seulement des hash, déterminer si deux utilisateurs ont le même mot de passe (ce qui sera beaucoup plus coûteux).
C’est linéaire au nombre d’utilisateurs, mais je pense qu’à 20000, ça passe encore crème.
#15.3
Effectivement. Mais bon, quoi qu’il en soit, c’est tellement ubuesque comme idée (unicité des mots de passe), qu’une personne sensée ne ferait jamais une telle idiotie !
#16
“le CERN a, d’une manière ou d’une autre, accès aux mots de passe en clair, ce qui est contraire aux règles élémentaires de sécurité.”.
Pas sûr… Si le système utilise un système de chiffrage / déchiffrage bijectif (= surjectif & injectif), ok pour le dire simplement, correspondance mathématique 1 pour 1 ,unicité. Genre si je vois 2 mots de passe CHIFFRÉS IDENTIQUES, alors il est vrai que les 2 mots de passe en clair (dont je n’ai pas accès et la connaissance) sont donc eux aussi IDENTIQUES.
Aussi dit autrement :
2 mots de passe en clair sont IDENTIQUES SI ET SEULEMENT SI 2 mots passes chiffrés sont IDENTIQUES.
(note: je ne suis pas prof de maths, mais après recherche sur le net, il semble tout à fait plausible si l’on choisit un algorithme de chiffrement qui va bien… et non pas une simple fonction HASH qui elle est surjective par nature)
#17
‘tain ! ils s’y prennent à l’avance au CERN pour la marchandise de l’avatar de DantonQ-Robespierre !
Sinon, l’article est lourd à lire, bien loin de la finesse du billet du CERN.
#18
Pas d’accord: Avec ce mode d’authentification on n’a besoin de rien d’autre que sa tête. Ce qui n’est pas le cas des authenticator/yubikey etc en double facteur et autres clef de connexion avec passphrase ou biométrie. Sans le matos sur soi, c’est mort.
Tout ce bazar n’apporte pas grand chose comparé à un mdp de bonne complexité. Certes, y’a toujours le risque keylogger mais sur une machine interne s’il y en a un en embuscade c’est qu’on a déjà un pb de sécurité informatique ou physique poutrée.
En tous cas, quand on stocke des passwd en clair ou non salés on n’a pas les couilles plus propres que les utilisateurs qu’on se permet de blâmer.
Niveau multiples facteurs, en prime, il y a un effet pervers majeur je pense: Habituer l’utilisateur à rentrer des éléments d’authentification variés sans plus se demander si cela a un sens!
Là ou je bosse, on a aussi nos connards a qui on a vendu le “zero trust model” et actuellement tu commences par rentrer ton adresse mail, ce qui te redirige vers le login interne de la boite car on a externalisé largement l’IT… qui va te demander un code authenticator ou autre avec une pop-up en plus, qui revient parfois aléatoirement en cours de session ou si tu utilise d’autres outils (outlook te l’a demandé à l’ouverture, teams te redemande souvent un code ensuite, parfois avec une redite login parfois non, puis certaines pages intranet…).
Je pense que ceux qui font du social engineering et qui étaient emmerdés par des années à apprendre aux utilisateurs à faire attention aux demandes d’authentification bizarres vont se régaler!!! Là, tout le monde subit et au bout de 3j de ce foutoir réponds sans se poser de question, parfois en se trompant de pop-up (j’ai vu des passwd de collègues remplis machinalement dans le champ mot de passe avant redirection… qu’ils ne changent même plus après ce type d’erreur/affichage, de peur que le foutoir ne tombe plus en marche et en se disant “y’a la doublette d’authenticator qui fera le job”: Fatalement, combien sont déjà revenu en simple facteur, la pénibilité en plus.
Le cirque de la sécurité, avec ceux qui le mettent en place qui n’y comprennent visiblement plus rien eux-mêmes.
Ne parlons pas côté bancaire des codes chiffres sans lettres/caractères spéciaux qui offrent moins d’entropie… et brisent les stratégies de création de mots de passe des utilisateurs! Après cela, on peut bien coller du double facteur et imposer une app à la con sur un débilophone troué.
#18.1
Haaa merci @YL, je me sent moins seul !
#19
En fait, comme ce qui est comparé au final, ce sont les hash, peu importe que les deux mots de passe soient différents au départ ou non, s’ils ont le même hash, ils permettent tous les deux l’authentification.
D’où l’intérêt de choisir des hachages où les collisions sont hautement peu probables (pour rappel, avec 256 bits on a plus de possibilités que le nombre d’atomes dans l’univers, donc y a de la marge pour que ça tombe mal).
Sinon, merci pour le partage, les poissons eux aussi sont en avance cette année, probablement un effet du réchauffement climatique
#19.1
Ha oui, j’avais oublié ce point, que la plupart des systèmes (dont le GSM d’ailleurs, le code inscrit dans la SIM n’est pas transmis, c’est son hash qui sert pour l’authentification sur le réseau), ne vérifient pas le MdP mais l’empreinte de celui-ci et en effet avec des hashs (par design many-to-one) qui génèrent potentiellement beaucoup de collisions, ça peut poser problème.
Merci pour la remarque !
#20
C’est vrai que cela complexifie quand même bien les choses en pratique. Mais à l’essai mkpasswd ne semble pas permettre un non salage (ou sel de taille nul), même préfixé du caractère $ censé virer les check de taille du salage d’après le man: Possibilité disparue (de même, donc, que saler avec le username qui peut être sous les 8 caractères?)???
#21
#22
Ce billet est bien frais : il vient directement du marché à côté du CERN par char à bœufs.
#22.1
Warning, Achtung, Attention :
Il ne faut pas saler la viande de votre animal pour la Pet Side Authentification Climax Procedure par ADN…
#22.2
Le marché de LuCERN
#23
Tout à fait. Mais du coup ça veut dire que les mots de passe sont peut être “hachés” mais pas salés.
C’est moins bon. 😁
#24
Préparer son poisson 10 jours avant c’est chaud quand même… Il ne va plus être très frais 😅
#24.1
NextInpact dans environ 1 semaine :
#24.2
Je vais inventer un nouveau style d’identification : des mdp composés uniquement d’odeurs de poissons ! Par exemple, mon mdp serait : “Anguille-merlu-maquereau-thon-moule” (un par doigt).
…Alors, c’est qui le pur génie ?
#25
« n → p + e - + v » c’est un mot de passe relativement fort non, notamment du fait que le caractère « → » n’est pas facilement accessible.
#26
c’est une interaction faible, alors que le “mot de passe fort” est en réalité la formule de l’interaction forte
#27
Pour les gens que ça intéresse, l’article du CERN est aussi disponible en français.
#28
#29
“un message vous informera, par exemple, que tel mot de passe est déjà utilisé par « stefan24 »”
C’est pratique pour ne pas avoir à brute forcer le passe de ce stefan.
Zut, je n’avais fini de lire le paragraphe.
J’aurais bien fait de lire les commentaires aussi.
#29.1
Indice : stefan24 et ludwig20 ont le même mot de passe.
#29.2
Ca fait quelques mois que je vois ces “fails” à coup de “Votre mot de passe est déjà utilisé par Machin”, ça sent plus la légende urbaine qu’autre chose j’ai l’impression. Et le CERN a juste eu envie de surfer dessus.
Bawi, ils mettent tous “Cern2023!” comme mot de passe.
Edit : N’empêche pour les mauvaises pratiques, un exercice intéressant quand vous êtes à un RDV dans une agence ou un bureau quelconque. Ayez les yeux baladeurs sur le poste de travail. Mes stats perso : 1 chance sur 4 d’avoir un post-it avec des credentials. Et 3⁄4 que le mot de passe soit “EntrepriseMoisAnnée!” ou “Entreprise!MoisAnnée”.
#29.3
Tu les as lus ?
Leak.
Il y avait de l’idée.
#30
Elle pue ton idée, littéralement.
#30.1
Quoi ? Elle est pas fraîche son idée ?
#30.2
Elle sent le poisson de l’an passé !
#31
Les mollusques ne sont pas des vertebrés.
Il n’y a pas non plus d’équivalence entre le pouce et le coquillage. Mais certains l’ont en effet prétendu au soleil. (la prochaine fois prévoyez la crème solaire…)
#32
Je pense que le 2FA c’est temporaire.
Le second facteur va devenir (est déjà) le véritable élément d’authentification.
il est beaucoup plus sécurisé que le password car:
le premier facteur (mot de passe) n’est qu’une barrière pour éviter que n’importe qui puisse déclencher une demande d’authentification et que le titulaire légitime reçoive des tonnes de SMS.
Dés lors qu’on abandonnera l’envoi des SMS/Messages et qu’on passera aux OTP générés par un programme/appareil, le premier facteur ne servira plus à rien.
#33
Absolument pas. Les deux sont complémentaires. Un élément seul, que ce soit le mot de passe ou bien l’OTP présente des risques :
Les deux facteurs ont des objectifs différents :
#34
Trop tôt cet article a une semaine d’ avance !
#35
Problème solutionné en impliquant l’identification biométrique sur le générateur du OTP.
Donc c’est géré du coté “client”: une chose de moins à gérer par le serveur.
Et donc une problématique de moins à “confier au” serveur = moins d’info personnelle à fournir.
Si seul le possesseur de l’appareil autorisé peut générer l’OTP, alors le problème d’authentification est résolu.
Dans les faits, ca revient à déporter coté “client” une identification biométrique demandée par le serveur. Avec l’avantage que le serveur n’a pas à connaitre les données biométriques.
#36
C’est juste que tu remplaces le ce que l’on sait par ce que l’on est. Mais ça reste du 2FA, car couplé avec “un ce qu’on a”.
Et c’est à considérer que le biométrique est infalsifiable. Ce qui est malheureusement loin d’être le cas :
Il existe encore d’autres méthodes biométriques, comme la posture lors de la marche, ou la forme du lob de l’oreille ou encore celle de l’iris, mais qui semblent difficilement utilisables pour la sécurisation d’objet comme un smartphone.
#37
hmm. Je vois plutôt les choses comme cela:
Aujourd’hui avec le 2FA traditionnel tu as effectivement un mdp et un OTP. Mais si tu utilises KeePassXC (par exemple), tout est stocké dans KeePassXC. Et les envois des mdp+OTP sont automatisés. Donc il n’y a plus vraiment deux facteurs distinct mais un seul outil qui se charge de tout.
#38
#39
C’est une définition hautement personnelle qui est loin d’être partagé. L’interprétation courante, que l’on peut retrouver dans un document de l’ANSSI par exemple, c’est :
Ce que tu catégorises comme ce que l’on sait (clé privée/publique) est en réalité un ce que l’on a.
Il ne faut pas mélanger le niveau d’authentification requis pour accéder à un service et sa mise en oeuvre côté utilisateur :
Ce qui peut être troublant, c’est que les facteurs fournis par l’utilisateur et les facteurs fournis au service ne sont pas forcément les mêmes. Quoi qu’il en soit, c’est bien du 2FA dans chacun des cas, qu’importe que derrière il n’y ait qu’un seul et même outil.
#40
Peut-être, mais un mot de passe (voir plutôt une passphrase) de bonne complexité et avec une logique de variantes propre à l’utilisateur (selon le service auquel on se connecte), ce n’est en pratique pas plus mis en défaut que faire confiance à un crypto-bidule auquel pas grand monde ne comprends qqchose.
Puis encore une fois, on n’a besoin que de sa tête pour accéder, ce qui n’est pas sans présenter quelques avantages. Et la couper pour s’emparer du contenu que l’utilisateur ne veut pas donner ne fonctionnera pas, contrairement à un appareil et l’index servant à le débloquer (par exemple).
Les voyageurs professionnels des pays risqués ont aussi pour habitude de connaître par cœur leur numéro de passeport. C’est possiblement une bien meilleure garantie de rentrer chez soi en cas d’aléa que d’espérer toujours avoir le document dans sa poche.
#41
Le principe de 2FA c’est de fournir 2 preuves d’identité distinctes à un mécanisme d’authentification (cf wikipedia).
Actuellement le mécanisme est uniquement coté serveur, ce qui signifie que le client doit envoyer deux preuves qui sont chacune vérifiées par le serveur.
Je pense que l’avenir est de répartir le mécanisme entre le client et le serveur. Ce n’est que mon avis, hein. Mais le passé a montré qu’on a tendance a vouloir simplifier les opérations à effectuer coté client, parfois au détriment de la sécurité globale. Genre le paiement sans contact :)
#42
Et un gros inconvénient: la capacité de mémorisation
Tout ca représente une charge mémorielle énorme. Tellement énorme que ca ne laisse que 3 choix:
A. Entrainer son cerveau façon “palais mental”
B. Ne pas suivre toutes les bonnes pratiques ci-dessus.
C. Laisser un outil gérer tes mdp à ta place.
La solution A n’est pas pour tout le monde. La B présente des risques pour la sécurité. Reste donc la C qui revient à avoir un seul outil qui fait le 2FA… le transformant dans les faits en une seule opération d’authentification coté client => je dis à l’outil “ok, vas-y, authentifie moi”.
#43
Dans ce cas, ce n’est plus du 2FA. Pour qu’il y ait du 2FA, il faut que le serveur ait 2 mécanismes d’authentification distinct. Il ne peut en être autrement, car le serveur ne peut faire confiance au client. C’est la base de la sécurité ;)
#44
La définition du 2FA c’est de fournir 2 preuves au mécanisme d’authentification.
Rien ne dit que la verif est intégralement et uniquement faite sur le serveur hébergeant la ressource auquel on veut accéder. Il y a parfois de la délégation totale ou partielle de la verif des tiers de confiance. Par ex se logguer avec son id google sur un site xyz, ou se loguer avec son email pro sur microsoft.com: ca entraine une délégation partielle/totale vers un portail externe.
Et puis je fais confiance au marketing pour trouver un terme qui fait croire que c’est aussi bien voir mieux que du 2FA. Genre OCMSFA : One-Click Multi Secured Factor. Et hop.
#45
On est d’accord.
La partie en gras est extrêmement importante et tu sembles l’oublier lors de l’approche client/serveur. Du point de vue du serveur, le client n’est jamais, jamais, jamais un tiers de confiance.
Oui il est possible de déléguer l’authentification à un service tiers, mais il faut que ce service tiers soit de confiance. Je t’accorde que pour des raisons de simplicité, je ne l’ai pas mentionné dans mon précédent commentaire. Mais le client n’étant pas de confiance, il n’est pas possible de lui déléguer la vérification.
Sauf quand le 2FA est une obligation légale (cas notamment des banques et des services de paiement)
#46
Très bon exemple les services de paiement. On est typiquement dans le cas que je décris.
J’ai un smartphone sans carte SIM, donc pas de n° de téléphone => utilisation en wifi only, comme si c’était une tablette.
J’ai installé l’appli de verif de paiement de ma banque sur ce smartphone. Puis je l’ai paramétré pour qu’elle soit associée à mon compte bancaire (avec surement moultes échanges de clés, certificats, confirmations par code, … jusque ca soit reconnu).
Maintenant, pour confirmer un achat, l’appli de ma banque demande:
Donc au au final, la banque fait entièrement confiance à l’appli sur mon smatphone pour valider mon paiement.
Alors, une question se pose: c’est du 2FA ou pas du 2FA ?
#47
2FA. Car tu oublies de mentionner quelques “détails” :
Tu n’as peut être qu’une seule application, mais pour faire simple, cette application transmet à la fois un certificat ET un mot de passe => 2 facteurs donc 2FA.
Je vois de suite venir le coup du mot de passe qui est le mot de passe local de l’application. Ce n’est pas un problème, car il sert très certainement à déverrouiller un autre facteur derrière, comme le mot de passe pour l’accès à ton compte.
Et ne t’inquiète pas pour les banques. Autant certaines peuvent être laxiste sur certaines choses, autant la dessus, elles sont plutôt carrées. Car la jurisprudence était assez simple avant le déploiement du 2FA : en cas de piratage et si pas de 2FA, la banque était en tord et devait rembourser. Aujourd’hui, avec le 2FA, elles sont sensées rembourser, sauf à prouver une faute de la part du titulaire du compte (et c’est bien à la banque de prouver que le titulaire a été négligent, et non au titulaire de prouver qu’il n’a pas été négligent).