J'aide un web-master à supprimer les spam de forum, mais maintenant tous par les proxy, vu qu'on a supprimé les plages des pays concernés.
Comme les proxy suppriment l'en-tête de l'expéditeur, j'aimerais savoir si quelqu'un connait le moyen de trouver l'origine dans le paquet ip.
Je sais que l'on peut le faire avec des programmes très spéciaux, qui coutent "les yeux de la tête"e;e;e;, mais n'y a t-il pas une autre méthode ou des programmes free/shreware qui le permettent ?
En fait, ce que je connaissais comme utilisation de MD5, c'est s'assur er qu'une transmission s'est correctement passée.
MD5, c'est une fonction de hachage. Une fonction de hachage cryptograph ique correcte, ça a les propriétés suivantes :
...
MD5 n'est plus considéré comme correcte, parce que 4 et 5 sont cass és. Plus spécifiquement, on sait fabriquer des fichiers qui ont le même MD5, et même des fichiers utiles (fabriquer deux blobs de données, c'est bien gent il, fabriquer deux exécutables et en faire signer un, c'est tout de suite plus dangereux). Pour l'attaque en préimage, c'est plus subtil : il y a un e attaque théorique en 2^123 essais ; 2^123, c'est monstrueux, complè tement inutilisable en pratique, mais dès lors que c'est moins que 2^127, on considère que c'est cassé.
Pour en revenir au fond, si tu as une fonction de hachage cryptographiq ue H, et que tu peux vérifier que H(a) = H(b), alors tu peux déduire qu e, à part gros coup de malchance, a = b. À partir de là, toutes les applica tions auxquelles tu peux penser sont possibles.
Oh alors ça, il faudra que je le relise demain ...
--
Nicolas George a écrit, le 15/03/2013 11:46 :
Gloops , dans le message <khtc62$35u$1@nntp.pasdenom.info>, a écrit :
En fait, ce que je connaissais comme utilisation de MD5, c'est s'assur er
qu'une transmission s'est correctement passée.
MD5, c'est une fonction de hachage. Une fonction de hachage cryptograph ique
correcte, ça a les propriétés suivantes :
...
MD5 n'est plus considéré comme correcte, parce que 4 et 5 sont cass és. Plus
spécifiquement, on sait fabriquer des fichiers qui ont le même MD5, et même
des fichiers utiles (fabriquer deux blobs de données, c'est bien gent il,
fabriquer deux exécutables et en faire signer un, c'est tout de suite plus
dangereux). Pour l'attaque en préimage, c'est plus subtil : il y a un e
attaque théorique en 2^123 essais ; 2^123, c'est monstrueux, complè tement
inutilisable en pratique, mais dès lors que c'est moins que 2^127, on
considère que c'est cassé.
Pour en revenir au fond, si tu as une fonction de hachage cryptographiq ue H,
et que tu peux vérifier que H(a) = H(b), alors tu peux déduire qu e, à part
gros coup de malchance, a = b. À partir de là, toutes les applica tions
auxquelles tu peux penser sont possibles.
Oh alors ça, il faudra que je le relise demain ...
En fait, ce que je connaissais comme utilisation de MD5, c'est s'assur er qu'une transmission s'est correctement passée.
MD5, c'est une fonction de hachage. Une fonction de hachage cryptograph ique correcte, ça a les propriétés suivantes :
...
MD5 n'est plus considéré comme correcte, parce que 4 et 5 sont cass és. Plus spécifiquement, on sait fabriquer des fichiers qui ont le même MD5, et même des fichiers utiles (fabriquer deux blobs de données, c'est bien gent il, fabriquer deux exécutables et en faire signer un, c'est tout de suite plus dangereux). Pour l'attaque en préimage, c'est plus subtil : il y a un e attaque théorique en 2^123 essais ; 2^123, c'est monstrueux, complè tement inutilisable en pratique, mais dès lors que c'est moins que 2^127, on considère que c'est cassé.
Pour en revenir au fond, si tu as une fonction de hachage cryptographiq ue H, et que tu peux vérifier que H(a) = H(b), alors tu peux déduire qu e, à part gros coup de malchance, a = b. À partir de là, toutes les applica tions auxquelles tu peux penser sont possibles.
Oh alors ça, il faudra que je le relise demain ...
--
Gloops
Nicolas George a écrit, le 15/03/2013 11:51 :
Stéphane Catteau , dans le message g>, a écrit :
1) La machine chez ton hébergeur est compromise. Ok, quelqu'un pourrait intercepter ton mot de passe à ce moment là, mais il n'en aurait pas besoin en fait.
Tu oublies un point important : beaucoup d'utilisateurs utilisent le mê me mot de passe sur plein de sites. Récupérer leur mot de passe sur un site nul permet d'avoir un bon candidat pour essayer d'accéder à leur co mpte sur un site plus important.
Là, il y a quand même l'hébergeur, qui m'a laissé tomber quand j' ai demandé comment on lance une commande IIS, mais qui impose un mot de passe avec un nombre minimal de caractères non alphanumériques, en précisant qu'il faut aussi des majuscules, des minuscules et des chiffr es.
Donc c'est un mot de passe correct, donc ça vaut le coup que son stockage le soit aussi.
2) Un routeur de ton hébergeur est compromis. 3) Un routeur entre chez toi et ton hébergeur est compris
Pour ça, il y a TLS, c'est correctement étudié et facile à mett re en place.
Au fait, as-tu des statistiques sur les hébergeurs qui supportent TLS e t ceux qui ne le supportent pas ? Avec éventuellement des noms des deux côtés (et ... du bon côté , éventuellement des raisons de fuir histoire qu'on évite de perdre du temps)
Nicolas George a écrit, le 15/03/2013 11:51 :
Stéphane Catteau , dans le message <mn.74bd7dd3606e690c.30736@sc4x.or g>,
a écrit :
1) La machine chez ton hébergeur est compromise. Ok, quelqu'un
pourrait intercepter ton mot de passe à ce moment là, mais il n'en
aurait pas besoin en fait.
Tu oublies un point important : beaucoup d'utilisateurs utilisent le mê me
mot de passe sur plein de sites. Récupérer leur mot de passe sur un site
nul permet d'avoir un bon candidat pour essayer d'accéder à leur co mpte sur
un site plus important.
Là, il y a quand même l'hébergeur, qui m'a laissé tomber quand j' ai
demandé comment on lance une commande IIS, mais qui impose un mot de
passe avec un nombre minimal de caractères non alphanumériques, en
précisant qu'il faut aussi des majuscules, des minuscules et des chiffr es.
Donc c'est un mot de passe correct, donc ça vaut le coup que son
stockage le soit aussi.
2) Un routeur de ton hébergeur est compromis.
3) Un routeur entre chez toi et ton hébergeur est compris
Pour ça, il y a TLS, c'est correctement étudié et facile à mett re en place.
Au fait, as-tu des statistiques sur les hébergeurs qui supportent TLS e t
ceux qui ne le supportent pas ?
Avec éventuellement des noms des deux côtés (et ... du bon côté ,
éventuellement des raisons de fuir histoire qu'on évite de perdre du temps)
1) La machine chez ton hébergeur est compromise. Ok, quelqu'un pourrait intercepter ton mot de passe à ce moment là, mais il n'en aurait pas besoin en fait.
Tu oublies un point important : beaucoup d'utilisateurs utilisent le mê me mot de passe sur plein de sites. Récupérer leur mot de passe sur un site nul permet d'avoir un bon candidat pour essayer d'accéder à leur co mpte sur un site plus important.
Là, il y a quand même l'hébergeur, qui m'a laissé tomber quand j' ai demandé comment on lance une commande IIS, mais qui impose un mot de passe avec un nombre minimal de caractères non alphanumériques, en précisant qu'il faut aussi des majuscules, des minuscules et des chiffr es.
Donc c'est un mot de passe correct, donc ça vaut le coup que son stockage le soit aussi.
2) Un routeur de ton hébergeur est compromis. 3) Un routeur entre chez toi et ton hébergeur est compris
Pour ça, il y a TLS, c'est correctement étudié et facile à mett re en place.
Au fait, as-tu des statistiques sur les hébergeurs qui supportent TLS e t ceux qui ne le supportent pas ? Avec éventuellement des noms des deux côtés (et ... du bon côté , éventuellement des raisons de fuir histoire qu'on évite de perdre du temps)
Gloops
Nicolas George a écrit, le 15/03/2013 11:29 :
Gloops , dans le message <khtdrv$3mm$, a écrit :
Bon alors finalement, la solution pourrait être un logiciel maison q ui irait collecter un maximum de données à droite et à gauche (syst ème, registre, répertoires, type de processeur, contenus de fichiers ...) , et en passerait une partie en arguments à un programme de cryptage reco nnu.
Tu es encore en train de faire de la cryptographie au petit bonheur la chance. Ça ne marche pas. Avant de chercher une solution, il faut que tu définisses correctement ton problème :
1. Quelles sont les données que tu veux protéger ?
2. Quel accès doit être possible, en utilisation normale, à ces d onnées ?
3. Contre quel genre d'attaques souhaites-tu les protéger ?
Je reviendrai, parce que ce que je dirais ce soir ne vaudrait pas le coup .
--
Nicolas George a écrit, le 15/03/2013 11:29 :
Gloops , dans le message <khtdrv$3mm$1@nntp.pasdenom.info>, a écrit :
Bon alors finalement, la solution pourrait être un logiciel maison q ui
irait collecter un maximum de données à droite et à gauche (syst ème,
registre, répertoires, type de processeur, contenus de fichiers ...) , et
en passerait une partie en arguments à un programme de cryptage reco nnu.
Tu es encore en train de faire de la cryptographie au petit bonheur la
chance. Ça ne marche pas. Avant de chercher une solution, il faut que tu
définisses correctement ton problème :
1. Quelles sont les données que tu veux protéger ?
2. Quel accès doit être possible, en utilisation normale, à ces d onnées ?
3. Contre quel genre d'attaques souhaites-tu les protéger ?
Je reviendrai, parce que ce que je dirais ce soir ne vaudrait pas le coup .
Bon alors finalement, la solution pourrait être un logiciel maison q ui irait collecter un maximum de données à droite et à gauche (syst ème, registre, répertoires, type de processeur, contenus de fichiers ...) , et en passerait une partie en arguments à un programme de cryptage reco nnu.
Tu es encore en train de faire de la cryptographie au petit bonheur la chance. Ça ne marche pas. Avant de chercher une solution, il faut que tu définisses correctement ton problème :
1. Quelles sont les données que tu veux protéger ?
2. Quel accès doit être possible, en utilisation normale, à ces d onnées ?
3. Contre quel genre d'attaques souhaites-tu les protéger ?
Je reviendrai, parce que ce que je dirais ce soir ne vaudrait pas le coup .
--
xavier
Gloops wrote:
Sous Windows ça s'appelle comment, ça ?
Ca s'appelle pas. Windows et SSH, c'est pain in the ass. On y arrive, mais on en chie.
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear. (Jethro Tull)
Gloops <gloops@zailes.invalid.org> wrote:
Sous Windows ça s'appelle comment, ça ?
Ca s'appelle pas. Windows et SSH, c'est pain in the ass. On y arrive,
mais on en chie.
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
(Jethro Tull)
Ca s'appelle pas. Windows et SSH, c'est pain in the ass. On y arrive, mais on en chie.
ça a le mérite d'être gracieux :)
Stéphane Catteau
Nicolas George n'était pas loin de dire :
[Désolé pour le retard, obligations familiales qui m'ont accessoirement permis de tester un truc]
Après tout tu l'as dit toi-même par ailleurs, ce qui compte c'est la clé et non pas l'algorithme de cryptage ; pour un algorithme de hachage, c'est le nombre de bit qui se rapproche le plus de cette clé.
Je ne suis pas d'accord. Si on veut comparer une fonction de hachage à une fonction de chiffrement,
Je dois vraiment très mal m'exprimer en ce moment :/ Où est-il question de comparaison ? Tu dis, à juste titre, que ce qui importe le plus ce n'est pas l'algorithme de cryptage que l'on choisi, mais la clé que l'on y associe. Pour ma part je me contente de dire que, si l'on rapporte cette phrase à un algorithme de hachage, donc si l'on doit définir ce qui est le facteur le plus important dans un tel algorithme, alors c'est le nombre de bit qui ressort ; autrement dit que le plus important ce n'est pas l'algorithme de hachage que l'on choisi, mais le nombre de bit sur lequel il travail. Après tout, le bon vieux CRC32 est un algorithme de hachage, mais si le controle de redondance cyclique vaut encore quelque chose pour détecter les erreurs, il montre néanmoins ses limites sur les flux de très grande taille et ne vaut pas grand chose dans les autres usages dévolus, de fait pour par la pratique, à ces algorithmes.
Evidement, le rapport d'exactitude entre les deux affirmations (importance forte de la clé ou du nombre de bit, par rapport à l'importance faible de l'algrithme) est plus limité dans le cas d'un algorithme de hachage. En effet, le nombre de bit est directement lié à celui-ci, alors qu'un bon algorithme de cryptage sait travailler avec des clés de longueur/robustesse variable. Rapporté à la pratique, cette affirmation revient donc à dire que l'algorithme de hachage choisi importe peu, tant qu'il fait parti de ceux utilisant le plus grand nombre de bits. Cela étant, tout comme pour les algorithmes de cryptage, à pondérer ensuite en fonction des failles découvertes.
[snip]
Je pense que tu t'embrouilles quelque part. D'ailleurs, je trouve ces deux paragraphes très confus, au point que je n'arrive pas à voir exactement de quoi tu parles.
Parce que tu occultes, involontairement je n'en doute pas un seul instant, le point important.
Par exemple, au début du deuxième, tu sembles dire que sur dix chaînes aléatoires, il y en aura probablement quatre qui auront le même MD5 : non, non, c'est juste faux.
Ce n'est pas ce que j'ai dit. Je vais décomposer l'action pour essayer d'être plus précis : 1) J'ai généré onze (voir plus loin) hash MD5 au hasard en tapant aléatoirement sur le clavier (donc j'avais les chaînes sous les yeux). 2) J'ai soumis ses onze hash au dictionnaire déjà cité. 3) Dans six cas, il ne m'a rien retourné. 4) Dans un cas il m'a retourné la chaîne que j'avais utilisée, j'ai donc exclus, peut-être à tort, cette chaine. 5) Dans les quatre cas restant, il a bien trouvé quelque chose correspondant à ce hash, mais ce n'était *pas* la chaîne que j'avais utilisé.
De là j'ai terminé en disant que l'échantillon était évidement trop faible pour en tirer de réelle conclusion, mais que le fait était là, c'était possible. Maintenant, après avoir lu ton message, je rajouterais que j'aurais du jouer au loto car c'était visiblement mon jour de chance ; j'ai réalisé l'impossible et je l'ai réalisé quatre fois de suite.
Cela étant dit, j'ai profité du fait qu'un autre site, disposant d'un dictionnaire plus conséquent dispose d'une méthode d'interrogation directe de son dictionnaire et des quatre jours qui allaient m'éloigner du forum, pour écrire rapidement un script générant des chaines aléatoires (de l'espace au tilde) entre 10 et 110 caractères, ainsi que de chaînes plus proches des mots de passes (alphanumérique entre 6 et 16 caractères) et j'ai testé 30 000 générations pour chaque cas (avec une pause pour ne pas trop stresser le site) L'échantillon est déjà plus conséquent, même s'il reste faible compte-tenu du nombre possible de hash. Résultat, pour les chaînes complexe, une centaine de fois le hash était déjà dans la base de données, contre un peu moins d'un millier pour les hashs de chaines alphanumérique. Et dans un cas comme dans l'autre, il y a eu une petite dizaine (8 et 7) de cas où le site a donné une autre chaîne que celle ayant servi à générer le hash (le script vérifiait ensuite que les deux donnaient effectivement le même hash). Visiblement, j'ai peut-être encore le temps de jouer au loto ;)
D'ailleurs, à ma connaissance, on ne connaît que des collisions « jumelle »
Voilà d'où vient le problème de compréhension entre nous. En bon mathématicien, pour toi la probabilité que cela se produise est si faible qu'elle est impossible ; alors ne parlons pas de la probabilité que cela se reproduise pour une même personne. Cela dit, je le comprends et n'exclus pas le fait que j'ai énormément de chance à chaque fois que je fais mumuse avec des chaînes aléatoires et des dictionnaires.
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
Nicolas George n'était pas loin de dire :
[Désolé pour le retard, obligations familiales qui m'ont accessoirement
permis de tester un truc]
Après tout tu l'as dit toi-même par ailleurs, ce qui compte c'est la
clé et non pas l'algorithme de cryptage ; pour un algorithme de
hachage, c'est le nombre de bit qui se rapproche le plus de cette clé.
Je ne suis pas d'accord. Si on veut comparer une fonction de hachage à une
fonction de chiffrement,
Je dois vraiment très mal m'exprimer en ce moment :/ Où est-il
question de comparaison ?
Tu dis, à juste titre, que ce qui importe le plus ce n'est pas
l'algorithme de cryptage que l'on choisi, mais la clé que l'on y
associe. Pour ma part je me contente de dire que, si l'on rapporte
cette phrase à un algorithme de hachage, donc si l'on doit définir ce
qui est le facteur le plus important dans un tel algorithme, alors
c'est le nombre de bit qui ressort ; autrement dit que le plus
important ce n'est pas l'algorithme de hachage que l'on choisi, mais le
nombre de bit sur lequel il travail.
Après tout, le bon vieux CRC32 est un algorithme de hachage, mais si
le controle de redondance cyclique vaut encore quelque chose pour
détecter les erreurs, il montre néanmoins ses limites sur les flux de
très grande taille et ne vaut pas grand chose dans les autres usages
dévolus, de fait pour par la pratique, à ces algorithmes.
Evidement, le rapport d'exactitude entre les deux affirmations
(importance forte de la clé ou du nombre de bit, par rapport à
l'importance faible de l'algrithme) est plus limité dans le cas d'un
algorithme de hachage. En effet, le nombre de bit est directement lié à
celui-ci, alors qu'un bon algorithme de cryptage sait travailler avec
des clés de longueur/robustesse variable.
Rapporté à la pratique, cette affirmation revient donc à dire que
l'algorithme de hachage choisi importe peu, tant qu'il fait parti de
ceux utilisant le plus grand nombre de bits. Cela étant, tout comme
pour les algorithmes de cryptage, à pondérer ensuite en fonction des
failles découvertes.
[snip]
Je pense que tu t'embrouilles quelque part. D'ailleurs, je trouve ces deux
paragraphes très confus, au point que je n'arrive pas à voir exactement de
quoi tu parles.
Parce que tu occultes, involontairement je n'en doute pas un seul
instant, le point important.
Par exemple, au début du deuxième, tu sembles dire que sur dix chaînes
aléatoires, il y en aura probablement quatre qui auront le même MD5 :
non, non, c'est juste faux.
Ce n'est pas ce que j'ai dit. Je vais décomposer l'action pour essayer
d'être plus précis :
1) J'ai généré onze (voir plus loin) hash MD5 au hasard en tapant
aléatoirement sur le clavier (donc j'avais les chaînes sous les yeux).
2) J'ai soumis ses onze hash au dictionnaire déjà cité.
3) Dans six cas, il ne m'a rien retourné.
4) Dans un cas il m'a retourné la chaîne que j'avais utilisée, j'ai
donc exclus, peut-être à tort, cette chaine.
5) Dans les quatre cas restant, il a bien trouvé quelque chose
correspondant à ce hash, mais ce n'était *pas* la chaîne que j'avais
utilisé.
De là j'ai terminé en disant que l'échantillon était évidement trop
faible pour en tirer de réelle conclusion, mais que le fait était là,
c'était possible.
Maintenant, après avoir lu ton message, je rajouterais que j'aurais du
jouer au loto car c'était visiblement mon jour de chance ; j'ai réalisé
l'impossible et je l'ai réalisé quatre fois de suite.
Cela étant dit, j'ai profité du fait qu'un autre site, disposant d'un
dictionnaire plus conséquent dispose d'une méthode d'interrogation
directe de son dictionnaire et des quatre jours qui allaient m'éloigner
du forum, pour écrire rapidement un script générant des chaines
aléatoires (de l'espace au tilde) entre 10 et 110 caractères, ainsi que
de chaînes plus proches des mots de passes (alphanumérique entre 6 et
16 caractères) et j'ai testé 30 000 générations pour chaque cas (avec
une pause pour ne pas trop stresser le site)
L'échantillon est déjà plus conséquent, même s'il reste faible
compte-tenu du nombre possible de hash. Résultat, pour les chaînes
complexe, une centaine de fois le hash était déjà dans la base de
données, contre un peu moins d'un millier pour les hashs de chaines
alphanumérique. Et dans un cas comme dans l'autre, il y a eu une petite
dizaine (8 et 7) de cas où le site a donné une autre chaîne que celle
ayant servi à générer le hash (le script vérifiait ensuite que les deux
donnaient effectivement le même hash).
Visiblement, j'ai peut-être encore le temps de jouer au loto ;)
D'ailleurs, à ma connaissance, on ne connaît que des collisions
« jumelle »
Voilà d'où vient le problème de compréhension entre nous. En bon
mathématicien, pour toi la probabilité que cela se produise est si
faible qu'elle est impossible ; alors ne parlons pas de la probabilité
que cela se reproduise pour une même personne.
Cela dit, je le comprends et n'exclus pas le fait que j'ai énormément
de chance à chaque fois que je fais mumuse avec des chaînes aléatoires
et des dictionnaires.
[Désolé pour le retard, obligations familiales qui m'ont accessoirement permis de tester un truc]
Après tout tu l'as dit toi-même par ailleurs, ce qui compte c'est la clé et non pas l'algorithme de cryptage ; pour un algorithme de hachage, c'est le nombre de bit qui se rapproche le plus de cette clé.
Je ne suis pas d'accord. Si on veut comparer une fonction de hachage à une fonction de chiffrement,
Je dois vraiment très mal m'exprimer en ce moment :/ Où est-il question de comparaison ? Tu dis, à juste titre, que ce qui importe le plus ce n'est pas l'algorithme de cryptage que l'on choisi, mais la clé que l'on y associe. Pour ma part je me contente de dire que, si l'on rapporte cette phrase à un algorithme de hachage, donc si l'on doit définir ce qui est le facteur le plus important dans un tel algorithme, alors c'est le nombre de bit qui ressort ; autrement dit que le plus important ce n'est pas l'algorithme de hachage que l'on choisi, mais le nombre de bit sur lequel il travail. Après tout, le bon vieux CRC32 est un algorithme de hachage, mais si le controle de redondance cyclique vaut encore quelque chose pour détecter les erreurs, il montre néanmoins ses limites sur les flux de très grande taille et ne vaut pas grand chose dans les autres usages dévolus, de fait pour par la pratique, à ces algorithmes.
Evidement, le rapport d'exactitude entre les deux affirmations (importance forte de la clé ou du nombre de bit, par rapport à l'importance faible de l'algrithme) est plus limité dans le cas d'un algorithme de hachage. En effet, le nombre de bit est directement lié à celui-ci, alors qu'un bon algorithme de cryptage sait travailler avec des clés de longueur/robustesse variable. Rapporté à la pratique, cette affirmation revient donc à dire que l'algorithme de hachage choisi importe peu, tant qu'il fait parti de ceux utilisant le plus grand nombre de bits. Cela étant, tout comme pour les algorithmes de cryptage, à pondérer ensuite en fonction des failles découvertes.
[snip]
Je pense que tu t'embrouilles quelque part. D'ailleurs, je trouve ces deux paragraphes très confus, au point que je n'arrive pas à voir exactement de quoi tu parles.
Parce que tu occultes, involontairement je n'en doute pas un seul instant, le point important.
Par exemple, au début du deuxième, tu sembles dire que sur dix chaînes aléatoires, il y en aura probablement quatre qui auront le même MD5 : non, non, c'est juste faux.
Ce n'est pas ce que j'ai dit. Je vais décomposer l'action pour essayer d'être plus précis : 1) J'ai généré onze (voir plus loin) hash MD5 au hasard en tapant aléatoirement sur le clavier (donc j'avais les chaînes sous les yeux). 2) J'ai soumis ses onze hash au dictionnaire déjà cité. 3) Dans six cas, il ne m'a rien retourné. 4) Dans un cas il m'a retourné la chaîne que j'avais utilisée, j'ai donc exclus, peut-être à tort, cette chaine. 5) Dans les quatre cas restant, il a bien trouvé quelque chose correspondant à ce hash, mais ce n'était *pas* la chaîne que j'avais utilisé.
De là j'ai terminé en disant que l'échantillon était évidement trop faible pour en tirer de réelle conclusion, mais que le fait était là, c'était possible. Maintenant, après avoir lu ton message, je rajouterais que j'aurais du jouer au loto car c'était visiblement mon jour de chance ; j'ai réalisé l'impossible et je l'ai réalisé quatre fois de suite.
Cela étant dit, j'ai profité du fait qu'un autre site, disposant d'un dictionnaire plus conséquent dispose d'une méthode d'interrogation directe de son dictionnaire et des quatre jours qui allaient m'éloigner du forum, pour écrire rapidement un script générant des chaines aléatoires (de l'espace au tilde) entre 10 et 110 caractères, ainsi que de chaînes plus proches des mots de passes (alphanumérique entre 6 et 16 caractères) et j'ai testé 30 000 générations pour chaque cas (avec une pause pour ne pas trop stresser le site) L'échantillon est déjà plus conséquent, même s'il reste faible compte-tenu du nombre possible de hash. Résultat, pour les chaînes complexe, une centaine de fois le hash était déjà dans la base de données, contre un peu moins d'un millier pour les hashs de chaines alphanumérique. Et dans un cas comme dans l'autre, il y a eu une petite dizaine (8 et 7) de cas où le site a donné une autre chaîne que celle ayant servi à générer le hash (le script vérifiait ensuite que les deux donnaient effectivement le même hash). Visiblement, j'ai peut-être encore le temps de jouer au loto ;)
D'ailleurs, à ma connaissance, on ne connaît que des collisions « jumelle »
Voilà d'où vient le problème de compréhension entre nous. En bon mathématicien, pour toi la probabilité que cela se produise est si faible qu'elle est impossible ; alors ne parlons pas de la probabilité que cela se reproduise pour une même personne. Cela dit, je le comprends et n'exclus pas le fait que j'ai énormément de chance à chaque fois que je fais mumuse avec des chaînes aléatoires et des dictionnaires.
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
Stéphane Catteau
Gloops devait dire quelque chose comme ceci :
J'ai du mal m'exprimer (ça semble récurent ces temps ci). Je me plaçais dans l'optique d'une connexion avec un protocole d'autentification clé publique/clé privée. C'est donc ta clé privée que tu stockes sur une clé USB. Tu connectes donc ta clé USB à ton ordinateur, ce qui te permet d'avoir accès à ta clé privée et de t'autentifier.
Mais ... La clef publique, enfin celle qui sert à décoder, doit être dans le fichier de configuration ?
Oui et alors ? Ce n'est que la clé qui valide la clé privée, peut importe qu'elle se balade dans la nature ou non, elle ne permet ni de se faire passer pour toi, ni de décrypter les flux interceptés (sauf si l'algorithme ne s'appuie que sur la clé pour les crypter, ce qui n'existe plus il me semble).
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
Gloops devait dire quelque chose comme ceci :
J'ai du mal m'exprimer (ça semble récurent ces temps ci). Je me
plaçais dans l'optique d'une connexion avec un protocole
d'autentification clé publique/clé privée. C'est donc ta clé privée que
tu stockes sur une clé USB. Tu connectes donc ta clé USB à ton
ordinateur, ce qui te permet d'avoir accès à ta clé privée et de
t'autentifier.
Mais ... La clef publique, enfin celle qui sert à décoder, doit être
dans le fichier de configuration ?
Oui et alors ? Ce n'est que la clé qui valide la clé privée, peut
importe qu'elle se balade dans la nature ou non, elle ne permet ni de
se faire passer pour toi, ni de décrypter les flux interceptés (sauf si
l'algorithme ne s'appuie que sur la clé pour les crypter, ce qui
n'existe plus il me semble).
J'ai du mal m'exprimer (ça semble récurent ces temps ci). Je me plaçais dans l'optique d'une connexion avec un protocole d'autentification clé publique/clé privée. C'est donc ta clé privée que tu stockes sur une clé USB. Tu connectes donc ta clé USB à ton ordinateur, ce qui te permet d'avoir accès à ta clé privée et de t'autentifier.
Mais ... La clef publique, enfin celle qui sert à décoder, doit être dans le fichier de configuration ?
Oui et alors ? Ce n'est que la clé qui valide la clé privée, peut importe qu'elle se balade dans la nature ou non, elle ne permet ni de se faire passer pour toi, ni de décrypter les flux interceptés (sauf si l'algorithme ne s'appuie que sur la clé pour les crypter, ce qui n'existe plus il me semble).
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
Stéphane Catteau
Gloops n'était pas loin de dire :
C'est un peu pour ça que j'imaginais introduire des variations dans le stockage de la clef de cryptage, pour que le pirate ne sache pas tout de suite où chercher ...
Et donc toi-même tu finiras par ne plus savoir où chercher et tu te retrouveras coincé face à un serveur avec lequel seul un accès physique permettrait de récupérer tes données.
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
Gloops n'était pas loin de dire :
C'est un peu pour ça que j'imaginais introduire des variations dans le
stockage de la clef de cryptage, pour que le pirate ne sache pas tout de
suite où chercher ...
Et donc toi-même tu finiras par ne plus savoir où chercher et tu te
retrouveras coincé face à un serveur avec lequel seul un accès physique
permettrait de récupérer tes données.
C'est un peu pour ça que j'imaginais introduire des variations dans le stockage de la clef de cryptage, pour que le pirate ne sache pas tout de suite où chercher ...
Et donc toi-même tu finiras par ne plus savoir où chercher et tu te retrouveras coincé face à un serveur avec lequel seul un accès physique permettrait de récupérer tes données.
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
Stéphane Catteau
Nicolas George devait dire quelque chose comme ceci :
1) La machine chez ton hébergeur est compromise. Ok, quelqu'un pourrait intercepter ton mot de passe à ce moment là, mais il n'en aurait pas besoin en fait.
Tu oublies un point important : beaucoup d'utilisateurs utilisent le même mot de passe sur plein de sites. Récupérer leur mot de passe sur un site nul permet d'avoir un bon candidat pour essayer d'accéder à leur compte sur un site plus important.
Comme il s'agit du mot de passe d'administration, je suis parti du principe qu'il était unique. Si ce n'est pas le cas, la faille ne vient pas tant de l'hébergeur qui s'est fait trouer sa machine, que de l'utilisateur qui a le cerveau troué.
2) Un routeur de ton hébergeur est compromis. 3) Un routeur entre chez toi et ton hébergeur est compris
Pour ça, il y a TLS, c'est correctement étudié et facile à mettre en place.
Exact. On peut aussi passer par TOR pour limiter le nombre de routeurs et/ou dans le cas d'un dédié passer par un VPN.
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
Nicolas George devait dire quelque chose comme ceci :
1) La machine chez ton hébergeur est compromise. Ok, quelqu'un
pourrait intercepter ton mot de passe à ce moment là, mais il n'en
aurait pas besoin en fait.
Tu oublies un point important : beaucoup d'utilisateurs utilisent le même
mot de passe sur plein de sites. Récupérer leur mot de passe sur un site
nul permet d'avoir un bon candidat pour essayer d'accéder à leur compte sur
un site plus important.
Comme il s'agit du mot de passe d'administration, je suis parti du
principe qu'il était unique. Si ce n'est pas le cas, la faille ne vient
pas tant de l'hébergeur qui s'est fait trouer sa machine, que de
l'utilisateur qui a le cerveau troué.
2) Un routeur de ton hébergeur est compromis.
3) Un routeur entre chez toi et ton hébergeur est compris
Pour ça, il y a TLS, c'est correctement étudié et facile à mettre en place.
Exact. On peut aussi passer par TOR pour limiter le nombre de routeurs
et/ou dans le cas d'un dédié passer par un VPN.
Nicolas George devait dire quelque chose comme ceci :
1) La machine chez ton hébergeur est compromise. Ok, quelqu'un pourrait intercepter ton mot de passe à ce moment là, mais il n'en aurait pas besoin en fait.
Tu oublies un point important : beaucoup d'utilisateurs utilisent le même mot de passe sur plein de sites. Récupérer leur mot de passe sur un site nul permet d'avoir un bon candidat pour essayer d'accéder à leur compte sur un site plus important.
Comme il s'agit du mot de passe d'administration, je suis parti du principe qu'il était unique. Si ce n'est pas le cas, la faille ne vient pas tant de l'hébergeur qui s'est fait trouer sa machine, que de l'utilisateur qui a le cerveau troué.
2) Un routeur de ton hébergeur est compromis. 3) Un routeur entre chez toi et ton hébergeur est compris
Pour ça, il y a TLS, c'est correctement étudié et facile à mettre en place.
Exact. On peut aussi passer par TOR pour limiter le nombre de routeurs et/ou dans le cas d'un dédié passer par un VPN.
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
Stéphane Catteau
Gloops n'était pas loin de dire :
Tu oublies un point important : beaucoup d'utilisateurs utilisent le même mot de passe sur plein de sites. Récupérer leur mot de passe sur un site nul permet d'avoir un bon candidat pour essayer d'accéder à leur compte sur un site plus important.
Là, il y a quand même l'hébergeur, qui m'a laissé tomber quand j'ai demandé comment on lance une commande IIS,
Ce qui est logique. Tu dis toi-même que c'est du mutualisé, il y a donc X personnes qui partage le même serveur. Non seulement cela constituerait une faille de sécurité puisque tu pourrais sortir de ta zone réservée, mais en plus bonjour l'état du serveur si à chaque script celui-ci était reconfiguré par les uns et les autres.
-- 17/06/1969 - 18/01/2011
Repose en paix mon amour :'(
Gloops n'était pas loin de dire :
Tu oublies un point important : beaucoup d'utilisateurs utilisent le même
mot de passe sur plein de sites. Récupérer leur mot de passe sur un site
nul permet d'avoir un bon candidat pour essayer d'accéder à leur compte sur
un site plus important.
Là, il y a quand même l'hébergeur, qui m'a laissé tomber quand j'ai
demandé comment on lance une commande IIS,
Ce qui est logique. Tu dis toi-même que c'est du mutualisé, il y a
donc X personnes qui partage le même serveur. Non seulement cela
constituerait une faille de sécurité puisque tu pourrais sortir de ta
zone réservée, mais en plus bonjour l'état du serveur si à chaque
script celui-ci était reconfiguré par les uns et les autres.
Tu oublies un point important : beaucoup d'utilisateurs utilisent le même mot de passe sur plein de sites. Récupérer leur mot de passe sur un site nul permet d'avoir un bon candidat pour essayer d'accéder à leur compte sur un site plus important.
Là, il y a quand même l'hébergeur, qui m'a laissé tomber quand j'ai demandé comment on lance une commande IIS,
Ce qui est logique. Tu dis toi-même que c'est du mutualisé, il y a donc X personnes qui partage le même serveur. Non seulement cela constituerait une faille de sécurité puisque tu pourrais sortir de ta zone réservée, mais en plus bonjour l'état du serveur si à chaque script celui-ci était reconfiguré par les uns et les autres.
