Filtrage IP

Nicolas George devait dire quelque chose comme ceci :

Euh, attends, je pense que j'ai compris ce que tu n'as pas compris.

Même chose. En fait on regarde le problème avec chacun d'un point de
vue trop différent pour arriver à s'accorder. Alors qu'au final je suis
convaincu que l'on pense pareil. 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é.


[snip]

Mais ce n'est pas ça dont tu as parlé. Tu as évoqué des sites du genre de
<URL: http://md5.noisette.ch/ > : ce ne sont pas des collisions que ce site
exploite, c'est juste une grosse base de données de MD5 connus, c'est une
attaque par dictionnaire.

Dictionnaire qui fonctionne en partie parce qu'il y a collision.

Dans le cas d'un mot de passe en clair, il faut qu'il soit dans le
dictionnaire pour être trouvé. Dès que tu sors des sentiers battus, tu
augmente largement la robustesse de ton mot de passe. "stephane" est un
mot de passe très fragile face à un dictionnaire, "stéphane" resistera
à tout ceux qui oublient qu'il existe des accents et "stép0hane"
resistera à quasiment tous les dictionnaires possibles.
Mais il en va autrement dans le cas d'un hash MD5, parce qu'il y a
possibilité de collision et que cette possibilité est finalement bien
plus grande qu'on ne le pensait.

Je sais que ce n'est qu'un exemple, mais franchement, sur dix chaînes
au hasard pouvant correspondrent à un mot de passe, arriver à trouver
quatre collisions, ça ne te semble pas énorme ? Et je parle bien de
collisions, de tous les essais que j'ai pu faire, aujourd'hui et avant,
jamais je ne suis tombé sur une chaîne qui correspondait à celle que
j'avais utilisée pour générer le hash.
Mais bon, j'avoue que j'excluais d'entré les chaînes les plus
élémentaires. Les milles mots les plus utilisés en anglais, par
exemple, doivent être présent dans tous les dictionnaires visant MD5 et
en fait n'importe quel algorithme de hachage. Même chose pour les
prénoms et probablement le contenu des dictionnaires utilisés pour les
mots de passe en clair.

C'est justement pour cela que ma confiance en MD5 a baissé et pour
cela que j'accuse les collisions. Un mot de passe qui resisterait à un
dictionnaire s'il était en clair, devient soudain plus vulnérable parce
qu'il est stocké sous forme d'un hash MD5 (sans grain de sel
évidement), tout cela parce qu'il y a au final un trop grand risque de
collision.

--
17/06/1969 - 18/01/2011

Repose en paix mon amour :'(

Stéphane Catteau a écrit, le 14/03/2013 17:09 :

Dans l'absolue je suis d'accord avec toi, protéger un login ne sert
strictement à rien. Mais tu as apparament oublié la raison de cette
discussion, à savoir que Gloops veut protéger les adresses e-mail d e
ses utilisateurs. Dès lors que cette adresse serait utilisée en tan t
que login (ce qui est très répandu) le seul moyen de la protéger c'est
de crypter aussi le login.

C'est-à-dire que comme identifiant on peut mettre un pseudo. Après, s i
on veut envoyer une newsletter il faut bien avoir l'adresse quelque
part. Bien sûr, pour juste écrire dans un forum, sans alerte de
réponses, c'est vrai que l'adresse mail ne s'impose pas.

Donc du coup, pour tphilippet qui a initié le fil, comme il parlait d'u n
forum, il peut se contenter de stocker pseudo et mot de passe, et
l'adresse mail ne sert que le temps de la valider (sauf si elle est
utilisée pour autre chose sur le site, je n'ai pas regardé). Si jamai s
la base est corrompue (dans le sens accès non autorisé), tout ce qu'o n
risque c'est du spam dans le forum (puisque le pirate a accès aux mots
de passe), pas dans la boîte mail de l'intervenant.

Encore que la base ASPNETDB générée automatiquement sur les sites
Asp.Net crypte automatiquement les mots de passe, donc de ce côté on est
tranquille. Mais j'ai cru comprendre qu'il n'y a pas trop d'utilisateurs
de cette plateforme ici.

Pour ma part j'ai un projet de lettre de diffusion pour alerter de mises
à jour de logiciels, là du coup je suis obligé de poursuivre la
réflexion. Pour sûr, les destinataires passeront moins de temps à l ire
la lettre de diffusion que j'en aurai passé à m'assurer que ça ne l eur
attire pas des saletés dans leur boîte mail.

Nicolas George a écrit, le 14/03/2013 19:28 :

Gloops , dans le message <kht3qe$vvi$1@nntp.pasdenom.info>, a écrit :

Ah mais je croyais que tu plaisantais.
Tu fais comment une connexion à une base de données, toi ?
Tu n'as pas une chaîne de caractères qui contient le type de base, le
mot de passe, éventuellement le protocole ?

Donc tu parlais de la chaîne qui sert à décrire la connexion à la base de
données pour l'API que tu utilises. Ça n'avait rien d'évident.

Évidemment, si wikipedia s'y met aussi, et répond Canalsat, eh bie n
comme disait un chef de projet dont tu apprécieras l'élégance, " on n'a
pas le cul sorti des ronces".

