pas un des centaines d'ingénieurs sécurité chez Microsoft, Mozilla, Google et autres n'y a pensé avant ?
Moi ce que je ne comprends pas, c’est comment dans une boîte avec des centaines d’ingénieurs sécurité, on peut laisser n’importe qui créer un compte hostmaster@live.fi en dépit du fait que hostmaster fait partie des noms de boîte aux lettres utilisés par les CA pour vérifier que le demandeur d’un certificat a bien le contrôle du nom de domaine (CA/Browser Forum Baseline Requirements, §3.2.2.4). Permettant ainsi au même n’importe qui d’obtenir un certificat parfaitement valide (signé par une CA reconnue, ce qui comme chacun sait est une véritable garantie, non mais oh c’est du sérieux tout ça) pour live.fi…
(Et n’allez pas croire que je tape seulement sur Microsoft, parce que c’est Microsoft. Ils ont eu la gentillesse de me fournir cet exemple, c’est tout, mais ce n’est qu’un exemple parmi d’autres de l’excellence du système PKIX.)
En fait, si j'ai bien compris comment Let's Encrypt fonctionne, c'est que leur autorité est approuvée par une autre
Pour l’instant, oui. Ils envisagent de faire intégrer leur propre racine auto-signée dans les magasins des navigateurs, mais ce n’est pas encore fait.
ce qui fait que si Let's Encrypt génère un certificat pour une personne malintentionnée, bah on l'a dans l'os parce que le certificat sera accepté d'office par le client.
Ça c’est totalement indépendant de la façon dont Let’s Encrypt fonctionne. Tu auras le même problème lorsque (si) Let’s Encrypt aura sa propre racine auto-signée, tout comme tu as déjà le même avec n’importe quelle autre autorité de certification.
Ce qu’on demande à une CA, c’est une preuve d’identité (est-ce que cette machine qui dit être www.amazon.com est réellementwww.amazon.com ?), en aucun cas une preuve de l’absence de mauvaises intentions.
D’ailleurs, Let’s Encrypt se fait taper sur les doigts à cause de ça par certains utilisateurs, qui aimeraient bien que Let’s Encrypt joue à la police et révoque tout certificat ayant été utilisé à de mauvaises fins — Let’s Encrypt refuse de faire ça et ça ne plaît pas à tout le monde, alors qu’aucune autre CA ne le fait sans que ça ne fasse broncher personne…
Le mien actuel est pas ridicule (strictement aucun rapport avec le dictionnaire, mais seulement 8 caractères).
Désolé, mais 8 caractères, aujourd’hui, c’est ridicule.
Dans le meilleur des cas (utilisation de lettres minuscules et majuscules, de chiffres, et plus généralement de toute la plage de caractères ASCII imprimables), il y 895 = 6 634 204 312 890 625 combinaisons à tester.
C’est certes hors de portée de ma machine (il me faudrait environ 21 ans), mais largement à la portée de beaucoup trop de monde (en gros, quiconque peut investir dans quelques cartes graphiques) pour que je sois à l’aise.
Je dirais que 12 caractères, c’est vraiment le strict minimum de nos jours. Et pour un « master password » dont dérivent tous les autres, je pense que je ne descendrai pas en-deçà de 18.
Mais pour aller sur un autre site, il va te falloir retrouver mon master password.
Oui, et le problème est que c’est possible, vu que ton mot de passe pour linuxfr.org est directement dérivé de ton master password.
Je ne dis pas que c’est facile (ça peut même être tellement difficile que ça cera, concrètement, infaisable si ton mot de passe maître est suffisamment complexe), mais c’est possible.
Et tu me dis qu'à coup de qques millions de tentatives par secondes tu vas arriver à retrouver mon master password "facilement" ?
S’il est trop simple ou s’il est dans un dictionnaire, oui, définitivement.
Il faut noter qu’un « dictionnaire », aujourd’hui, ce n’est plus une simple liste de mots sortis d’un « Robert » ou d’un « Larousse » (ou de /usr/share/dict). les craqueurs élaborent aujourd’hui des dictionnaires très riches, alimentés notamment par de vrais mots de passe issus des innombrables bases de données de sites piratés (par exemple, le dictionnaire utilisé pour craquer les mots de passe de LinkedIn comportait plus de 500 millions de mots et a permis de retrouver des mots de passe de plus de vingt caractères).
On peut calculer une espérance théorique ? Concrètement, ça prend 1h ou 1 million d'années à le trouver ?
Dis-moi quel est ton mot de passe, je te dirai s’il est suffisamment fort. :D
Plus sérieusement, c’est justement parce que je ne peux pas répondre à cette question que je préfère éviter d’utiliser une méthode où la sécurité de tous mes mots de passe dépend de la réponse à cette question…
Il suffit de brute forcer : merci, mais pour n'importe quel site il "suffit" de brute forcer. Je ne vois pas en quoi ça change ce paramètre.
Si l’attaquant sait que tu utilises SGP, il lui suffit de craquer un seul des mots de passe générés pour retrouver ton mot de passe maître, et à partir de là obtenir les mots de passe pour tous les sites.
MD5 est trop faible. Trop faible pour quoi ? Je te donne un hash MD5, on n'est toujours pas capable de créer le contenu correspondant sur commande
Nul besoin d’inverser la fonction de condensation si
le mot de passe est trop faible, et
l’attaquant peut tester rapidement toutes les combinaisons.
Ma pauvre machine de bureau est capable, sans forcer (pas d’utilisation de plusieurs cœurs, du GPU, ou d’autres optimisations de ce genre) de calculer environ dix millions de MD5 par seconde.
Note que même un mot de passe d’apparence complexe peut être « faible » s’il est dans un dictionnaire, ou s’il peut être construit à partir d’un dictionnaire.
Ce n’est pas une faiblesse propre à MD5. Comme je le disais plus haut, toutes les fonctions de condensation conçues pour être rapide ont le même problème (SHA-512 ? Je peux en calculer environ six millions par seconde, les doigts dans le nez). C’est pour ça qu’elles ne sont pas adaptées à la condensation de mots de passe.
Si on craque le mot de passe, on a accès à tout : de ce que je vois, vous stockez vos mots de passe qque part. Si je craque cet accès j'ai donc également accès à tous les mots de passe.
Pas comparable.
Dans ton cas, il suffit à l’attaquant d’obtenir un seul de tes mots de passe (de quelque façon que ce soit : via un keylogger sur ta machine, en sniffant le réseau — il y a encore des sites dont les formulaires de login ne sont pas protégés par TLS… —, en obtenant un dump de la base de données d’un site — non, je ne suis pas parano, renseignez-vous, il ne se passe pas une semaine sans qu’un site ne se fasse pas pirater sa BD —, etc.) pour pouvoir ensuite tenter de le craquer à loisir, totalement « offline », en y mettant autant de ressources que possible et sans que tu ne te doutes rien.
De mon côté (avec un fichier de mots de passe chiffré par GnuPG, mais ce serait à peu près pareil avec un gestionnaire de mots de passe comme KeePassX ou assimilé), si l’attaquant obtient un de mes mots de passe, ben… il a un de mes mots de passe. Chouette pour lui mais ça ne lui permettra jamais d’obtenir les autres.
S’il veut tous mes mots de passe, il lui faut impérativement mettre la main sur mon fichier de mots de passe, et casser la protection dudit fichier¹. Pas impossible certes, mais la grosse différence par rapport à ton schéma est que l’attaquant n’a plus le choix du point d’attaque. Il doit s’en prendre à ma machine, il ne peut pas choisir de sniffer un point quelconque du réseau ou s’en prendre à un site mal protégé.
¹ Ce qui chez moi implique de devoir
casser la clef AES protégeant le fichier lui-même, ou
factoriser ma clef OpenPGP publique (la voilà, si tu veux essayer), ou
obtenir ma clef OpenPGP privée et casser la phrase de passe qui la protège.
Or il se trouve que Brown ne s'est pas occupé de l'entretient de sa caisse
Faut dire qu’il a sans doute eu du mal à se procurer du plutonium aussi, on ne peut plus compter sur les terroristes libyens depuis la chute de Kadhafi.
le tout itéré avec une bonne fonction de hachage (Keccak?)
Le problème avec les fonctions de hachage, même les bonnes comme Keccak, est qu’elles sont conçues (entre autres) pour être rapides, ce qui n’est pas idéal pour ce genre d’utilisation.
Ici, on a besoin au contraire d’une fonction « lente ». S’il fallait, par exemple, 100 ms pour hacher le mot de passe maître, ça n’aurait pas beaucoup d’impact pour l’utilisateur en conditions normales (100 ms, c’est suffisamment rapide pour que l’utilisateur perçoive à peine le délai), mais ça rendrait la recherche exhaustive beaucoup plus coûteuse pour l’attaquant.
Et mieux encore, il faudrait une fonction coûteuse en temps et en mémoire. Des fonctions comme scrypt ou Argon2, spécialement conçues pour le « hachage » de mot de passe.
Exécuter n fois une fonction de condensation sur un mot de passe est un « hack », qu’on devrait laisser de côté maintenant qu’on a des fonctions étudiées pour.
Non, c'est pas juste un hachage du nom du site : c'est un chiffrement du nom du site avec une clé (commune à tous les sites)
C’est une condensation ré-itérée x fois (avec x = 10 par défaut) d’un mot de passe principal suivi du nom du site. Rien à voir avec un chiffrement.
C’est plus ou moins analogue à un HMAC, à ceci près que la clé est ici le mot de passe principal de l’utilisateur, qui à presque tous les coups ne fournit pas une sécurité suffisante (comparé par exemple à une clef aléatoire de 128 bits).
Tant qu'ils n'ont pas la clé, l'algo ne suffit pas.
Le problème est que la « clé » n’est pas si difficile que ça à retrouver (sauf si le mot de passe est très complexe). Pas forcément à la portée du premier venu, mais rien de comparable avec la difficulté de craquer un chiffrement digne de ce nom.
« Attention, paranoïaque en approche à 11 heures ! Feu à volonté ! »
Ahem.
Un (rapide, certes) coup d’œil au code ne m’inspire pas beaucoup confiance. Deux petites choses me gènent particulièrement.
D’abord, même si l’auteur met en avant le fait qu’il s’agisse d’un bookmarklet qui s’exécute localement, je vois que le code télécharge une version de jQuery depuis les serveurs de Google. Donc, même si j’installe le bookmarklet une fois pour toute (après avoir vérifié qu’il fait bien ce qu’il est censé faire), a priori chaque fois que je l’exécute je récupère un bout de code arbitraire depuis l’Internet. Merci, sans façon.
Ensuite, j’ai de grosses réserves sur l’algorithme de génération de mots de passe. Par défaut, c’est simplement une concaténation du mot de passe « maître » et de l’URL du site cible, passé dix fois de suite à la moulinette de MD5.
La fonction MD5 est à mon avis beaucoup trop faible pour être encore utilisée de cette façon. Faire dix passages au lieu d’un seul n’y change pas grand’chose. Pour peu que le mot de passe maître ne soit pas suffisamment complexe, quelqu’un qui sait que tu génères tes mots de passe de cette façon pourrait probablement remonter jusqu’au mot de passe maître (et là, c’est jackpot, il connaît tous tes mots de passes pour tous les sites que tu visites).
Il est possible d’utiliser SHA512 au lieu de MD5, ce qui est certes nettement mieux mais ce n’est toujours pas une fonction appropriée pour ce genre de tâche.
L'histoire de la seconde trilogie est intéressante, surtout quand on la calque avec l'histoire française moderne
Pour ma part, j’y voyais un parallèle avec, d’une part, la République romaine qui en temps de crise nommait un dictator avec les pleins pouvoirs ou presque, et d’autre part, la IIIe République française qui s’est volontairement sabordée lorsque l’Assemblée nationale a donné tout pouvoir à Philippe Pétain le 10 juillet 1940 (non, je ne suis pas assez vieux pour avoir vu ça, mais c’est à ça que m’a fait penser la scène de l’épisode III où Palpatine proclame la naissance de l’Empire galactique sous les acclamations de la grande majorité des sénateurs et à la consternation de seulement quelques-uns — So that’s how liberty dies: with thunderous applause).
Heureusement que le gouvernement américain est plus raisonnable que l’Empire galactique, lui a refusé de construire une Étoile de la Mort quand on le lui a demandé. Trop cher et trop vulnérable pour ce prix.
quand je dis standard c'est plutôt standard d'utilisation (cad utilisé majoritairement). Ce n'est pas (encore) le cas des algos basés sur les courbes
Oui et non.
Dans TLS par exemple, si la cryptographie ECC est encore rarement utilisé pour l’étape d’authentification (seuls 4% des certificats des serveurs web utilisent une clef ECDSA d’après l’université de Berkeley, contre 96% qui ont une clef RSA), elle est beaucoup plus fréquente lors de l’étape d’échange de clef (environ 75% des connexions utilisent un échange Diffie-Hellman sur courbe elliptique, d’après la même étude).
Et puisqu’on parlait de consoles, ECDSA a aussi notoirement été utilisé par dans la PlayStation 3 — un fait « notoire » principalement parce que Sony a magistralement foiré l’implémentation de l’algorithme… illustrant au passage deux points :
il est toujours plus facile de trouver une faille dans l’implémentation d’une primitive cryptographique, ou dans tout le code qui gravite autour, que d’attaquer la primitive proprement dite (Cryptography is bypassed, not penetrated — Adi Shamir) ;
corollairement, la rigueur accordée à l’implémentation compte beaucoup plus que le choix de l’algorithme (entre AES ou Twofish, c’est kif-kif bourricot, mais mieux vaut encore un 3DES codé avec soin qu’un AES codé avec les pieds).
C’est une protection suffisante, seulement si la version de tar utilisée prend soin de ne jamais rien écrire ailleurs que dans le répertoire courant (en supprimant le '/' initial des noms de fichiers dans l’archive et en refusant d’extraire les fichiers dont le nom comprend des '..'). C’est ce que fait GNU tar par défaut (sauf si l’option --absolute-paths est utilisée), mais ce n’est pas forcément le comportement des autres versions.
Avec ta méthode, tu es informé du problème rencontré par gpg, mais ça ne change rien au fait que tu as déjà envoyé à tar une archive non-vérifiée, tu n’es informé de l’erreur qu’a posteriori. Charge ensuite à toi, en cas d’erreur, d’aller défaire tout ce que tar a fait (en espérant qu’il n’ait pas déjà écrasé des fichiers pré-existants).
Il est plus sûr d’attendre que GnuPG ait fini son travail (y compris la vérification d’intégrité) avant de faire quoi que ce soit avec le texte déchiffré.
Pourquoi ne pas utiliser des pipes? c'est tout l’intérêt.
Pour le chiffrement, OK, mais pour le déchiffrement, c’est à éviter.
Pour des raisons historiques, OpenPGP (et donc GnuPG) fonctionne en mode MAC-then-Encrypt. Un MAC est calculé sur le texte clair, ajouté à la fin du texte (RFC 4880, §5.13), et l’ensemble est ensuite chiffré. (C’est une mauvaise stratégie et ça fait partie des choses que le prochain RFC sur OpenPGP devrait corriger.) Ce n’est donc qu’après avoir déchiffré tout le texte chiffré que GnuPG peut enfin prendre connaissance du MAC et ainsi vérifier l’intégrité du texte clair.
Si tu fais quelque chose comme ça :
gpg -d archive.tar.gpg | tar xf -
tu envoies à tar un texte clair dont l’intégrité n’a pas (encore) été vérifié. Si l’archive chiffrée a été modifiée par un attaquant, GnuPG affichera un message d’erreur en fin d’opération, mais dans le contexte d’un script appelé depuis une interface graphique (sans console pour afficher la sortie d’erreur standard), celui-ci passera inaperçu.
Il faut laisser GnuPG déchiffrer intégralement le fichier, vérifier le code de retour, et ensuite seulement détarrer l’archive :
if gpg -o archive.tar -d archive.tar.gpg ; then
# OK, on peut continuer
tar xf archive.tar
else
# Il y a quelque chose qui ne va pas
# Même si GnuPG a commencé à écrire le
# fichier archive.tar, on ne peut pas s’y fier!
# Prévenir l'utilisateur ou faire autre chose
:
fi
Tout d'abord, j'aimerais comprendre ce que c'est une attaque théorique ?
Une attaque qui n’est pas réalisable en pratique, pour plusieurs raisons possibles :
parce qu’elle ne concerne qu’une version « castrée » de l’algorithme et n’est pas transposable à la version complète (par exemple, une attaque contre une version d’AES128 réduite à 6 tours, alors que la version complète comprend 10 tours) ;
parce qu’elle ne réduit la complexité que très marginalement par rapport à une attaque par recherche exhaustive de la clef, restant ainsi complètement hors de portée d’une application pratique ;
parce qu’elle nécessite d’énormes quantités de textes chiffrés avec la même clef que celle que l’on cherche à casser ;
etc.
Mais pour les cryptologues, toute attaque qui est moins complexe que la recherche exhaustive (aka brute-force) est formellement une attaque réussie, même si elle est complètement irréalisable.
Par exemple, l’attaque de Bogdanov et al. (2011) contre AES128 nécessite 288 paires de textes chiffrés/textes clairs et environ 2126 opérations pour retrouver une clef. Irréalisable, mais il n’empêche : elle est moins complexe qu’une recherche exhaustive de la clef (qui demanderait en moyenne 2127 opérations), donc c’est une bonne attaque.
Apparemment ça ne suffit pas à remettre en cause un algo ?
Non.
2008 j'achète une WII, je sniffe un peu et ohhhh… l'échange des certificat ne se fait pas selon un standard mais sur un algo asymétrique basé sur les courbes elliptiques […] les industriels passent sur des algos autres
Je ne sais pas ce qu’utilise la Wii, mais es-tu bien sûr que son algo asymétrique n’est pas standard ? Les industriels n’ont pas sorti les algorithmes à bases de courbes elliptiques d’un chapeau, hein. La plupart des implémentations utilisent les courbes standardisées par le NIST (NIST P256, P384, P521).
(Et juste pour le fun, la prétendue « attaque » de Filiol (2003), qui affirmait pouvoir casser non seulement AES mais n’importe quel algorithme de chiffrement par blocs — étonnamment (ou pas), personne n’a pu reproduire ses résultats.)
En fait, il y a probablement plus d’attaques (encore une fois, théoriques) sur Rijndael que sur n’importe quel autre finaliste de la compétition AES. L’intérêt des cryptologues pour les autres algorithmes s’est éteint lorsque Rijndael a été sélectionné (pourquoi s’attaquer à des algorithmes que personne ne va utiliser puisque tout le monde choisit l’algorithme standard ?).
Et ce sont justement toutes les attaques sur Rijndael qui renforcent la confiance dans cet algorithme : il est attaqué de toute part depuis quinze ans, et personne ne réussit à faire mieux que des attaques purement théoriques.
Ajoute à ça le fait fait que Rijndael est recommandé
Évidemment qu’il est recommandé, c’est devenu LE standard du chiffrement symétrique.
En fait, AES est devenu l’algorithme que personne ne te reprochera de choisir, parce que tout le monde fait pareil. Si un jour il est cassé, le blâme ira à ses concepteurs. Alors que si tu utilises (au hasard) Twofish, et qu’il est un jour cassé, c’est toi qu’on blâmera pour avoir choisi autre chose que le standard.
Je soupçonne qu'un acteur pas très incontournable soit un peu dans ce genre de position de faiblesse dans une négotiation avec le réalisateur d'un blockbuster. Il peut accepter des choses même si c'est dangereux, qu'on le trompe et que l'intérêt artistique est douteux.
Pas la peine de soupçonner, il y a des cas avérés. Comme lorsque Tippi Hedren a failli se faire crever un œil sur le tournage de Birds (par de vrais corbeaux alors que Hitchcock lui avait assuré que la scène serait tournée avec des oiseaux mécaniques). Mais c’est de l’ART, Hitchcock est un GÉNIE (et Hedren une jeune actrice sans expérience), alors ça passe.
Posté par gouttegd .
En réponse au journal yippee ki-yay.
Évalué à 9.
Dernière modification le 15 janvier 2016 à 18:48.
aucun cascadeur n'a accepté de remplacer Alan Rickman […] le réalisateur a demandé au cascadeur en chef de lâcher le filin à "deux" et non à "trois" pour créer un effet de surprise
Donc, le cascadeur en chef voit ses collègues cascadeurs refuser de faire la cascade même sans l’effet de surprise parce que même comme ça c’est déjà dangereux, mais ça ne lui pose aucun problème de laisser un non-cascadeur faire la cascade en lui rajoutant un effet de surprise qui augmente probablement la dangerosité de la chose ?
C’est moi ou le réalisateur et le cascadeur « en chef » sont des irresponsables ?
Je ne suis pas sûr de comprendre pourquoi tu unsetGPG_AGENT_INFO, mais quelle qu’en soit la raison, attention : cette variable n’a plus aucun effet à partir de GnuPG ≥ 2.1. À partir de cette version, la socket de l’agent GPG n’est plus variable, mais toujours située à l’emplacement $GNUPG_HOME/S.gpg-agent.
Si le but était de forcer GnuPG à démarrer un nouvel agent sans utiliser celui déjà lancé (pourquoi ?)… ça ne marchera pas avec GnuPG ≥ 2.1.
Dropbear est une implémentation de SSH (le protocole) qui est totalement indépendante de OpenSSH (l’implémentation dont il est question ici), donc même s’il implémentait la même option de roaming (ce qui n’est sans doute pas le cas, ça a l’air d’être une spécificité d’OpenSSH et non une fonctionnalité standardisée), il ne serait pas impacté.
[^] # Re: What's the point ?
Posté par gouttegd . En réponse au journal À propos des certificats. Évalué à 6.
Moi ce que je ne comprends pas, c’est comment dans une boîte avec des centaines d’ingénieurs sécurité, on peut laisser n’importe qui créer un compte
hostmaster@live.fien dépit du fait quehostmasterfait partie des noms de boîte aux lettres utilisés par les CA pour vérifier que le demandeur d’un certificat a bien le contrôle du nom de domaine (CA/Browser Forum Baseline Requirements, §3.2.2.4). Permettant ainsi au même n’importe qui d’obtenir un certificat parfaitement valide (signé par une CA reconnue, ce qui comme chacun sait est une véritable garantie, non mais oh c’est du sérieux tout ça) pourlive.fi…(Et n’allez pas croire que je tape seulement sur Microsoft, parce que c’est Microsoft. Ils ont eu la gentillesse de me fournir cet exemple, c’est tout, mais ce n’est qu’un exemple parmi d’autres de l’excellence du système PKIX.)
[^] # Re: Quel le problème en fait ?
Posté par gouttegd . En réponse au journal À propos des certificats. Évalué à 5.
Pour l’instant, oui. Ils envisagent de faire intégrer leur propre racine auto-signée dans les magasins des navigateurs, mais ce n’est pas encore fait.
Ça c’est totalement indépendant de la façon dont Let’s Encrypt fonctionne. Tu auras le même problème lorsque (si) Let’s Encrypt aura sa propre racine auto-signée, tout comme tu as déjà le même avec n’importe quelle autre autorité de certification.
Ce qu’on demande à une CA, c’est une preuve d’identité (est-ce que cette machine qui dit être
www.amazon.comest réellementwww.amazon.com?), en aucun cas une preuve de l’absence de mauvaises intentions.D’ailleurs, Let’s Encrypt se fait taper sur les doigts à cause de ça par certains utilisateurs, qui aimeraient bien que Let’s Encrypt joue à la police et révoque tout certificat ayant été utilisé à de mauvaises fins — Let’s Encrypt refuse de faire ça et ça ne plaît pas à tout le monde, alors qu’aucune autre CA ne le fait sans que ça ne fasse broncher personne…
[^] # Re: SuperGenPass
Posté par gouttegd . En réponse au journal Où mettre son archive de mots de passe ?. Évalué à 2.
J’ai écrit ça trop vite, grossière erreur, c’est 958 combinaisons, pas 895…
[^] # Re: SuperGenPass
Posté par gouttegd . En réponse au journal Où mettre son archive de mots de passe ?. Évalué à 2. Dernière modification le 31 janvier 2016 à 21:02.
Désolé, mais 8 caractères, aujourd’hui, c’est ridicule.
Dans le meilleur des cas (utilisation de lettres minuscules et majuscules, de chiffres, et plus généralement de toute la plage de caractères ASCII imprimables), il y 895 = 6 634 204 312 890 625 combinaisons à tester.
C’est certes hors de portée de ma machine (il me faudrait environ 21 ans), mais largement à la portée de beaucoup trop de monde (en gros, quiconque peut investir dans quelques cartes graphiques) pour que je sois à l’aise.
Je dirais que 12 caractères, c’est vraiment le strict minimum de nos jours. Et pour un « master password » dont dérivent tous les autres, je pense que je ne descendrai pas en-deçà de 18.
[^] # Re: SuperGenPass
Posté par gouttegd . En réponse au journal Où mettre son archive de mots de passe ?. Évalué à 2.
Oui, et le problème est que c’est possible, vu que ton mot de passe pour linuxfr.org est directement dérivé de ton master password.
Je ne dis pas que c’est facile (ça peut même être tellement difficile que ça cera, concrètement, infaisable si ton mot de passe maître est suffisamment complexe), mais c’est possible.
S’il est trop simple ou s’il est dans un dictionnaire, oui, définitivement.
Il faut noter qu’un « dictionnaire », aujourd’hui, ce n’est plus une simple liste de mots sortis d’un « Robert » ou d’un « Larousse » (ou de
/usr/share/dict). les craqueurs élaborent aujourd’hui des dictionnaires très riches, alimentés notamment par de vrais mots de passe issus des innombrables bases de données de sites piratés (par exemple, le dictionnaire utilisé pour craquer les mots de passe de LinkedIn comportait plus de 500 millions de mots et a permis de retrouver des mots de passe de plus de vingt caractères).Dis-moi quel est ton mot de passe, je te dirai s’il est suffisamment fort. :D
Plus sérieusement, c’est justement parce que je ne peux pas répondre à cette question que je préfère éviter d’utiliser une méthode où la sécurité de tous mes mots de passe dépend de la réponse à cette question…
[^] # Re: SuperGenPass
Posté par gouttegd . En réponse au journal Où mettre son archive de mots de passe ?. Évalué à 3. Dernière modification le 28 janvier 2016 à 19:09.
Pour enfoncer le clou (et peut-être être plus clair), les deux gros points faibles du principe de SGP sont :
[^] # Re: SuperGenPass
Posté par gouttegd . En réponse au journal Où mettre son archive de mots de passe ?. Évalué à 2.
Si l’attaquant sait que tu utilises SGP, il lui suffit de craquer un seul des mots de passe générés pour retrouver ton mot de passe maître, et à partir de là obtenir les mots de passe pour tous les sites.
Nul besoin d’inverser la fonction de condensation si
Ma pauvre machine de bureau est capable, sans forcer (pas d’utilisation de plusieurs cœurs, du GPU, ou d’autres optimisations de ce genre) de calculer environ dix millions de MD5 par seconde.
Note que même un mot de passe d’apparence complexe peut être « faible » s’il est dans un dictionnaire, ou s’il peut être construit à partir d’un dictionnaire.
Ce n’est pas une faiblesse propre à MD5. Comme je le disais plus haut, toutes les fonctions de condensation conçues pour être rapide ont le même problème (SHA-512 ? Je peux en calculer environ six millions par seconde, les doigts dans le nez). C’est pour ça qu’elles ne sont pas adaptées à la condensation de mots de passe.
Pas comparable.
Dans ton cas, il suffit à l’attaquant d’obtenir un seul de tes mots de passe (de quelque façon que ce soit : via un keylogger sur ta machine, en sniffant le réseau — il y a encore des sites dont les formulaires de login ne sont pas protégés par TLS… —, en obtenant un dump de la base de données d’un site — non, je ne suis pas parano, renseignez-vous, il ne se passe pas une semaine sans qu’un site ne se fasse pas pirater sa BD —, etc.) pour pouvoir ensuite tenter de le craquer à loisir, totalement « offline », en y mettant autant de ressources que possible et sans que tu ne te doutes rien.
De mon côté (avec un fichier de mots de passe chiffré par GnuPG, mais ce serait à peu près pareil avec un gestionnaire de mots de passe comme KeePassX ou assimilé), si l’attaquant obtient un de mes mots de passe, ben… il a un de mes mots de passe. Chouette pour lui mais ça ne lui permettra jamais d’obtenir les autres.
S’il veut tous mes mots de passe, il lui faut impérativement mettre la main sur mon fichier de mots de passe, et casser la protection dudit fichier¹. Pas impossible certes, mais la grosse différence par rapport à ton schéma est que l’attaquant n’a plus le choix du point d’attaque. Il doit s’en prendre à ma machine, il ne peut pas choisir de sniffer un point quelconque du réseau ou s’en prendre à un site mal protégé.
¹ Ce qui chez moi implique de devoir
[^] # Re: non pas pour manquer de respect
Posté par gouttegd . En réponse au journal Décidément, Marvin Minsky bronsonisé. Évalué à 5.
Faut dire qu’il a sans doute eu du mal à se procurer du plutonium aussi, on ne peut plus compter sur les terroristes libyens depuis la chute de Kadhafi.
-> []
[^] # Re: SuperGenPass
Posté par gouttegd . En réponse au journal Où mettre son archive de mots de passe ?. Évalué à 5.
Le problème avec les fonctions de hachage, même les bonnes comme Keccak, est qu’elles sont conçues (entre autres) pour être rapides, ce qui n’est pas idéal pour ce genre d’utilisation.
Ici, on a besoin au contraire d’une fonction « lente ». S’il fallait, par exemple, 100 ms pour hacher le mot de passe maître, ça n’aurait pas beaucoup d’impact pour l’utilisateur en conditions normales (100 ms, c’est suffisamment rapide pour que l’utilisateur perçoive à peine le délai), mais ça rendrait la recherche exhaustive beaucoup plus coûteuse pour l’attaquant.
Et mieux encore, il faudrait une fonction coûteuse en temps et en mémoire. Des fonctions comme scrypt ou Argon2, spécialement conçues pour le « hachage » de mot de passe.
Exécuter n fois une fonction de condensation sur un mot de passe est un « hack », qu’on devrait laisser de côté maintenant qu’on a des fonctions étudiées pour.
[^] # Re: SuperGenPass
Posté par gouttegd . En réponse au journal Où mettre son archive de mots de passe ?. Évalué à 3.
C’est une condensation ré-itérée x fois (avec x = 10 par défaut) d’un mot de passe principal suivi du nom du site. Rien à voir avec un chiffrement.
C’est plus ou moins analogue à un HMAC, à ceci près que la clé est ici le mot de passe principal de l’utilisateur, qui à presque tous les coups ne fournit pas une sécurité suffisante (comparé par exemple à une clef aléatoire de 128 bits).
Le problème est que la « clé » n’est pas si difficile que ça à retrouver (sauf si le mot de passe est très complexe). Pas forcément à la portée du premier venu, mais rien de comparable avec la difficulté de craquer un chiffrement digne de ce nom.
[^] # Re: SuperGenPass
Posté par gouttegd . En réponse au journal Où mettre son archive de mots de passe ?. Évalué à 6.
« Attention, paranoïaque en approche à 11 heures ! Feu à volonté ! »
Ahem.
Un (rapide, certes) coup d’œil au code ne m’inspire pas beaucoup confiance. Deux petites choses me gènent particulièrement.
D’abord, même si l’auteur met en avant le fait qu’il s’agisse d’un bookmarklet qui s’exécute localement, je vois que le code télécharge une version de jQuery depuis les serveurs de Google. Donc, même si j’installe le bookmarklet une fois pour toute (après avoir vérifié qu’il fait bien ce qu’il est censé faire), a priori chaque fois que je l’exécute je récupère un bout de code arbitraire depuis l’Internet. Merci, sans façon.
Ensuite, j’ai de grosses réserves sur l’algorithme de génération de mots de passe. Par défaut, c’est simplement une concaténation du mot de passe « maître » et de l’URL du site cible, passé dix fois de suite à la moulinette de MD5.
La fonction MD5 est à mon avis beaucoup trop faible pour être encore utilisée de cette façon. Faire dix passages au lieu d’un seul n’y change pas grand’chose. Pour peu que le mot de passe maître ne soit pas suffisamment complexe, quelqu’un qui sait que tu génères tes mots de passe de cette façon pourrait probablement remonter jusqu’au mot de passe maître (et là, c’est jackpot, il connaît tous tes mots de passes pour tous les sites que tu visites).
Il est possible d’utiliser SHA512 au lieu de MD5, ce qui est certes nettement mieux mais ce n’est toujours pas une fonction appropriée pour ce genre de tâche.
[^] # Re: Ardour
Posté par gouttegd . En réponse à la dépêche Sortie de LibraZiK 1.0 : Premier pas (20160107). Évalué à 3.
Seules les versions compilées sont payantes. L’accès au code source est gratuit (tu es invité à faire une donation mais ce n’est pas obligatoire).
[^] # Re: Déification des vieux Starwars
Posté par gouttegd . En réponse au journal Qui nous sauvera de J. J. Abrams ?. Évalué à 5.
Pour ma part, j’y voyais un parallèle avec, d’une part, la République romaine qui en temps de crise nommait un dictator avec les pleins pouvoirs ou presque, et d’autre part, la IIIe République française qui s’est volontairement sabordée lorsque l’Assemblée nationale a donné tout pouvoir à Philippe Pétain le 10 juillet 1940 (non, je ne suis pas assez vieux pour avoir vu ça, mais c’est à ça que m’a fait penser la scène de l’épisode III où Palpatine proclame la naissance de l’Empire galactique sous les acclamations de la grande majorité des sénateurs et à la consternation de seulement quelques-uns — So that’s how liberty dies: with thunderous applause).
[^] # Re: Merci ça soulage ...
Posté par gouttegd . En réponse au journal Qui nous sauvera de J. J. Abrams ?. Évalué à 5.
Heureusement que le gouvernement américain est plus raisonnable que l’Empire galactique, lui a refusé de construire une Étoile de la Mort quand on le lui a demandé. Trop cher et trop vulnérable pour ce prix.
[^] # Re: script pour chiffrer des fichiers et dossiers
Posté par gouttegd . En réponse au journal GnuPT a disparu. Évalué à 4.
Oui et non.
Dans TLS par exemple, si la cryptographie ECC est encore rarement utilisé pour l’étape d’authentification (seuls 4% des certificats des serveurs web utilisent une clef ECDSA d’après l’université de Berkeley, contre 96% qui ont une clef RSA), elle est beaucoup plus fréquente lors de l’étape d’échange de clef (environ 75% des connexions utilisent un échange Diffie-Hellman sur courbe elliptique, d’après la même étude).
Et puisqu’on parlait de consoles, ECDSA a aussi notoirement été utilisé par dans la PlayStation 3 — un fait « notoire » principalement parce que Sony a magistralement foiré l’implémentation de l’algorithme… illustrant au passage deux points :
il est toujours plus facile de trouver une faille dans l’implémentation d’une primitive cryptographique, ou dans tout le code qui gravite autour, que d’attaquer la primitive proprement dite (Cryptography is bypassed, not penetrated — Adi Shamir) ;
corollairement, la rigueur accordée à l’implémentation compte beaucoup plus que le choix de l’algorithme (entre AES ou Twofish, c’est kif-kif bourricot, mais mieux vaut encore un 3DES codé avec soin qu’un AES codé avec les pieds).
[^] # Re: script pour chiffrer des fichiers et dossiers
Posté par gouttegd . En réponse au journal GnuPT a disparu. Évalué à 5.
C’est une protection suffisante, seulement si la version de tar utilisée prend soin de ne jamais rien écrire ailleurs que dans le répertoire courant (en supprimant le '/' initial des noms de fichiers dans l’archive et en refusant d’extraire les fichiers dont le nom comprend des '..'). C’est ce que fait GNU tar par défaut (sauf si l’option
--absolute-pathsest utilisée), mais ce n’est pas forcément le comportement des autres versions.[^] # Re: script pour chiffrer des fichiers et dossiers
Posté par gouttegd . En réponse au journal GnuPT a disparu. Évalué à 5.
Avec ta méthode, tu es informé du problème rencontré par gpg, mais ça ne change rien au fait que tu as déjà envoyé à tar une archive non-vérifiée, tu n’es informé de l’erreur qu’a posteriori. Charge ensuite à toi, en cas d’erreur, d’aller défaire tout ce que tar a fait (en espérant qu’il n’ait pas déjà écrasé des fichiers pré-existants).
Il est plus sûr d’attendre que GnuPG ait fini son travail (y compris la vérification d’intégrité) avant de faire quoi que ce soit avec le texte déchiffré.
[^] # Re: script pour chiffrer des fichiers et dossiers
Posté par gouttegd . En réponse au journal GnuPT a disparu. Évalué à 5.
Pour le chiffrement, OK, mais pour le déchiffrement, c’est à éviter.
Pour des raisons historiques, OpenPGP (et donc GnuPG) fonctionne en mode MAC-then-Encrypt. Un MAC est calculé sur le texte clair, ajouté à la fin du texte (RFC 4880, §5.13), et l’ensemble est ensuite chiffré. (C’est une mauvaise stratégie et ça fait partie des choses que le prochain RFC sur OpenPGP devrait corriger.) Ce n’est donc qu’après avoir déchiffré tout le texte chiffré que GnuPG peut enfin prendre connaissance du MAC et ainsi vérifier l’intégrité du texte clair.
Si tu fais quelque chose comme ça :
tu envoies à tar un texte clair dont l’intégrité n’a pas (encore) été vérifié. Si l’archive chiffrée a été modifiée par un attaquant, GnuPG affichera un message d’erreur en fin d’opération, mais dans le contexte d’un script appelé depuis une interface graphique (sans console pour afficher la sortie d’erreur standard), celui-ci passera inaperçu.
Il faut laisser GnuPG déchiffrer intégralement le fichier, vérifier le code de retour, et ensuite seulement détarrer l’archive :
[^] # Re: script pour chiffrer des fichiers et dossiers
Posté par gouttegd . En réponse au journal GnuPT a disparu. Évalué à 5.
Une attaque qui n’est pas réalisable en pratique, pour plusieurs raisons possibles :
Mais pour les cryptologues, toute attaque qui est moins complexe que la recherche exhaustive (aka brute-force) est formellement une attaque réussie, même si elle est complètement irréalisable.
Par exemple, l’attaque de Bogdanov et al. (2011) contre AES128 nécessite 288 paires de textes chiffrés/textes clairs et environ 2126 opérations pour retrouver une clef. Irréalisable, mais il n’empêche : elle est moins complexe qu’une recherche exhaustive de la clef (qui demanderait en moyenne 2127 opérations), donc c’est une bonne attaque.
Non.
Je ne sais pas ce qu’utilise la Wii, mais es-tu bien sûr que son algo asymétrique n’est pas standard ? Les industriels n’ont pas sorti les algorithmes à bases de courbes elliptiques d’un chapeau, hein. La plupart des implémentations utilisent les courbes standardisées par le NIST (NIST P256, P384, P521).
[^] # Re: script pour chiffrer des fichiers et dossiers
Posté par gouttegd . En réponse au journal GnuPT a disparu. Évalué à 4.
Euh, si, des attaques théoriques sur Rijndael, il y en a. Juste quelques-unes :
(Et juste pour le fun, la prétendue « attaque » de Filiol (2003), qui affirmait pouvoir casser non seulement AES mais n’importe quel algorithme de chiffrement par blocs — étonnamment (ou pas), personne n’a pu reproduire ses résultats.)
En fait, il y a probablement plus d’attaques (encore une fois, théoriques) sur Rijndael que sur n’importe quel autre finaliste de la compétition AES. L’intérêt des cryptologues pour les autres algorithmes s’est éteint lorsque Rijndael a été sélectionné (pourquoi s’attaquer à des algorithmes que personne ne va utiliser puisque tout le monde choisit l’algorithme standard ?).
Et ce sont justement toutes les attaques sur Rijndael qui renforcent la confiance dans cet algorithme : il est attaqué de toute part depuis quinze ans, et personne ne réussit à faire mieux que des attaques purement théoriques.
Évidemment qu’il est recommandé, c’est devenu LE standard du chiffrement symétrique.
En fait, AES est devenu l’algorithme que personne ne te reprochera de choisir, parce que tout le monde fait pareil. Si un jour il est cassé, le blâme ira à ses concepteurs. Alors que si tu utilises (au hasard) Twofish, et qu’il est un jour cassé, c’est toi qu’on blâmera pour avoir choisi autre chose que le standard.
[^] # Re: Anecdote sur cette chute.
Posté par gouttegd . En réponse au journal yippee ki-yay. Évalué à 6.
Pas la peine de soupçonner, il y a des cas avérés. Comme lorsque Tippi Hedren a failli se faire crever un œil sur le tournage de Birds (par de vrais corbeaux alors que Hitchcock lui avait assuré que la scène serait tournée avec des oiseaux mécaniques). Mais c’est de l’ART, Hitchcock est un GÉNIE (et Hedren une jeune actrice sans expérience), alors ça passe.
[^] # Re: Anecdote sur cette chute.
Posté par gouttegd . En réponse au journal yippee ki-yay. Évalué à 9. Dernière modification le 15 janvier 2016 à 18:48.
Donc, le cascadeur en chef voit ses collègues cascadeurs refuser de faire la cascade même sans l’effet de surprise parce que même comme ça c’est déjà dangereux, mais ça ne lui pose aucun problème de laisser un non-cascadeur faire la cascade en lui rajoutant un effet de surprise qui augmente probablement la dangerosité de la chose ?
C’est moi ou le réalisateur et le cascadeur « en chef » sont des irresponsables ?
[^] # Re: script pour chiffrer des fichiers et dossiers
Posté par gouttegd . En réponse au journal GnuPT a disparu. Évalué à 5.
Je ne suis pas sûr de comprendre pourquoi tu unset
GPG_AGENT_INFO, mais quelle qu’en soit la raison, attention : cette variable n’a plus aucun effet à partir de GnuPG ≥ 2.1. À partir de cette version, la socket de l’agent GPG n’est plus variable, mais toujours située à l’emplacement$GNUPG_HOME/S.gpg-agent.Si le but était de forcer GnuPG à démarrer un nouvel agent sans utiliser celui déjà lancé (pourquoi ?)… ça ne marchera pas avec GnuPG ≥ 2.1.
[^] # Re: dropbear SSH
Posté par gouttegd . En réponse au journal OpenSSH, UseRoaming no. Évalué à 4.
Si :
[^] # Re: dropbear SSH
Posté par gouttegd . En réponse au journal OpenSSH, UseRoaming no. Évalué à 4.
Dropbear est une implémentation de SSH (le protocole) qui est totalement indépendante de OpenSSH (l’implémentation dont il est question ici), donc même s’il implémentait la même option de roaming (ce qui n’est sans doute pas le cas, ça a l’air d’être une spécificité d’OpenSSH et non une fonctionnalité standardisée), il ne serait pas impacté.