Discussion :

[Gordon Fowler]

Un serveur de la Fondation Apache victime d'une attaque
Des mots de passe utilisateurs auraient été dérobés

Des Hackers ont réussi à s'introduire dans un serveur que la Apache Software Foundation utilise pour le reporting des bugs de ses produits.

Philip Gollucci, vice président des infrastructures chez Apache, rassure la communauté des développeurs "aucun code source n'a pu être affecté, en aucune manière".

Les pirates, qui ne sont pas encore identifiés, auraient réussi leur intrusion dès le 6 avril en utilisant la méthode dite de "cross-site scripting". Ils auraient ensuite commencé à dérober des mots de passe et des identifiants d'utilisateurs à partir du 9.

Néanmoins, souligne la Fondation Apache, ces mots de passe ne seraient exploitables que si les développeurs les utilisent également pour accéder aux systèmes de contrôle de leur source.

En aout dernier, un autre serveur, nommé Minotaur, avait également été victime d'attaque qui avait permis à des tiers de faire tourner leurs scripts sur le site officiel de la Fondation.

Source : L'annonce sur le blog officiel de la Fondation

Et vous ?

Après ces deux attaques réussies, les serveurs de la Fondation Apache vous semblent-ils assez sécurisés ? Ou s'agit-il de deux désagréments que n'importe quelle société connait ?

[dams78]

Je me suis dit : non ce n'est pas possible Apache ne peut pas stocker les mots de passe en clair... J'ai parcouru du coup vite fait l'annonce officielle et il semblerait que ce soient bien des hash qui ont été dérobés et que seuls les mots de passe un peu trop triviaux peuvent être décryptés.
Je me trompe?

[Marco46]

Il existe maintenant des dictionnaires de hash.

Tu rentres le hash et ça te sort le mot correspondant.

Bref, stocker les hashs sans salt ou boucle de hashage n'est plus sécure dès lors que le pirate peut faire un export de la BDD pour la bourriner en local.

[gorgonite]

Bref, stocker les hashs sans salt ou boucle de hashage n'est plus sécure dès lors que le pirate peut faire un export de la BDD pour la bourriner en local.

Et que l'utilisateur utilise un mot de passe pas assez long et/ou contenu dans un dictionnaire... et il y a moyen de l'interdire en amont

[Zeusviper]

Je me suis dit : non ce n'est pas possible Apache ne peut pas stocker les mots de passe en claire... J'ai parcourue du coup vite fait l'annonce officielle et il semblerait que ce soient bien des hash qui ont été dérobés et que seuls les mots de passe un peu trop triviaux peuvent être décryptés.
Je me trompe?

C'est tout à fait ça. Dans le doute mieux vaut le changer quand même.
Le problème de ces vols de mdp, c'est surtout pour ailleurs. Peu utilisent des couples login/password différents sur chaque site. Ceux volés sur l'un seront ainsi testés sur d'autres...

Sinon, un grand bravo à la communication d'Apache est vraiment stylée! Rare sont les sites à reconnaitre les piratages et surtout à détailler la procédure et les erreurs d'administration qui ont menées au piratage.

[bugsan]

Ou ne plus utiliser md5

Pour info il existe des outils de brute force MD5 utilisant les GPU de carte graphique. Ca peut monter à plus d'un milliard de hash par seconde... ce qui rend accessible des mots de passe de 9 ou 10 caractères.

Cadeau : http://3.14.by/en/md5

[RapotOR]

Ou stocker une version modifiée du password (md5,sha1,...).

Il y a moyen d'agir sur le password ou/et meme le hash généré.

Sur le password; vous pouvez y ajouter une date d'inscription; une répétition du password; une chaine fixe; etc... libre à votre imagination.

Ensuite, vous pouvez aussi modifier le hash généré avant le stockage. Changer les caractères de place; changer une partie; enlever une partie; etc...

je ne prétends pas avoir LA solution mais cela donne toujours plus de fil à retordre.

Ces solutions ne sont valables que si le code n'est pas opensource,ou si ces configurations sont des paramètres.

[Invité]

Le défaut du hash est qu'il n'est pas unique pour chaque entrée, donc même si ton entrée est très compliquée, on pourra peut-être trouver un mot de passe simple dont le hash a la même valeur.

[berceker united]

Le défaut du hash est qu'il n'est pas unique pour chaque entrée, donc même si ton entrée est très compliquée, on pourra peut-être trouver un mot de passe simple dont le hash a la même valeur.

Exacte, en fait, c'est juste une question de rapport temps/puissance pour trouver le mot de passe.

[Marco46]

Le défaut du hash est qu'il n'est pas unique pour chaque entrée, donc même si ton entrée est très compliquée, on pourra peut-être trouver un mot de passe simple dont le hash a la même valeur.