Rien compris.

Ben Canalsat, comme chaîne de caractères pour décrire la connexion à une
base de données ... c'est un peu raté.

http://www.trucsweb.com/ASP/trucs.asp?no=102&type=7

« SQL Server, Access, Oracle, BD2, Foxpro, MySQL, Excel... »

-> poubelle.

ça explique que ce n'était pas évident ci-dessus : c'est vrai que t out
ça est à peu près de la même origine, et que j'ai plus ou moins t oujours
travaillé avec, donc c'était plus évident pour moi. J'étais persu adé que
cette notion était multiplateforme, et que seul le contenu de la chaî ne
changeait d'un type de base à un autre, d'où le peu de détails four ni.

En fait, ce que je connaissais comme utilisation de MD5, c'est s'assurer
qu'une transmission s'est correctement passée. Un jour, j'ai eu une
image de disque dont le logiciel de sauvegarde m'avait dit qu'elle étai t
correcte, sauf qu'il s'est avéré que dedans il n'y avait que des zé ros.
Il est peu probable que la somme MD5 de cette sauvegarde ait été
conforme à celle de l'original. Malheureusement, pour faire la
comparaison, il fallait la faire fichier par fichier et écrire un scrip t
pour ça ... J'aurais dû le faire, tiens.

Alors après, là vous me faites entrevoir une formule qui semble avoir de
plus grandes chances de masquer le contenu d'une base qu'un cryptage
dont la clef serait publiée dans le même répertoire que la base.

A savoir, un hashage basé sur un pseudo, qui donnerait un
enregistrement, dont le contenu ne serait révélé que si on fournit le
mot de passe qui se trouve dedans. A quelques précautions près
concernant les pseudos donnant le même hashage. Vous me dites qu'il fau t
faire une recherche sur Putty ?

Nicolas George a écrit, le 14/03/2013 19:41 :

Gloops , dans le message <kht53a$jq$1@nntp.pasdenom.info>, a écrit :

Mais es-tu capable de refournir le
texte originel à partir du MD5 ?

Non, évidemment, c'est le principe d'une fonction de hachage.

Mais il ne faut plus utiliser MD5. De nos jours, le choix le plus évi dent
est SHA-2.

Je ne suis pas très sûr de mémoire, il me semble que c'est ça que j'ai
utilisé. Si vous voulez je pourrai regarder pendant le week-end (ah au
fait ne vous étonnez pas, je ne suis pas là demain, d'ailleurs je
devrais être couché).

D'ailleurs, je crois que j'ai sorti une énormité à l'instant.
Un hashage pour confirmer un mot de passe proposé c'est bien, mais ...
pour fournir une chaîne de connexion à partir de son cryptage, j'ai p eur
de m'être emballé un peu vite.

Bon alors finalement, la solution pourrait être un logiciel maison qui
irait collecter un maximum de données à droite et à gauche (systè me,
registre, répertoires, type de processeur, contenus de fichiers ...), e t
en passerait une partie en arguments à un programme de cryptage reconnu .

Le programme de cryptage bénéficie de l'expérience des gens qui l'o nt
amélioré au fil du temps, et ça n'empêche pas de changer réguli èrement
le stockage des clefs. La contrainte, pour ça, c'est être disponible
pour développer de nouvelles versions du programme de stockage des clef s
de cryptage. Et c'est mieux aussi de disposer d'une machine de
développement qui soit rarement en ligne, vu que c'est assez évident que
si le pirate a l'occasion de fourrer son nez dans les sources en clair
du programme ...

J'ai l'impression d'avoir trouvé un principe qui peut tenir la route
(vous me direz ce que vous en pensez ...), après, c'est pas tout ça i l
me restera à mettre au point l'implémentation, dans l'esprit d'une
adaptation aisée pour que les changements soit fréquents.

Bon, je crois que tu as raison. Je garde dans un coin mon projet de
programme de stockage de clefs de cryptage (pour ... encore un certain
temps peut-être bien), mais avant, je vais commencer par bien potasser
les pages de doc de développement consacrées à la sécurité, il y a de
quoi faire.

Si Microsoft a mauvaise réputation en matière de sécurité, c'est bien en
raison de l'abondance de la matière à étudier, et du fait aussi que
d'une façon générale le client attend un programme qui remplisse le s
fonctionnalités qu'il a demandées, et la sécurité c'est très ra re qu'il
l'audite. Enfin je veux dire, vu du côté développeur, c'est plus
motivant de passer du temps sur ce qui est susceptible de couvrir les
fonctionnalités demandées par l'utilisateur.

Pour ce qui est de limiter la taille de saisie dans un champ par
exemple, il y a des cas où c'est réalisé par la plateforme, d'autre s où
c'est de la responsabilité du développeur de l'application, et ... ce
n'est pas ce qu'on teste en premier.

Gloops , dans le message <khtdrv$3mm$1@nntp.pasdenom.info>, a écrit :

Bon alors finalement, la solution pourrait être un logiciel maison qui
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 reconnu.

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 données ?

