FantastIX a écrit 1338 commentaires

le multi-facteur ne protège pas contre la compromission du périphérique […]

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.

Pourquoi pas les deux ? Authentification à deux facteurs et enrôlement de la machine ?

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…

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.

Perso, je préfère l'expression "altération climatique" à "réchauffement", "dérèglement" ou "changement", qui exhibent bien moins l'aspect anthropique. C'est juste une parenthèse que je fais.

[…] le multi-facteur ne protège pas contre la compromission du périphérique […]

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.

[…] des code SMS […]

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¹.

Si tu veux du multi-facteur résistant au vol de terminal, il te faut trouver un moyen de forcer les utilisateurs à utiliser : […]

Perso, moi? Je ne veux rien. Mais si tu insistes…

• un terminal et un dispositif physique […]

À la bonne heure, voilà, on y est! C'est ce que je disais: les périphériques style YubiKey.

Ou pas:

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 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.

Non ce n'est pas normal :-)

Au risque de te contredire encore une fois: si, c'est 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.

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.

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.

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…

On ne confond pas climat et météo, ici, hein, n'est-ce pas?

J'ajouterai que si le résultat des syntaxe comme Markxxx est de rendre lisible un document, c'est en raison du faible bruit engendré par la décoration. Le "bruit" engendré par la syntaxe de décoration HTML rend la lecture d'un document au mieux difficile, au pire, à vomir.

Pour couronner le tout, la plupart des outils nécessaires au rendu HTML sont extrêmement gourmands en ressources¹. Le plus vorace est sans conteste le moteur de Chrome. On peut mieux faire.

Sinon il y a PDF mais il faut passer par une moulinette de conversion comme pandoc, par exemple. Noter que ce dernier s'applique à toute conversion, bidirectionnelle, entre formats, pas seulement Markdown ↔ HTML.

Il y a aussi la syntaxe Rich Text, poussée encore plus avant par LaTeX. Tout est question de combien de temps on veut passer sur la compréhension d'une syntaxe pour la rendre abordable à tous.

Il ne faut pas non plus perdre de vue que les développeurs, en général, n'aiment pas rédiger de la documentation. C'est juste pas leur tasse de thé café. Alors si c'est pour leur proposer des syntaxes imbitables, ça va pas arranger les choses…

Comme on peut le voir, on a le choix. Et restreindre ce choix à juste une seule syntaxe, quelle que soit l'argumentation, reviendrait à oublier les raisons pour lesquelles on a justement cet éventail de possibilités.

---

¹ Ouais, je sais, il y a links, très connu des utilisateurs de clic-o-dromes… Ahem… ;-)

Il faut passer par un système d'hébergement en ligne comme imgur.com. Certains outils de capture d'écran, tel que celui de Xfce, prennent en charge le dépôt d'une image vers ce service distant. Ensuite, il suffit de recopier l'URL dans le post avec le lien "Image" de l'éditeur de texte LinuxFr. Il existe une foultitude de services gratuits d'hébergement d'images sur la toile.

Par contre, il ne faut pas voir ça comme une disqualification de ma part.

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 ;-) .

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?

Je te remercie.

Parce qu'une majorité des arguments consiste simplement à lire la nouvelle, c'est bien pour ça que c'est du troll .

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.

Il faut lire l'article avant […]

Supposition gratuite ;-) . Bien sûr que je l'ai lu. Mal, de toute évidence.

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.

Tu ne vois vraiment pas en quoi réduire les risques de vol de compte augmente la sécurité ? Vraiment vraiment ?

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.

On appelle ça un procès d'intention.

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?

hmm… entre possible et possibles… -_-

Il n'est évidemment pas question d'auditer/certifier les développeurs de logiciels libres […]

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.

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

C'est pas faux ;-) …

Ah, merci mais c'est trop tard pour l'édition… Quand je parlais d'imbitable, c'était au nombre de lignes et à la complexité que je faisais référence, ceci dit. Mais bon, j'ai déjà vu plus compliqué en moins de lignes, aussi.

