À propos de libmcrypt et php-mcrypt
+
Par Remi le mardi 7 juillet 2015, 13:41 - HowTo - Lien permanent
Je ne compte plus les fois où j'ai du expliquer pourquoi utiliser cette bibliothèque ou cette extension est une grave erreur. Il est donc temps d'en faire un article.
libmcrypt est un projet mort, non maintenu depuis plus de 8 ans, la dernière version 2.5.8 a été publiée en février 2007 !... et malgré les nombreux tickets ouverts, aucune activité.
La cryptographie est un élément essentiel de la gestion de la sécurité. Si on regarde en arrière, les failles découvertes et corrigées dans divers logiciels, la nécessite d'augmenter les standards de sécurités et d'abandonner les vieux algorithmes, comment peut-on imaginer utiliser une vieillerie de plus de 8 ans ?
Il existe plusieurs bibliothèques alternatives bien maintenues :
Et, pour PHP, plusieurs autres solutions sont disponibles:
- la fonction crypt, hachage à sens unique
- l'extension openssl
- les fonctions de hachage de mot de passe, depuis PHP 5.5 ou leur implémentation en PHP password_compat
- les classes phpseclib implémentées en PHP, qui peuvent profiter des extensions intallées.
Une RFC a été proposée pour retirer l'extension mcrypt de PHP 7, mais, honte à nous, elle n'a pas été acceptée (15-18), elle restera donc disponible.
L'oeuf ou la poule ? L'extension est utilisée car elle est disponible, et elle est conservée parce qu'elle est utilisée.
Nous devons vraiment communiquer sur ce problème, et c'est ce que nous faisons déjà depuis longtemps chez Fedora, la plupart des projets comprennent le problème et acceptent de le corriger en basculant sur une implémentation plus sécurisées, quelques exemples :
- phpMyAdmin utilise phpseclib.
- roundcubemail a basculé sur l'utilisation de openssl par defaut, voir rcube.php
- CakePHP est informé, voir ticket #5440, et la PR #5496 a été intégrée dans la version 3.0
- Laravel est aussi informé, voir ticket #9020, et la PR #9041 a été intégrée dans la version 5.1
- etc
Certain framework continuent de proposer une interface pour utiliser mcrypt (ex Zend\Crypt\Symmetric\MCrypt, ticket #3), encore une fois, c'est l'oeuf ou la poule,les applications utilisent cette fonction parce qu'elle existe.
Ceci explique pourquoi certaines distributions linux professionnelles, comme RHEL, ne fournissent ni libmcrypt ni php-mcrypt. On devrait sans doute en discuter avec les autres distributions Linux (Debian, Fedora...) pour arrêter de fournir cette bibliothèque.
Utilisez vous mcrypt ? Comprenez vous que vous DEVEZ basculer dès que possible ? ou, au moins, rapporter ce problème au fournisseur des logiciels que vous utilisez.
Commentaires
Je viens juste d'ouvrir la PR #23 pour tcpdf.
Je comptais justement utiliser mcrypt et AES via PHP pour stocker des données sensibles.
La communauté à l'air unanime sur le fait qu'AES est un des algos les plus blindés, du coup j'ai du mal à comprendre ce que ça change d'utiliser cette librairie ou une autre. C'est le même algo qui est utilisé dans tous les cas, non ?
- Y a t'il des failles importantes dues au manque de mises à jour ?
- Pour du chiffrement (pas à sens unique), vaut mieux partir sur openssl ou nss du coup ?
- Apparement phpseclib utilise mcrypt aussi, " For purposes of speed, mcrypt is used if it's available"
@Anon; openssl gère parfaitement l'AES. mcrypt est mort. RIP.
Oui, phpseclib "peut" utiliser mcrypt, en dernier recours, peut s'en passer, mais préfère en général openssl.
SI on considère que mcrypt est vraiment non-sécurisé, alors ça reste problématique désolé… Par exemple dans les navigateurs, la politique pour avoir une bonne note de sécurité est de désactiver complètement RC4.
@Def: Oui, donc il ne faut pas l'installer.
@Anon : un petit article qui explique pourquoi ne pas utiliser mcrypt d'autant plus avec AES : https://paragonie.com/blog/2015/05/...
Je n'étais pas au courant que mcrypt était baser sur une librairie non maintenu.
Du coup je vais voir si on peu migrer de librairie sans perte de donnée.
Si je comprend bien le problème, c'est surtout que avec mcrypt on peux facilement utilisé des option mauvaise pour la sécurité. C'est bien cela?
Et au sujet de openSSL c'est moi ou il y a presque tout les mois des problème de sécurité critique découverte, qu'elles sont les implication pour openSSL dans PHP?
> Si je comprend bien le problème, c'est surtout que avec mcrypt on peux facilement utilisé des option mauvaise pour la sécurité. C'est bien cela?
C'est surtout que si une faille est découverte elle ne sera jamais corrigée.
> Et au sujet de openSSL c'est moi ou il y a presque tout les mois des problème de sécurité critique découverte, qu'elles sont les implication pour openSSL dans PHP?
Oui, ces failles sont la preuve que les bibliothèques de cryptographie sont très sensibles, ces corrections sont la preuves que le projet est vivant. Mais OpenSSL est plus critique car utilisée dans le cryptage des communications client/serveur (https et consort). Pour PHP, les paquets utilisent la bibliothèque openssl qui sont maintenus, donc pas de soucis sur une distriburion correctement maintenue.
TCPDF version 6.2.10 n'utilise plus mcrypt :)
PHP RFC: Deprecate (then Remove) Mcrypt a été acceptée, donc mcrypt sera dépréciée à partir de PHP 7.1.