3. Contre quel genre d'attaques souhaites-tu les protéger ?

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'assurer
qu'une transmission s'est correctement passée.

MD5, c'est une fonction de hachage. Une fonction de hachage cryptographique
correcte, ça a les propriétés suivantes :

1. Ça prend en entrée un fichier de taille quelconque.

2. Ça renvoie une donnée de taille raisonnable (fixe).

3. La connaissance du résultat ne t'apprend rien d'intéressant sur la donnée
initiale : ni sa taille, ni ses premiers caractères, ni, etc.

4. Étant donnée un résultat, il est impossible de reconstruire un fichier
qui donnerait ce résultat (c'est ce qu'on appelle une préimage).

5. Il est impossible de construire deux fichiers qui ont la même image
(c'est ce qu'on appelle une collision).

Je précise un peu le 5 : il est trivial de constater que, puisque le
résultat est plus petit que le fichier de départ, il y a forcément plusieurs
fichiers qui donnent le même résultat. Le point important, c'est qu'on n'en
connaisse pas.

De plus, toute fonction de hachage est vulnérable à une attaque par force
brute : si le résultat fait 128 bits, dès lors qu'on essaie plus de 2^127
entrées, on commence à avoir une probabilité importante de tomber sur le
résultat cherché (préimage). Pour des collisions, le paradoxe des
anniversaires intervient, il suffit de 2^64 entrées (la racine carrée) pour
que la probabilité monte. Heureusement, 2^64, ça reste énorme.

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 gentil,
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 une
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 cryptographique H,
et que tu peux vérifier que H(a) = H(b), alors tu peux déduire que, à part
gros coup de malchance, a = b. À partir de là, toutes les applications
auxquelles tu peux penser sont possibles.

Stéphane Catteau , dans le message <mn.74bd7dd3606e690c.30736@sc4x.org>,
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 compte sur
un site plus important.

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.

Stéphane Catteau , dans le message <mn.74de7dd339c70746.30736@sc4x.org>,
a écrit :

Même chose. En fait on regarde le problème avec chacun d'un point de
vue trop différent pour arriver à s'accorder. Alors qu'au final je suis
convaincu que l'on pense pareil.

C'est probable.

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 pense que la meilleure comparaison est de dire
que le hachage est une fonction de chiffrement dont on n'a pas la clef de
déchiffrement.

Le nombre de bits, ça joue sur les attaques en force brute, et c'est valable
aussi bien pour du hachage que pour du chiffrement (asymétrique).

Dictionnaire qui fonctionne en partie parce qu'il y a collision.

Dans le cas d'un mot de passe en clair, il faut qu'il soit dans le
dictionnaire pour être trouvé. Dès que tu sors des sentiers battus, tu
augmente largement la robustesse de ton mot de passe. "stephane" est un
mot de passe très fragile face à un dictionnaire, "stéphane" resistera
à tout ceux qui oublient qu'il existe des accents et "stép0hane"
resistera à quasiment tous les dictionnaires possibles.
Mais il en va autrement dans le cas d'un hash MD5, parce qu'il y a
possibilité de collision et que cette possibilité est finalement bien
plus grande qu'on ne le pensait.

Je sais que ce n'est qu'un exemple, mais franchement, sur dix chaînes
au hasard pouvant correspondrent à un mot de passe, arriver à trouver
quatre collisions, ça ne te semble pas énorme ? Et je parle bien de
collisions, de tous les essais que j'ai pu faire, aujourd'hui et avant,
jamais je ne suis tombé sur une chaîne qui correspondait à celle que
j'avais utilisée pour générer le hash.
Mais bon, j'avoue que j'excluais d'entré les chaînes les plus
élémentaires. Les milles mots les plus utilisés en anglais, par
exemple, doivent être présent dans tous les dictionnaires visant MD5 et
en fait n'importe quel algorithme de hachage. Même chose pour les
prénoms et probablement le contenu des dictionnaires utilisés pour les
mots de passe en clair.

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

L'ensemble de ce que tu sembles dire semble en contradiction avec ce que je
sais de MD5, et je me tiens assez au courant de l'actualité de ce côté-là.
J'aimerais bien que tu clarifies ce que tu disais.

C'est justement pour cela que ma confiance en MD5 a baissé et pour
cela que j'accuse les collisions. Un mot de passe qui resisterait à un
dictionnaire s'il était en clair, devient soudain plus vulnérable parce
qu'il est stocké sous forme d'un hash MD5 (sans grain de sel
évidement), tout cela parce qu'il y a au final un trop grand risque de
collision.

MD5 est cassé, tout le monde est d'accord là-dessus, et il vaut mieux ne
plus l'utiliser puisque de toutes façons on a déjà mieux depuis longtemps.
Mais les attaques qui font que MD5 est cassé sont nettement plus subtiles
que juste un mot de passe qui tombe sur le même MD5 que celui stocké pour un
utilisateur.

D'ailleurs, à ma connaissance, on ne connaît que des collisions
« jumelle » : on a fabriqué en même temps a et b pour que MD5(a) = MD5(b).
On ne connaît aucune chaîne b qui ait le même MD5 qu'une chaîne a si a n'a
pas été fabriqué exprès.