Bonjour à tous,
probablement depuis la mise à jour de PHP, la méthode donnée si dessous ne fonctionne plus et introduit une vulnérabilité grave : un attaquant peut se loguer uniquement avec le login (tout les mots de passe sont acceptés). Le problème est du à une mauvaise utilisation des double-quote mais n'existait pas quand j'ai rédigé ce post.

Plus ennuyeux, le code avec les caractère correctement échappé ne fonctionne pas non plus:

$conf['pass_convert'] = create_function('$s', 'return crypt($s, \'$2a$12$T9sWUQ03RRG6oSwtDvJtyn$\');');

Alors qu'il fonctionne très bien en console:

<?php
$lol=create_function('$s', 'return crypt($s, \'$2a$12$T9sWUQ03RRG6oSwtDvJtyn$\');');
echo $lol('prout')."\n";
echo crypt('prout', '$2a$12$T9sWUQ03RRG6oSwtDvJtyn$');
?>
$2a$12$T9sWUQ03RRG6oSwtDvJtyeVMo73pP8Ry0HCUsIFidDkIrW/oUtp3q
$2a$12$T9sWUQ03RRG6oSwtDvJtyeVMo73pP8Ry0HCUsIFidDkIrW/oUtp3q

PS: Woula! En dumpant la BDD je me rend compte que la solution n'a jamais fonctionné! Et je suis incapable de dire pourquoi!

PS2: J'ai finalement trouvé ; c'est la taille du champ password qui cause problème!

DESCRIBE piwigo_users;
+--------------+--------------+------+-----+---------+----------------+
| Field        | Type         | Null | Key | Default | Extra          |
+--------------+--------------+------+-----+---------+----------------+
| id           | smallint(5)  | NO   | PRI | NULL    | auto_increment |
| username     | varchar(100) | NO   | UNI |         |                |
| password     | varchar(32)  | YES  |     | NULL    |                |
| mail_address | varchar(255) | YES  |     | NULL    |                |
+--------------+--------------+------+-----+---------+----------------+

En cherchant de la doc, j'ai aussi découvert que md5, sha1 ou même sha512 sont des fonctions de hashage qui ne doivent pas être utilisées pour chiffrer des mots de passe! Car si elle empêche de trouver un pass depuis son hash, seules, elles n'empêchent pas une attaque par bruteforce (car elles sont très rapides à calculer). C'est d'ailleurs pour cela que PHP propose hash() et crypt(). hash() est le hashage normal, crypt effectue le même hashage... 5000 fois de suite.

Bref, j'ai trouvé et corrigé mon problème. J'enlève l'ALERT et je corrige le premier post.

flop25 a écrit:

Oui tout à fait.
Mais le problème est la retro compatibilité

Justement, j'ai pensé à un truc...

Pour regénérer les mots de passe, il faut qu'on ait le mot de passe en clair. Il n'y a qu'un seul moment où Piwigo a ce mot de passe en clair : lors de l'identification. On pourrait, au moment de l'identification, mettre à jour le hash du mot de passe en base.

Ensuite comment différencier un mot de passe qui a déjà été mis à jour et un mot de passe encore en MD5 ? Avec la longueur de la chaîne hashée. Un mot de passe hashé en MD5 fait 32 charactères (0-9a-f). Selon l'algorithme choisi, un mot de passe hashé fera davantage.

Je n'ai pas poussé l'étude, mais il faut choisir l'algorithme de hashage judicieusement car certains nécessitent une version récente de PHP (comme $2x$ ou $2y$ proposés ci-dessus, qui nécessitent PHP 5.3.7 !). L'autre point important, c'est qu'il faut que l'algo retourne le même résultat quelque soit la machine sur laquelle il est exécuté : on doit pouvoir déménager son Piwigo facilement d'un hébergeur à l'autre sans devoir réinitialiser tous les mots de passe.

si je ne me trompe pas on a $conf['secret_key'] qui est généré à l'installation, on peut aussi l'utiliser comme sel (ça permet d'être sur d'avoir un truc aléatoire)

Merci
j'y ai pensé aussi mais le problème est la maj ! Il faut renvoyer un mail à tous les utilisateurs ou mettre une procédure de maj du mpd à la connexion : dans les deux cas il faut garder une trace de l'identification d'avant
Mais n'hésitez pas à créer un ticket Mantis et à continuer à aider ;) http://piwigo.org/bugs/