C'est fou ce qu'on peut apprendre des macros de GCC!

Bon, ceci sort du cadre de mon journal mais je voulais aussi afficher des statistiques/renseignements sur le projet, par exemple le nom du fichier d'entête, l'architecture, les fonctionnalités additionnelles, l'ordre des octets, etc. Après avoir "chipoté" quelques heures de plus, voici ce que j'ai fini par utiliser:

echo -e "#include <avr/io.h>\nvoid main() {}" | sort | \
avr-gcc -E -dM -Os -DF_CPU=16000000 -mmcu=atmega2560 - | \
sed -rn \
-e '/AVR_IOXXX/s/.*\s+"([^"]+)"$/MCU header: \1/p' \
-e '/__AVR_LIBC_VERSION_STRING__/s/.*\s+"([0-9\-\.]+)"$/AVR libc: version \1/p' \
-e '/__AVR_DEVICE_NAME__/s/.*\s+(\w+)$/device name: \1/p' \
-e '/__AVR_ARCH__/s/.*\s+(\w+)$/architecture: avr\1/p' \
-e '/SIGNATURE/{N;N;s/#define\s+SIG\w+//g;s/\n/,/g;s/^/signature:/gp}' \
-e '/RAMSIZE/s/.*\s+([0-9]+)$/RAM size: \1 bytes/gp' \
-e '/E2SIZE/s/.*\s+([0-9]+)$/EEPROM size: \1 bytes/gp' \
-e '/__SIZEOF_(SHORT|INT|LONG|FLOAT|POINTER|SIZE_T)__/s/.*__SIZEOF_(\w+)__\s+([0-9]+)$/\L\1 size: \2 bytes/gp' \
-e '/__BYTE_ORDER__/s/.*__ORDER_(\w+)_ENDIAN__/byte ordering: \L\1 endian/gp' \
-e '/_AVR_HAVE_(MUL|MOVW|E?LPMX?|E?JMP_E?CALL|RAMP[DXYZ])/{s/.*HAVE_(\w+)__.*$/\1/g;H}' \
-e '${x;s/\n|_/ /g;s/^/features:/gp}'

C'est imbitable, hein? C'est normal. Comment ça fonctionne? avr-gcc -E invoque le préprocesseur sans compiler quoi que ce soit. La source est une simple fonction main() avec le fichier d'en-tête minimal, io.h. Dans tout ce bazar, sort est essentiel! Ensuite, vient l'analyse:

• la macro __AVR_IOXXX__ contient le nom du fichier d'en-tête spécifique au processeur,
• décortiquer __AVR_LIBC_VERSION_STRING__ et ne prendre que la chaîne correspondant à la version de avr-libc,
• faire pareil avec __AVR_DEVICE_NAME__ et __AVR_ARCH__,
• la signature est répartie sur 3 lignes, du style #define SIGNATURE_[012] 0x[0-9]+; on jumelle ces trois lignes en ne retenant que les valeurs hexadécimales,
• les macros RAMSIZE et E2SIZE sont décortiquées comme __AVR_DEVICE_NAME__,
• extraire les tailles pour des types intéressants (short, int, float, etc.) en rappelant le nom du type, gentiment converti en minuscules (\L)
• faire de même pour l'agencement avec __BYTE_ORDER__, dont on ne retient que le terme du milieu (peut être "LITTLE", "BIG" ou "PDP")
• extraire les fonctionnalités __AVR_HAVE_XXX__ et les joindre sur une seule ligne.

Toutes ces transformations sont aussi préfixées par une étiquette. Voici ce que ça donne, par exemple pour un ATmega2560:

architecture: avr6
device name: atmega2560
MCU header: iomxx0_1.h
AVR libc: version 2.1.0
byte ordering: little endian
signature: 0x1E, 0x98, 0x01
float size: 4 bytes
int size: 2 bytes
long size: 4 bytes
pointer size: 2 bytes
short size: 2 bytes
size_t size: 2 bytes
features: ELPM ELPMX JMP CALL¹ LPMX MOVW MUL RAMPZ

Dans un autre fil, j'ai avoué que je sed souvent à la difficulté. Ben voilà.

La documentation se trouve ici: https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html

¹ Noter que les valeurs JMP et CALL sont liées par un underscore avec la macro _AVR_HAVE_JMP_CALL__. J'ai simplement remplacé dans la foulée ce dernier par un espace, comme le marqueur de fin de ligne.

Ben… tu prends un miroir et tu regardes ce que ça donne. Ou alors tu imprimes à l'envers (retournement autour de l'axe vertical).

Suivant.

Ta suggestion a piqué ma curiosité et j'ai essayé d'arriver à ce résultat avec uniquement le préprocesseur avr-cpp. Et bingo! Voici ce que ça donne avec un "bête" programme de démo pour le ATtiny1634, par exemple:

avr-cpp -E -dM -Os -DF_CPU=8000000 -mmcu=attiny1634 demo.cpp | \
sed -rne 's/#define\s+(\w+)\s+_SFR_([IM]\w+[0-9]+\(\w+\))/\1: \2/p'

En gros, ça n'affiche que les lignes de définition des registres (SFR_IOxx et SFR_MEMxx) et le résultat est le suivant:

TWSSRA: MEM8(0x7D)
EECR: IO8(0x1C)
EEDR: IO8(0x1D)
OSCCAL0: MEM8(0x63)
MCUCR: IO8(0x36)
PINA: IO8(0x0F)
PINB: IO8(0x0B)
PINC: IO8(0x07)
...

Note que les options -O et -DF_CPU= sont nécessaires pour éviter un avertissement (généré dans les en-têtes).

Il "suffit" de tripatouiller le script sed pour adapter la sortie en fonction du langage souhaité. Moralité: on a déjà assez avec les outils de base.

C'est bien entendu un premier jet car, tu l'auras remarqué, on perd l'info du processeur et du fichier d'en-tête incorporé. Je pense que c'est l'objet de l'option -d du préprocesseur. Je suis à peu près certain que c'est là-dessus qu'il faut jouer.

Merci, et aussi pour le tuyau.

Perso, je me tapais la liste des registres en les pompant depuis la fiche technique (toujours avec un script de mon cru pour formater les résultats). Du coup, je construis cette liste à mesure des micros dont je me sers et j'étoffe les scripts en fonction. Avec une liste prête à l'emploi, je pourrai effectivement répartir les registres par architecture et les spécificités par-CPU.

Jusqu'à présent, j'ai eu la flemme de "parser" les fichiers *.h pour en faire quelque chose :-D .

pour quelle(s) raison(s) as-tu choisi, pour ce nouveau projet, cette forge plutôt qu'une autre ?

La raison est toute simple: à l'époque où je me suis créé un compte (2005), github, gitlab et cie n'existaient pas encore. Les offres étaient limitées et Sourceforge jouissait encore d'une bonne réputation.

J'ai ensuite voulu découvrir autre chose mais Github, c'est non pour moi — bien qu'un compte soit obligatoire dans certains projets pour le rapport de bugs et ça me gave un peu, d'ailleurs. J'ai aussi essayé Savannah pour son hébergement éthique, il y a quelques jours. Mais le temps qu'il faut pour seulement déposer une archive dépasse les trois jours… un peu gros quand c'est le seul maillon à prendre autant de temps dans la chaîne. C'est sans doute la rançon du peer-reviewing¹, nécessaire dans de tels cas, j'imagine mais c'est bien frustrant.

Donc je suis resté avec mon compte Sourceforge. Il a le mérite de déjà exister et de ne pas (plus) me prendre la tête.

---

¹ Je l'appelle ainsi mais sans savoir si c'est le nom approprié.