Euh ... Le principe du hash c'est d'être une empreinte unique. Si deux valeurs différentes ont un même hash et bien c'est une faille dans l'algorithme.

Ou alors je comprends mal ce que tu veux dire.

Ou stocker une version modifiée du password (md5,sha1,...).

Il y a moyen d'agir sur le password ou/et meme le hash généré.

Sur le password; vous pouvez y ajouter une date d'inscription; une répétition du password; une chaine fixe; etc... libre à votre imagination.

Ensuite, vous pouvez aussi modifier le hash généré avant le stockage. Changer les caractères de place; changer une partie; enlever une partie; etc...

je ne prétends pas avoir LA solution mais cela donne toujours plus de fil à retordre.

Ces solutions ne sont valables que si le code n'est pas opensource,ou si ces configurations sont des paramètres.

Ça s'appelle un salt. Et on peut très bien utiliser une valeur dynamique pour le salt, comme le login, ça n'a rien avoir avec une différenciation opensource/propriétaire.

Ça peut se combiner avec un hash récursif. C'est à dire hasher le même mot de passer des milliers de fois ce qui entraine un petit "lag" d'une seconde ou deux pour l'utilisateur mais qui complique considérablement le cassage du hash et empêche de fait la recherche par dictionnaire.

[pseudocode]

Euh ... Le principe du hash c'est d'être une empreinte unique. Si deux valeurs différentes ont un même hash et bien c'est une faille dans l'algorithme.

Non. C'est une signature de longueur fixe.

Par exemple, MD5 = 128 bits, c'est a dire 2^128 valeurs possibles.

Vu qu'on peut créer une infinité de mots de passe différents et calculer le hash de chacun, il y a donc forcément des mots de passe avec le meme hash.

[Invité]

Euh ... Le principe du hash c'est d'être une empreinte unique. Si deux valeurs différentes ont un même hash et bien c'est une faille dans l'algorithme.

Ou alors je comprends mal ce que tu veux dire.

Mais il ne faut pas oublier que des experts ont montré il y a un moment qu'il existait des collisions avec le hash MD5. Donc MD5("toto") peut tres bien valoir le MD5 de ton password de 32 caractères.

[cahnory]

Et bien comme l'a dit pseudocode ce n'est pas spécifique à md5 mais à tout algorithme de hashage à longueur fixe (est-ce le cas de tous ça je n'en sais rien ). Si le nombre de possibilité est fini on ne peut pas avoir une réponse unique pour une infinité de possibilité.

Grosso modo et pour prendre un exemple poussé à fond, si je crée un algorithme qui me donne des hash à 1 char ou chaque char ne peut être que 1 ou 0 je n'aurai que deux hash possibles : 1 et 0. Donc des trois hashage j'aurai forcément deux résultats identiques. Parcontre si mon nombre de char n'est pas limité même avec seulement des 1 et des 0 (ce qui ne serait tout de même pas très judicieux ) je pourrai (si mon algorithme est bien foutu) avoir autant de hash que de valeur à hasher possible (une infinité donc).
Pas besoin d'expert pour arriver à cette conclusion.

[goomazio]

Ça s'appelle un salt. Et on peut très bien utiliser une valeur dynamique pour le salt, comme le login, ça n'a rien avoir avec une différenciation opensource/propriétaire.

Sauf que mettre les deux derniers caractères de l'identifiant à la suite du mot de passe avant de le crypter ne sert à rien si le pirate le sait. Et il le saura si le code est téléchargeable.

[kedare]

Sauf que mettre les deux derniers caractères de l'identifiant à la suite du mot de passe avant de le crypter ne sert à rien si le pirate le sait. Et il le saura si le code est téléchargeable.

Sauf que le salt change pour chaque mot de passe... ca veux dire qu'il doit tout refaire pour chaque mot de passe... vu que son dictionnaire inversé sera lié a un salt

[goomazio]

Le salage est plus efficace si la méthode est secrète quand même.

[Patriarch24]

Le salage est plus efficace si la méthode est secrète quand même.

En crypto, on sait depuis longtemps que les secrets ne tiennent pas longtemps... C'est justement le fait que les algorithmes soient publics qui fait leur force.

[user25]

La solution au problème de sécurité des bases de données de mots de passe cryptés est d'utiliser un algorithme de cryptage polymorphe.

Avec ça les tables de hashs seront énormèment moins fiables.

Pour ma part je dirais que ce genre de problème peut arriver à n'importe qui.

C'est comme développer une application. Quand on trouve des failles on modifie le code pour les supprimer. Mais qui nous dit que les modifications que l'on a apportées ne contiennent pas de failles ou que l'on a pas rendu les failles existantes plus facilement exploitables ?

C'est la boucle ! Il est très rare de voir des serveurs et des applications totalement sécurisés.