Une partie du problème avec les « gestes de déverrouillage » est que les gens ont apparemment encore moins d’imagination pour créer de tels gestes que pour créer des mots de passe.
trouver un geste de déverrouillage avec une bonne sensibilité, sans accès à l'écran, avec juste l'accéléromètre du téléphone.
Avec l’accès aux données des capteurs du téléphone (accéléromètre et autres), on peut craquer non seulement les « gestes de déverrouillage » mais aussi les PIN « classiques » (Aviv et al. 2012, Mehrnezhad et al. 2017).
Les auteurs de Meltdown ne savent pas très bien pourquoi leur attaque n’a pas réussi sur les processeurs AMD et ARM, mais les tests qu’ils ont réussi à faire montrent qu’avec ces processeurs aussi, les contrôles sont fait a posteriori :
However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and and instructions past illegal memory access are also performed.
Pour les auteurs, il semble établi que, sur le papier au moins, Meltdown devrait fonctionner aussi sur des processeurs non-Intel, il n’y a pas de différence conception suffisamment grande entre les fondeurs. Ce n’est peut-être qu’une question de temps avant de voir débarquer une version de Meltdown qui fonctionne sur d’autres processeurs.
Pourquoi serait-il normal de prendre ce risque, et surtout d'affirmer que non non c'est normal qu'on fasse ça ?
Parce qu’on n’imaginait pas à l’époque le genre d’attaques par canaux cachés que l’on imagine à présent.
Peut-être que les ingénieurs de l’époque étaient nuls, peut-être qu’ils étaient tous achetés par la NSA. Ou peut-être qu’ils n’avaient pas le bénéfice des quinze dernières années de recherche.
Il existe des cas où l'on découvre une nouvelle catégorie de problèmes/bugs, et forcément on n'avait pas mis en place des solutions aux problèmes/bugs que l'on ne connaissait pas encore.
Si c’est réellement le cas (je ne prétends avoir fait le tour de la littérature sur la question, peut-être qu’il y a des travaux plus anciens), je pense qu’on peut difficilement reprocher aux fondeurs de n’avoir pas su empêcher, dans leurs designs datant pour certains du milieu des années 90, des attaques qui ne seront imaginées que dix ou quinze ans plus tard.
Intel est la risée d’Internet pour avoir dit ces derniers jours, en substance, « nous n’avons pas merdé, nos processeurs fonctionnent exactement comme prévu », mais ils n’ont pas forcément tort sur ce point.
J'ai eu confirmation que c'est bien Linus qui a dévoilé la faille le premier en poussant les patchs avant terme.
D’après le dernier article d’Ars Technica, c’est un développeur AMD qui a mis la puce à l’oreille de tout le monde en postant le patch qui désactive la mitigation pour les processeurs AMD (et dont le commentaire était un peu trop bavard).
It was this specific information—that the flaw involved speculative attempts to access kernel data from user programs—that arguably led to researchers figuring out what the problem was.
ça pourrait passer inaperçu car ça ne laisse pas de traces sur le système, mais les personnes au courant ont fait de gros efforts pour voir si ces failles étaient déjà utilisées dans la nature, on peut donc leur accorder un certain crédit
En même temps, si l’exploitation de la faille ne laisse pas de traces, même en faisant « de gros efforts » on ne voit pas ce qui est invisible, alors sans aucunement remettre en cause le crédit des « personnes au courant », le fait est qu’on ne sait pas si les failles ont été exploitées.
Point de vue pessimiste : les failles ont été découvertes par plusieurs personnes indépendamment (au moins trois équipes différentes si j’ai bien suivi), donc on peut raisonnablement supposer qu’elles aient aussi pu être découvertes par d’autres acteurs.
Point de vue optimiste : les failles ont été découvertes par plusieurs personnes à peu près au même moment. Comme il est peu probable que toutes ces personnes aient toutes eu le même coup de génie au même moment, ces découvertes sont probablement l’évolution logique de travaux antérieurs. On peut donc selon moi tout aussi raisonnablement penser que si des acteurs mal-intentionnés ont eux aussi découvert ces failles, ils l’ont fait eux aussi à peu près au même moment (mi-2017 en gros), et donc que si ces failles sont exploitées elles ne le sont pas depuis longtemps.
Bref est-ce que ce ne serait pas une estimation faible de l'entropie ?
Si. En négligeant l’entropie structurelle ou de configuration (l’entropie provenant de la manière dont le mot de passe est construit : est-ce que c’est un mot choisi dans le dictionnaire ? Deux mots choisis dans le dictionnaire ? Un mot du dictionnaire suivi de deux chiffres ? Un mot du dictionnaire renversé suivi d’une date suivi d’un motif de six lettres sur un clavier QWERTY ? etc.), on sous-estime nécessairement l’entropie totale du mot de passe.
Je cite Daniel Wheeler (principal auteur de la Zxcvbn originelle) à ce sujet :
I’m OK [with disregarding configuration entropy] for tree reasons:
It’s difficult to formulate a sound model for structural entropy; statistically, I don’t happen to know what structures people choose most, so I’d rather do the safe thing and underestimate.
For a complex structure, the sum of the pieces alone is often sufficient to give an “excellent” rating. For exemple, even knowing the word-word-word-word structure of correcthorsebatterystaple, an attacker would need to spend centuries cracking it.
Most people don’t have complex password structures. Disregarding structure only underestimates by a few bits in the common case.
Je ne prétends pas que le nom retenu soit le meilleur, mais il n’est pas possible de contenter tout le monde.
Par exemple, si j’avais choisi un des noms que tu proposes, on m’aurait peut-être fait la même remarque que la dernière fois que j’ai présenté un outil dont le nom comportait un tiret (à savoir, ce n’est pas pratique, c’est à éviter).
Du coup je ferais la même réponse que la dernière fois : si c’est vraiment important, change le nom du binaire pour ce que tu veux avec l’option --program-transform-name lors de la configuration.
Pour ce qui est du nom du projet lui-même (pas le binaire), j’ai pris scorepw pour la simple raison qu’une recherche Google ne rapportait aucun autre projet similairement nommé (contrairement à des alternatives comme « password checker » ou assimilés).
Maintenant, je me demande ce qu'il en est pour quelque chose de bien plus court mais finalement très similaire : ✔️🐎🔋📌
Alors, je te déteste (cordialement, hein), parce que tu mets précisément le doigt sur une situation où scorepw ne va servir à rien…
Comme je le mentionne en fin de journal, scorepw (ou plus exactement, les bibliothèques dont il dépend, notamment Zxcvbn-C) fait plus ou moins n’importe quoi en présence de caractères non-ASCII. C’est valable pour les caractères accentués, c’est a fortiori valable pour des caractères de ce genre.
À mon avis, tous ces résultats surestiment largement le « mot » que tu donnes.
C’est particulièrement vrai pour Zxcvbn-C, qui ne connaissant pas UTF-8 traite en fait ✔️🐎🔋📌 comme un mot de 18 caractères dont les valeurs s’étalent sur toute la plage de 0 à 255 (d’où une estimation d’entropie qui crève le plafond mais à laquelle je ne me fierai pas).
Zxcvbn-CPP s’en sort mieux en considérant correctement 4 caractères Unicode au lieu de 18 octets, mais même comme ça l’entropie estimée me semble trop haute.
En général, quand on estime l’entropie d’un mot de passe, on part du principe que la « structure » du mot de passe (comment il est formé) est connue de l’attaquant. Par exemple, quand Randall estime que correcthorsebatterystaple a environ 44 bits d’entropie, c’est en supposant que l’attaquant sait que le mot de passe est formé de quatre mots courants choisis au hasard.
Une estimation correcte de ✔️🐎🔋📌 qui suit le même principe devrait à mon avis assumer que l’attaquant sait que le mot de passe est formé non pas de quatre caractères Unicode arbitraires (choisis dans la totalité d’Unicode), mais de quatre « symboles » provenant d’une plage restreinte d’Unicode (par exemple la plage des « Mscellaneous SYmbols », de U+1F300 à U+1F5FF).
C’est peut-être d’ailleurs ce que fait l’implémentation CoffeeScript de Zxcvbn, parce qu’elle considère ce mot de passe très moyen (à juste titre selon moi).
Mais 16 bits pour les 9 lettres, j'ai plus de mal à comprendre…
Il s’agit de 16 bits pour un mot (ici troubadour) choisi dans une liste comprenant entre autres des mots peu communs (« uncommon (non-gibberish) base word »), contrairement au cas du correcthorsebatterystaple qui ne comprend que des mots choisis dans une liste de mots plus courants (une liste forcément moins longue qu’une liste comprenant des mots courants et des mots moins courants).
Par exemple, le dictionnaire dont je parlais dans le journal constitué à partir des mots de la Wikipédia anglophone comprend exactement 100 000 mots, donc le choix d’un mot dans cette liste apporte ~16.6 bits d’entropie, soit à peu près ce qu’a retenu Randall.
J'ai l'impression que beaucoup de gens sont chez un hébergeur et je m'en viens a me demander pourquoi?
Une raison parmi d’autres : je viens de déménager et il m’a fallu pas moins de six semaines pour avoir une connexion Internet dans mon nouvel appartement.
J’étais bien content que mon serveur mail/contacts/agenda/etc. soit bien au chaud dans un datacenter bien connecté d’où je pouvais toujours le joindre avec le peu de connectivité que j’avais (depuis mon lieu de travail ou en passant par mon téléphone avec des cartes 4G pré-payées).
L’auto-hébergement, c’est peut-être bien pour quelqu’un qui a une situation raisonnablement stable. Mais quand on ne sait pas où on sera dans deux ans (dans quelle ville voire dans quel pays), quel service on pourra avoir (FTTH ? FTTC ? ADSL ? port 25 ouvert ? adresse IP fixe ? IPv6 ?) et à quel prix, ou combien de temps ça va prendre (deux jours, deux semaines ou deux mois ?)… non merci.
Donc au final tu admet que Let's Encrypt est un gain net en sécurité par rapport à un certificat signé par une CA non reconnuee…
Pas du tout.
Je suis un utilisateur, je me connecte à un site qui me présente un certificat signé par une autorité reconnue et donc mon navigateur ne me dit rien du tout. Quelle certitude ai-je que je ne suis pas victime d’une attaque de type MITM ?
Aucune. Point.
Oh, certes, peut-être que la nécessité pour l’attaquant de devoir obtenir un certificat signé par une CA reconnue (ou par une sous-CA totalement inconnue) réduit quelque peu la probabilité de ce genre d’attaque, en la réduisant à ceux qui savent où et comment obtenir un certificat frauduleux.
Mais une mesure de « sécurité » qui ne fonctionne que dans l’hypothèse heureuse où l’attaquant n’a pas beaucoup de moyens, et ne me donne comme seule garantie que « vous n’êtes probablement pas attaqué, sauf si vous l’êtes »… je n’appelle pas ça un « gain net en sécurité ».
Contrairement à HPKP par exemple, qui après la première connexion alertera immanquablement l’utilisateur de toute tentative d’attaque. Ça c’est un vrai gain en sécurité. Seulement la vrai sécurité, c’est chiant, c’est difficile, alors on vire parce que dire qu’on se préoccupe de la sécurité est plus important que de prendre la peine de le faire effectivement. (La raison avancée par Google pour virer HPKP est que les administrateurs de serveurs ne savent pas gérer ça correctement — ben oui, c’est difficile, la sécurité.)
Je maintiens : utiliser un certificat signé par une CA reconnue est une mesure de confort pour les utilisateurs, en aucun cas une mesure de sécurité. Ça ne veut pas dire que c’est mal, mais il ne faut pas se bercer d’illusion sur ce que ça apporte.
À moyen/long terme, l'idée c'est d'exposer les CA qui font n'importe quoi et les forcer à améliorer leurs procédures (ou a les faire sortir de la liste des CA reconnues).
Oui, je connais l’idée, merci. Et perso j’y crois autant qu’à la trickle-down economics …
HTTPS avec les CA par défaut c'est un peu léger mais Let's Encrypt et CT ne rendent pas la situation pire.
Let’s Encrypt, peut-être pas. Mais CT, si, absolument, en donnant encore plus d’importance aux CA et en empêchant activement toute méthode d’authentification alternative qui ne passerait pas par les CA.
Les CA font partie du problème, pas de la solution.
Donc voilà, il y a quoi comme faille dans Thunderbird ?
À ma connaissance les vulnérabilités découvertes dans Thunderbird n’ont pas été rendues publiques, contrairement à celles de Enigmail. La raison en est que si les vulnérabilités d’Enigmail ont déjà été corrigées (version 1.9.9 publiée le 19 décembre), ce n’est pas (encore) le cas pour Thunderbird, apparemment car les vulnérabilités découvertes ont une cause profonde, liée à l’architecture même du logiciel, et de fait ne se corrigent pas en quelques jours.
The add-on architecture of Thundebird allows an attacker to obtain your email communication through compromised add-ons. The add-ons are insufficiently separated and have access to the content in Thunderbird. This includes end-to-end encrypted communications: Even a users private PGP keys can fall into the hands of an attacker.
À première vue quelque chose ne colle pas ici : si on peut aisément concevoir qu’un défaut d’isolation des greffons permette à un greffon d’accéder à n’importe quelle donnée au sein de Thunderbird, cela ne suffit pas à mettre en danger les clefs OpenPGP privées qui ne sont jamais manipulées directement ni par Thunderbird ni par Enigmail. Il y a une double indirection entre Thunderbird/Enigmail et les clefs OpenPGP : Enigmail délègue le déchiffrement (ou la signature) d’un message au programme gpg qui lui-même délègue toute opération impliquant une clef privée à l’agent GnuPG, qui est le seul programme à manipuler les clefs privées directement.
Pour qu’un greffon Thunderbird permette à un attaquant d’accéder « même aux clefs OpenPGP privées », il faudrait que les vulnérabilités donnent un accès non seulement à Thunderbird lui-même, mais à travers lui à tout le système de fichiers (permettant d’exfiltrer un fichier arbitraire).
Malheureusement, la suite du message de Posteo.de sous-entend que c’est précisément le cas :
Here, even Enigmail cannot improve the situation. It is even possible for an attacker to use compromised Thunderbird add-ons and gain access to parts of your device and your sensitive data.
Je note que si c’est réellement le cas, vos clefs OpenPGP privées devraient être le dernier de vos soucis. D’une part, elles sont de toutes façons stockées sous forme chiffrée en permanence (l’agent GnuPG ne les déchiffre qu’en mémoire, juste avant de les utiliser quand il en a besoin, et les efface de sa mémoire aussitôt après) et donc pour peu que vous avec une phrase de passe décente, l’attaquant qui les exfiltrerait ne se retrouverait pas plus avancé.
D’autre part et surtout, si l’attaquant peut accéder à l’ensemble de votre système de fichiers, pourquoi chercherait-il vos clefs OpenPGP alors qu’il peut déjà récupérer tous les documents qu’il veut, à la source, en clair ?
PS: avec NextCloud, on a un vrai client de synchro headless ?
Le client Owncloud (qui fonctionne tant avec Owncloud qu’avec Nextcloud) a un client en ligne de command owncloudcmd. Il dépend toujours de Qt (Qt5Network, Qt5Core, etc.) mais fonctionne sans serveur graphique.
Toutefois, contrairement à son homologue graphique, owncloudcmd fait une synchro puis se termine — il ne reste pas à monitorer les fichiers et refaire une synchro en cas de changements.
Bof, il suffit de trouver une CA peu regardante. Avec certaines, on peut même obtenir (il suffit de demander) non pas un simple certificat frauduleux, mais un certificat intermédiaire permettant au titulaire d’émettre lui-même autant de certificats qu’il veut pour n’importe quel domaine.
De plus, si une attaque a lieu il est plus facile de la détecter a posteriori.
Ça fera une belle jambe à ceux qui ont été victimes de l’attaque avant qu’elle ne soit détectée. Ou à celui qui a été victime, si on parle d’une attaque ciblée ne visant qu’une personne bien précise.
Ça par contre ce n’est pas mort puisque Google ne jure que par ça… et ça ne résoud absolument pas le problème. Oui, ça peut permettre une « détection a posteriori » d’une attaque. Ça ne change rien au fait qu’au moment où l’attaque se produit, mon navigateur acceptera sans broncher le certificat frauduleux présenté par l’attaque, Certificate Transparency ou pas.
On peut aussi argumenter que le fait que Let's Encrypt force le renouvellement de certificat régulier force les utilisateurs à automatiser et sécuriser le processus. Alors qu'auparavant c'était souvent fait de manière ad hoc.
est ce que ce certificat apporte vraiment plus de sécurité?
Non. En l’état actual de PKIX, un certificat signé par une autorité de certification reconnue (qu’il s’agisse de Let’s Encrypt ou d’une autre) n’apporte aucune sécurité supplémentaire par rapport à un certificat signé par une autorité non-reconnue.
La seule chose qu’apporte la signature par une autorité reconnue est l’absence de message d’erreur côté client, sans que les clients aient quoi que ce soit à faire (comme installer le certificat racine d’une autorité privée). C’est une mesure de confort, pas de sécurité (ce qui n’est pas négligeable pour autant).
Avec un certificat auto-signé, tes clients sont protégés contre un attaquant passif mais vulnérables à une attaque active de type MITM. Avec un certificat signé par une autorité reconnue, ben… ils sont toujours vulnérables à une attaque active de type MITM, puisqu’il y a what mille autorités de certification là dehors qui peuvent délivrer un certificat frauduleux que les navigateurs des clients accepteront sans broncher (« bah quoi, il est signé par une autorité reconnue, alors c’est bon »).
Il se pourrait très bien qu'il y ait un module de gestion de photos avec du chiffrement côté serveur et un module de gestion de mots de passe avec du chiffrement côté client.
C’est le cas. Le chiffrement des fichiers de manière générale se fait côté serveur, mais Passman, le module de gestion de mots de passe, chiffre les mots de passe côté client. Le serveur ne voit jamais le mot de passe permettant d’ouvrir un coffre.
Pour les curieux, l’extrait de l’audit concernant Enigmail est disponible.
Sur la vulnérabilité TBE-01-002, je n’ai aucun commentaire à faire si ce n’est un doh! doublé d’un facepalm … Encore une excellente illustration de la loi d’Adi Shamir : Cryptography is bypassed, not penetrated. Pourquoi attaquer de front un algorithme de chiffrement quand on peut s’en prendre à une banale expression rationnelle ?
En revanche la vulnérabilité TBE-01-005 me laisse dubitatif. L’audit semble dire qu’Enigmail déchiffre automatiquement et silencieusement un bloc chiffré caché au fin fond d’un e-mail, permettant à un attaquant d‘obtenir une copie déchiffré d’un message simplement en l’insérant subrepticement dans le fil d’une conversation.
Je ne sais pas dans quelles conditions (p.ex. quelles versions d’Enigmail et/ou de GnuPG) ils ont testé ça (ni même si ils ont réellement testé ce scénario ou s’il s’agit juste d’une vulnérabilité théorique), mais le déchiffrement d’un bloc chiffré, même caché au fin fond d’un email de plusieurs centaines de lignes, n’est la plupart du temps pas silencieux puisque GnuPG doit demander à l’utilisateur de saisir la phrase de passe de sa clef privée. Ce n’est que si la phrase de passe est déjà dans le cache de l’agent GnuPG (donc si l’utilisateur s’en est servi dans les dix minutes précédentes, dans la configuration par défaut) qu’on ne lui demande rien. Ce n’est pas insurmontable pour l’attaquant (qui pourrait s’arranger par exemple pour envoyer lui-même un mail chiffré à sa victime quelques minutes avant de lui envoyer le mail contenant le message dont il veut obtenir le texte clair), mais ce n’est ni très discret ni aussi facile que ne semble le suggérer l’audit.
Ah, et sinon :
Enigmail est une extension pour Thunderbird permettant de chiffrer les communications en utilisant OpenGPG.
Je vais (encore) chipoter, mais « OpenGPG », ça n’existe pas. Piqûre de rappel :
PGP (Pretty Good Privacy) = le programme original, écrit par Zimmerman au début des années 1990
OpenPGP = le standard (RFC 4880) décrivant le format des messages et clefs manipulés par PGP
GnuPG (GNU Privacy Guard, parfois appelé gpg qui est en fait le nom du binaire principal) = une implémentation libre du standard OpenPGP
De mémoire, il n'y a pas de vaisseau automatique ou télécommandé dans cet univers (à part les sondes au début de Star Wars V ?).
Dans la trilogie originale, peut-être. Mais depuis, je suis sûr d’avoir vu des droïdes piloter des engins, y compris du côté de la République/de la Rébellion. Sans parler bien sûr de la flotte entièrement mécanisée de la Fédération du Commerce.
Et même si on s’en tenait uniquement à la trilogie originale : quand on a des droïdes médicaux capables de greffer une main artificielle, on peut facilement imaginer un droïde pilote.
Enfin bon, une incohérence de plus dans une série dont les trous scénaristiques sont tellement gros qu’on pourrait y faire passer un croiseur interstellaire de classe Executor, on n’est plus à ça près…
Merci pour ton expertise sur la solidité du chiffrage, je n'avais pas les connaissance nécessaire pour en juger.
Oui, alors euh mon « expertise » est uniquement basée sur ce que les développeurs disent qu’ils font. Je ne suis pas allé regarder le code pour savoir s’il fait correctement ce qu’il est supposé faire — même si j’avais voulu le faire, je ne suis de toute façon pas compétent pour juger de la qualité d’une implémentation (le code pourrait bien être truffé de failles de sécurité, je n’en rendrais jamais compte). D’où ma réserve à la fin, « si l’implémentation est correcte ».
D'ailleurs je suis preneur de critique sur ce logiciel
Indépendamment de ce logiciel, je ne suis pas fan de l’approche basée sur un master password dont les mots de passes finaux sont directement dérivés.
Le problème fondamental avec cette approche, c’est que si par malheur le mot de passe principal vient à être compromis, c’est jackpot pour l’attaquant, il peut dériver l’ensemble de tes mots de passe. Contrairement à un gestionnaire de mots de passe classique (qui stockerait les mots de passe dans une base chiffrée), il n’a même pas besoin d’exfiltrer la base de mots de passe, la simple connaissance du mot de passe maître est suffisante. Du coup, cette approche est potentiellement plus risquée qu’une approche « classique ».
Je note toutefois que contrairement à d’autres logiciels que j’ai pu voir basés sur la même approche, LessPass semble dériver les mots de passe finaux d’une manière cryptographiquement solide (PBKDF2 — encore que j’aurais préféré Argon2 qui est expressément conçu pour ce genre de choses, contrairement à PBKDF2 qui est plus un bidouillage), ce qui au moins devrait empêcher un attaquant de remonter au mot de passe maître juste en connaissant un mot de passe dérivé (sous réserve que l’implémentation est correcte).
Mais sous debian, je suis tombé sur des trucs assez moches, par exemple :
- opendkim utilise maintenant un unit systemd, mais il ne lit plus /etc/default/opendkim (bien que le fichier soit toujours installé par le paquet)
Il faut appeler le script /lib/opendkim/opendkim.service.generate pour que le contenu du fichier /etc/default/opendkim soit pris en compte.
Je n'ai pas le souvenir d'avoir entendu parler de la Turquie comme un paradis pour les femmes, ni les homos, ni les machins-choses
Moi si, jusqu’à ces dernières années.
Enfin, « un paradis », n’exagérons rien, mais la Turquie était probablement l’un des pays les plus progressistes de la région avant qu’Erdoğan ne lui fasse faire machine arrière toute vers le 19ème siècle.
[^] # Re: Et les « gestures » ?
Posté par gouttegd . En réponse au journal Microsoft voudrait de la biométrie. Évalué à 7. Dernière modification le 09 janvier 2018 à 13:15.
Même pas. Il suffit de te filmer discrètement à distance, sans jamais toucher à ton téléphone.
Une partie du problème avec les « gestes de déverrouillage » est que les gens ont apparemment encore moins d’imagination pour créer de tels gestes que pour créer des mots de passe.
Avec l’accès aux données des capteurs du téléphone (accéléromètre et autres), on peut craquer non seulement les « gestes de déverrouillage » mais aussi les PIN « classiques » (Aviv et al. 2012, Mehrnezhad et al. 2017).
[^] # Re: Et sur le fond?
Posté par gouttegd . En réponse au journal Microsoft voudrait de la biométrie. Évalué à 5.
Oui, tous les jours. Dans mon labo, l’accès est contrôlé par badge et digicode (le code étant propre à chaque badge).
[^] # Re: Bug (ou fonctionnalité ?)
Posté par gouttegd . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 4.
Les auteurs de Meltdown ne savent pas très bien pourquoi leur attaque n’a pas réussi sur les processeurs AMD et ARM, mais les tests qu’ils ont réussi à faire montrent qu’avec ces processeurs aussi, les contrôles sont fait a posteriori :
Pour les auteurs, il semble établi que, sur le papier au moins, Meltdown devrait fonctionner aussi sur des processeurs non-Intel, il n’y a pas de différence conception suffisamment grande entre les fondeurs. Ce n’est peut-être qu’une question de temps avant de voir débarquer une version de Meltdown qui fonctionne sur d’autres processeurs.
Parce qu’on n’imaginait pas à l’époque le genre d’attaques par canaux cachés que l’on imagine à présent.
Peut-être que les ingénieurs de l’époque étaient nuls, peut-être qu’ils étaient tous achetés par la NSA. Ou peut-être qu’ils n’avaient pas le bénéfice des quinze dernières années de recherche.
[^] # Re: Bug (ou fonctionnalité ?)
Posté par gouttegd . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 6.
Oui. À ma connaissance, les premières attaques par canaux cachés visant les caches du processeur datent de cette décennie (p.ex. Gullasch et al. 2011, Hund et al. 2013, Irazoqui et al. 2015, etc.).
Si c’est réellement le cas (je ne prétends avoir fait le tour de la littérature sur la question, peut-être qu’il y a des travaux plus anciens), je pense qu’on peut difficilement reprocher aux fondeurs de n’avoir pas su empêcher, dans leurs designs datant pour certains du milieu des années 90, des attaques qui ne seront imaginées que dix ou quinze ans plus tard.
Intel est la risée d’Internet pour avoir dit ces derniers jours, en substance, « nous n’avons pas merdé, nos processeurs fonctionnent exactement comme prévu », mais ils n’ont pas forcément tort sur ce point.
[^] # Re: Et Linus ?
Posté par gouttegd . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 10.
D’après le dernier article d’Ars Technica, c’est un développeur AMD qui a mis la puce à l’oreille de tout le monde en postant le patch qui désactive la mitigation pour les processeurs AMD (et dont le commentaire était un peu trop bavard).
# Failles non-exploitées ?
Posté par gouttegd . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 10.
En même temps, si l’exploitation de la faille ne laisse pas de traces, même en faisant « de gros efforts » on ne voit pas ce qui est invisible, alors sans aucunement remettre en cause le crédit des « personnes au courant », le fait est qu’on ne sait pas si les failles ont été exploitées.
Point de vue pessimiste : les failles ont été découvertes par plusieurs personnes indépendamment (au moins trois équipes différentes si j’ai bien suivi), donc on peut raisonnablement supposer qu’elles aient aussi pu être découvertes par d’autres acteurs.
Point de vue optimiste : les failles ont été découvertes par plusieurs personnes à peu près au même moment. Comme il est peu probable que toutes ces personnes aient toutes eu le même coup de génie au même moment, ces découvertes sont probablement l’évolution logique de travaux antérieurs. On peut donc selon moi tout aussi raisonnablement penser que si des acteurs mal-intentionnés ont eux aussi découvert ces failles, ils l’ont fait eux aussi à peu près au même moment (mi-2017 en gros), et donc que si ces failles sont exploitées elles ne le sont pas depuis longtemps.
[^] # Re: Correct horse battery staple
Posté par gouttegd . En réponse au journal Scorepw, un évaluateur de mots de passe. Évalué à 5.
Si. En négligeant l’entropie structurelle ou de configuration (l’entropie provenant de la manière dont le mot de passe est construit : est-ce que c’est un mot choisi dans le dictionnaire ? Deux mots choisis dans le dictionnaire ? Un mot du dictionnaire suivi de deux chiffres ? Un mot du dictionnaire renversé suivi d’une date suivi d’un motif de six lettres sur un clavier QWERTY ? etc.), on sous-estime nécessairement l’entropie totale du mot de passe.
Je cite Daniel Wheeler (principal auteur de la Zxcvbn originelle) à ce sujet :
[^] # Re: Mais pourquoi scorepw ?
Posté par gouttegd . En réponse au journal Scorepw, un évaluateur de mots de passe. Évalué à 6.
Je ne prétends pas que le nom retenu soit le meilleur, mais il n’est pas possible de contenter tout le monde.
Par exemple, si j’avais choisi un des noms que tu proposes, on m’aurait peut-être fait la même remarque que la dernière fois que j’ai présenté un outil dont le nom comportait un tiret (à savoir, ce n’est pas pratique, c’est à éviter).
Du coup je ferais la même réponse que la dernière fois : si c’est vraiment important, change le nom du binaire pour ce que tu veux avec l’option
--program-transform-namelors de la configuration.Pour ce qui est du nom du projet lui-même (pas le binaire), j’ai pris scorepw pour la simple raison qu’une recherche Google ne rapportait aucun autre projet similairement nommé (contrairement à des alternatives comme « password checker » ou assimilés).
[^] # Re: Correct horse battery staple
Posté par gouttegd . En réponse au journal Scorepw, un évaluateur de mots de passe. Évalué à 2.
Embarquer un moteur JS dans scorepw pour pouvoir utiliser l’implémentation originale ?
Euh, on va dire que ce n’est pas au programme pour l’instant. Après si quelqu’un est motivé, j’accepte les patchs !
[^] # Re: Saisie
Posté par gouttegd . En réponse au journal Scorepw, un évaluateur de mots de passe. Évalué à 2.
C’est plutôt à Xinfe qu’il faut poser la question, mais pour ma part et en supposant que je suis sur ma machine :
Sur un téléphone, aucune idée.
[^] # Re: Correct horse battery staple
Posté par gouttegd . En réponse au journal Scorepw, un évaluateur de mots de passe. Évalué à 6.
Alors, je te déteste (cordialement, hein), parce que tu mets précisément le doigt sur une situation où scorepw ne va servir à rien…
Comme je le mentionne en fin de journal, scorepw (ou plus exactement, les bibliothèques dont il dépend, notamment Zxcvbn-C) fait plus ou moins n’importe quoi en présence de caractères non-ASCII. C’est valable pour les caractères accentués, c’est a fortiori valable pour des caractères de ce genre.
À mon avis, tous ces résultats surestiment largement le « mot » que tu donnes.
C’est particulièrement vrai pour Zxcvbn-C, qui ne connaissant pas UTF-8 traite en fait ✔️🐎🔋📌 comme un mot de 18 caractères dont les valeurs s’étalent sur toute la plage de 0 à 255 (d’où une estimation d’entropie qui crève le plafond mais à laquelle je ne me fierai pas).
Zxcvbn-CPP s’en sort mieux en considérant correctement 4 caractères Unicode au lieu de 18 octets, mais même comme ça l’entropie estimée me semble trop haute.
En général, quand on estime l’entropie d’un mot de passe, on part du principe que la « structure » du mot de passe (comment il est formé) est connue de l’attaquant. Par exemple, quand Randall estime que correcthorsebatterystaple a environ 44 bits d’entropie, c’est en supposant que l’attaquant sait que le mot de passe est formé de quatre mots courants choisis au hasard.
Une estimation correcte de ✔️🐎🔋📌 qui suit le même principe devrait à mon avis assumer que l’attaquant sait que le mot de passe est formé non pas de quatre caractères Unicode arbitraires (choisis dans la totalité d’Unicode), mais de quatre « symboles » provenant d’une plage restreinte d’Unicode (par exemple la plage des « Mscellaneous SYmbols », de U+1F300 à U+1F5FF).
C’est peut-être d’ailleurs ce que fait l’implémentation CoffeeScript de Zxcvbn, parce qu’elle considère ce mot de passe très moyen (à juste titre selon moi).
[^] # Re: Correct horse battery staple
Posté par gouttegd . En réponse au journal Scorepw, un évaluateur de mots de passe. Évalué à 4.
Il s’agit de 16 bits pour un mot (ici troubadour) choisi dans une liste comprenant entre autres des mots peu communs (« uncommon (non-gibberish) base word »), contrairement au cas du correcthorsebatterystaple qui ne comprend que des mots choisis dans une liste de mots plus courants (une liste forcément moins longue qu’une liste comprenant des mots courants et des mots moins courants).
Par exemple, le dictionnaire dont je parlais dans le journal constitué à partir des mots de la Wikipédia anglophone comprend exactement 100 000 mots, donc le choix d’un mot dans cette liste apporte ~16.6 bits d’entropie, soit à peu près ce qu’a retenu Randall.
[^] # Re: vocabulaire
Posté par gouttegd . En réponse au journal Retour d'expérience Nextcloud. Évalué à 4.
Une raison parmi d’autres : je viens de déménager et il m’a fallu pas moins de six semaines pour avoir une connexion Internet dans mon nouvel appartement.
J’étais bien content que mon serveur mail/contacts/agenda/etc. soit bien au chaud dans un datacenter bien connecté d’où je pouvais toujours le joindre avec le peu de connectivité que j’avais (depuis mon lieu de travail ou en passant par mon téléphone avec des cartes 4G pré-payées).
L’auto-hébergement, c’est peut-être bien pour quelqu’un qui a une situation raisonnablement stable. Mais quand on ne sait pas où on sera dans deux ans (dans quelle ville voire dans quel pays), quel service on pourra avoir (FTTH ? FTTC ? ADSL ? port 25 ouvert ? adresse IP fixe ? IPv6 ?) et à quel prix, ou combien de temps ça va prendre (deux jours, deux semaines ou deux mois ?)… non merci.
[^] # Re: Non, mais ce n’est pas Let’s Encrypt le problème
Posté par gouttegd . En réponse au message Let's Encrypt est-il adéquat?. Évalué à 2.
Pas du tout.
Je suis un utilisateur, je me connecte à un site qui me présente un certificat signé par une autorité reconnue et donc mon navigateur ne me dit rien du tout. Quelle certitude ai-je que je ne suis pas victime d’une attaque de type MITM ?
Aucune. Point.
Oh, certes, peut-être que la nécessité pour l’attaquant de devoir obtenir un certificat signé par une CA reconnue (ou par une sous-CA totalement inconnue) réduit quelque peu la probabilité de ce genre d’attaque, en la réduisant à ceux qui savent où et comment obtenir un certificat frauduleux.
Mais une mesure de « sécurité » qui ne fonctionne que dans l’hypothèse heureuse où l’attaquant n’a pas beaucoup de moyens, et ne me donne comme seule garantie que « vous n’êtes probablement pas attaqué, sauf si vous l’êtes »… je n’appelle pas ça un « gain net en sécurité ».
Contrairement à HPKP par exemple, qui après la première connexion alertera immanquablement l’utilisateur de toute tentative d’attaque. Ça c’est un vrai gain en sécurité. Seulement la vrai sécurité, c’est chiant, c’est difficile, alors on vire parce que dire qu’on se préoccupe de la sécurité est plus important que de prendre la peine de le faire effectivement. (La raison avancée par Google pour virer HPKP est que les administrateurs de serveurs ne savent pas gérer ça correctement — ben oui, c’est difficile, la sécurité.)
Je maintiens : utiliser un certificat signé par une CA reconnue est une mesure de confort pour les utilisateurs, en aucun cas une mesure de sécurité. Ça ne veut pas dire que c’est mal, mais il ne faut pas se bercer d’illusion sur ce que ça apporte.
Oui, je connais l’idée, merci. Et perso j’y crois autant qu’à la trickle-down economics …
Let’s Encrypt, peut-être pas. Mais CT, si, absolument, en donnant encore plus d’importance aux CA et en empêchant activement toute méthode d’authentification alternative qui ne passerait pas par les CA.
Les CA font partie du problème, pas de la solution.
[^] # Re: on pourrait en savoir plus ?
Posté par gouttegd . En réponse au journal [PGP] Des failles de sécurité sous le sapin pour Thunderbird et Enigmail !. Évalué à 6.
À ma connaissance les vulnérabilités découvertes dans Thunderbird n’ont pas été rendues publiques, contrairement à celles de Enigmail. La raison en est que si les vulnérabilités d’Enigmail ont déjà été corrigées (version 1.9.9 publiée le 19 décembre), ce n’est pas (encore) le cas pour Thunderbird, apparemment car les vulnérabilités découvertes ont une cause profonde, liée à l’architecture même du logiciel, et de fait ne se corrigent pas en quelques jours.
Je cite le blog de Posteo.de (l’emphase est de moi):
À première vue quelque chose ne colle pas ici : si on peut aisément concevoir qu’un défaut d’isolation des greffons permette à un greffon d’accéder à n’importe quelle donnée au sein de Thunderbird, cela ne suffit pas à mettre en danger les clefs OpenPGP privées qui ne sont jamais manipulées directement ni par Thunderbird ni par Enigmail. Il y a une double indirection entre Thunderbird/Enigmail et les clefs OpenPGP : Enigmail délègue le déchiffrement (ou la signature) d’un message au programme gpg qui lui-même délègue toute opération impliquant une clef privée à l’agent GnuPG, qui est le seul programme à manipuler les clefs privées directement.
Pour qu’un greffon Thunderbird permette à un attaquant d’accéder « même aux clefs OpenPGP privées », il faudrait que les vulnérabilités donnent un accès non seulement à Thunderbird lui-même, mais à travers lui à tout le système de fichiers (permettant d’exfiltrer un fichier arbitraire).
Malheureusement, la suite du message de Posteo.de sous-entend que c’est précisément le cas :
Je note que si c’est réellement le cas, vos clefs OpenPGP privées devraient être le dernier de vos soucis. D’une part, elles sont de toutes façons stockées sous forme chiffrée en permanence (l’agent GnuPG ne les déchiffre qu’en mémoire, juste avant de les utiliser quand il en a besoin, et les efface de sa mémoire aussitôt après) et donc pour peu que vous avec une phrase de passe décente, l’attaquant qui les exfiltrerait ne se retrouverait pas plus avancé.
D’autre part et surtout, si l’attaquant peut accéder à l’ensemble de votre système de fichiers, pourquoi chercherait-il vos clefs OpenPGP alors qu’il peut déjà récupérer tous les documents qu’il veut, à la source, en clair ?
[^] # Re: Montage webdav/davfs2
Posté par gouttegd . En réponse au journal Retour d'expérience Nextcloud. Évalué à 4.
Le client Owncloud (qui fonctionne tant avec Owncloud qu’avec Nextcloud) a un client en ligne de command
owncloudcmd. Il dépend toujours de Qt (Qt5Network, Qt5Core, etc.) mais fonctionne sans serveur graphique.Toutefois, contrairement à son homologue graphique,
owncloudcmdfait une synchro puis se termine — il ne reste pas à monitorer les fichiers et refaire une synchro en cas de changements.[^] # Re: Non, mais ce n’est pas Let’s Encrypt le problème
Posté par gouttegd . En réponse au message Let's Encrypt est-il adéquat?. Évalué à 5. Dernière modification le 29 décembre 2017 à 16:08.
Bof, il suffit de trouver une CA peu regardante. Avec certaines, on peut même obtenir (il suffit de demander) non pas un simple certificat frauduleux, mais un certificat intermédiaire permettant au titulaire d’émettre lui-même autant de certificats qu’il veut pour n’importe quel domaine.
Ça fera une belle jambe à ceux qui ont été victimes de l’attaque avant qu’elle ne soit détectée. Ou à celui qui a été victime, si on parle d’une attaque ciblée ne visant qu’une personne bien précise.
le HTTP Public Key Pinning, c’est mort, Google a dit qu’ils n’en voulaient plus. Et comme c’est Google, ben voilà quoi.
Ça par contre ce n’est pas mort puisque Google ne jure que par ça… et ça ne résoud absolument pas le problème. Oui, ça peut permettre une « détection a posteriori » d’une attaque. Ça ne change rien au fait qu’au moment où l’attaque se produit, mon navigateur acceptera sans broncher le certificat frauduleux présenté par l’attaque, Certificate Transparency ou pas.
Là-dessus je suis d’accord.
# Non, mais ce n’est pas Let’s Encrypt le problème
Posté par gouttegd . En réponse au message Let's Encrypt est-il adéquat?. Évalué à 10. Dernière modification le 27 décembre 2017 à 12:41.
Non. En l’état actual de PKIX, un certificat signé par une autorité de certification reconnue (qu’il s’agisse de Let’s Encrypt ou d’une autre) n’apporte aucune sécurité supplémentaire par rapport à un certificat signé par une autorité non-reconnue.
La seule chose qu’apporte la signature par une autorité reconnue est l’absence de message d’erreur côté client, sans que les clients aient quoi que ce soit à faire (comme installer le certificat racine d’une autorité privée). C’est une mesure de confort, pas de sécurité (ce qui n’est pas négligeable pour autant).
Avec un certificat auto-signé, tes clients sont protégés contre un attaquant passif mais vulnérables à une attaque active de type MITM. Avec un certificat signé par une autorité reconnue, ben… ils sont toujours vulnérables à une attaque active de type MITM, puisqu’il y a what mille autorités de certification là dehors qui peuvent délivrer un certificat frauduleux que les navigateurs des clients accepteront sans broncher (« bah quoi, il est signé par une autorité reconnue, alors c’est bon »).
[^] # Re: Autres retour d'expérience : 2 utilisateurs, synchro calendrier et contacts
Posté par gouttegd . En réponse au journal Retour d'expérience Nextcloud. Évalué à 4.
C’est le cas. Le chiffrement des fichiers de manière générale se fait côté serveur, mais Passman, le module de gestion de mots de passe, chiffre les mots de passe côté client. Le serveur ne voit jamais le mot de passe permettant d’ouvrir un coffre.
# Des détails
Posté par gouttegd . En réponse au journal [PGP] Des failles de sécurité sous le sapin pour Thunderbird et Enigmail !. Évalué à 10. Dernière modification le 26 décembre 2017 à 15:33.
Pour les curieux, l’extrait de l’audit concernant Enigmail est disponible.
Sur la vulnérabilité TBE-01-002, je n’ai aucun commentaire à faire si ce n’est un doh! doublé d’un facepalm … Encore une excellente illustration de la loi d’Adi Shamir : Cryptography is bypassed, not penetrated. Pourquoi attaquer de front un algorithme de chiffrement quand on peut s’en prendre à une banale expression rationnelle ?
En revanche la vulnérabilité TBE-01-005 me laisse dubitatif. L’audit semble dire qu’Enigmail déchiffre automatiquement et silencieusement un bloc chiffré caché au fin fond d’un e-mail, permettant à un attaquant d‘obtenir une copie déchiffré d’un message simplement en l’insérant subrepticement dans le fil d’une conversation.
Je ne sais pas dans quelles conditions (p.ex. quelles versions d’Enigmail et/ou de GnuPG) ils ont testé ça (ni même si ils ont réellement testé ce scénario ou s’il s’agit juste d’une vulnérabilité théorique), mais le déchiffrement d’un bloc chiffré, même caché au fin fond d’un email de plusieurs centaines de lignes, n’est la plupart du temps pas silencieux puisque GnuPG doit demander à l’utilisateur de saisir la phrase de passe de sa clef privée. Ce n’est que si la phrase de passe est déjà dans le cache de l’agent GnuPG (donc si l’utilisateur s’en est servi dans les dix minutes précédentes, dans la configuration par défaut) qu’on ne lui demande rien. Ce n’est pas insurmontable pour l’attaquant (qui pourrait s’arranger par exemple pour envoyer lui-même un mail chiffré à sa victime quelques minutes avant de lui envoyer le mail contenant le message dont il veut obtenir le texte clair), mais ce n’est ni très discret ni aussi facile que ne semble le suggérer l’audit.
Ah, et sinon :
Je vais (encore) chipoter, mais « OpenGPG », ça n’existe pas. Piqûre de rappel :
[^] # Re: LA scène de l'espace
Posté par gouttegd . En réponse au journal Parlons un peu de Star Wars VIII - Les derniers Jedi (Attention : SPOILERS). Évalué à 4.
Dans la trilogie originale, peut-être. Mais depuis, je suis sûr d’avoir vu des droïdes piloter des engins, y compris du côté de la République/de la Rébellion. Sans parler bien sûr de la flotte entièrement mécanisée de la Fédération du Commerce.
Et même si on s’en tenait uniquement à la trilogie originale : quand on a des droïdes médicaux capables de greffer une main artificielle, on peut facilement imaginer un droïde pilote.
Enfin bon, une incohérence de plus dans une série dont les trous scénaristiques sont tellement gros qu’on pourrait y faire passer un croiseur interstellaire de classe Executor, on n’est plus à ça près…
[^] # Re: Pourquoi avoir une base de donnée ?
Posté par gouttegd . En réponse au journal Coffre numérique.. Évalué à 2.
Oui, alors euh mon « expertise » est uniquement basée sur ce que les développeurs disent qu’ils font. Je ne suis pas allé regarder le code pour savoir s’il fait correctement ce qu’il est supposé faire — même si j’avais voulu le faire, je ne suis de toute façon pas compétent pour juger de la qualité d’une implémentation (le code pourrait bien être truffé de failles de sécurité, je n’en rendrais jamais compte). D’où ma réserve à la fin, « si l’implémentation est correcte ».
[^] # Re: Pourquoi avoir une base de donnée ?
Posté par gouttegd . En réponse au journal Coffre numérique.. Évalué à 3.
Indépendamment de ce logiciel, je ne suis pas fan de l’approche basée sur un master password dont les mots de passes finaux sont directement dérivés.
Le problème fondamental avec cette approche, c’est que si par malheur le mot de passe principal vient à être compromis, c’est jackpot pour l’attaquant, il peut dériver l’ensemble de tes mots de passe. Contrairement à un gestionnaire de mots de passe classique (qui stockerait les mots de passe dans une base chiffrée), il n’a même pas besoin d’exfiltrer la base de mots de passe, la simple connaissance du mot de passe maître est suffisante. Du coup, cette approche est potentiellement plus risquée qu’une approche « classique ».
Je note toutefois que contrairement à d’autres logiciels que j’ai pu voir basés sur la même approche, LessPass semble dériver les mots de passe finaux d’une manière cryptographiquement solide (PBKDF2 — encore que j’aurais préféré Argon2 qui est expressément conçu pour ce genre de choses, contrairement à PBKDF2 qui est plus un bidouillage), ce qui au moins devrait empêcher un attaquant de remonter au mot de passe maître juste en connaissant un mot de passe dérivé (sous réserve que l’implémentation est correcte).
[^] # Re: Tu m'as convaincu !
Posté par gouttegd . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 4.
Il faut appeler le script
/lib/opendkim/opendkim.service.generatepour que le contenu du fichier/etc/default/opendkimsoit pris en compte.Et je suis d’accord, c’est assez moche.
[^] # Re: tout a fait
Posté par gouttegd . En réponse au journal L’écriture neutre. Évalué à 4.
Moi si, jusqu’à ces dernières années.
Enfin, « un paradis », n’exagérons rien, mais la Turquie était probablement l’un des pays les plus progressistes de la région avant qu’Erdoğan ne lui fasse faire machine arrière toute vers le 19ème siècle.