PHP 7.2 intégrera la bibliothèque de cryptographie Libsodium

Qui fera de ce langage le premier à supporter un outil moderne de ce genre, selon Scott

Le 2017-02-22 18:04:31, par Olivier Famien, Chroniqueur Actualités

Avec plus de 80 % de part de marché, PHP est devenu l’un des langages de programmation les plus utilisés pour la conception des sites web dynamiques et les applications web. En plus de soutenir ces sites web, PHP est également utilisé pour le développement de certains systèmes de gestion de contenu (CMS en anglais), notamment Dupral, Joomla et bien d’autres encore.

Vu la forte communauté d’utilisateurs entourant ce langage de programmation, une déviation ou un bogue au niveau de ce langage aurait de grandes répercussions dans l’environnement web. Conscient de ce fait, l’équipe en charge du développement de PHP vient d’adopter l’intégration de l’extension Libsodium dans le noyau de la version 7.2 de PHP qui doit sortir d’ici la fin de l’année.

Selon Scott Arciszewski, Chef de développement à Paragon Initiative Enterprises et grand défenseur du renforcement de la cryptographie dans les CMS PHP, l’extension Libsodium qui trouvera sa place dans la prochaine version de PHP offre le chiffrement authentifié, le déchiffrement, des performances accrues pour la cryptographie sur les courbes elliptiques, le hachage de mots de passe ainsi que bien d’autres avantages.

Depuis le mois de novembre 2016, Arciszewski a émis une proposition afin d’intégrer l’extension Libsodium également connue sous le nom Sodium dans le noyau de PHP 7.2 dans le but d’améliorer la sécurité de ce langage et par-delà des autres outils bâtis sur ce langage. Après soumission de cette proposition au vote, Arciszewski annonce que la RFC (Request for comments) Libsodium a été adoptée avec trente-sept voix pour et zéro voix contre.

Au-delà de l’intégration de cet outil de sécurité par défaut dans le noyau de PHP, c’est tout l’environnement gravitant autour de ce langage qui en sera affecté. Arciszewski explique que cette décision d’intégrer Libsodium par défaut dans PHP a été motivée par le fait que WordPress, le CMS écrit en PHP, contient de nombreux problèmes de sécurité dus à l’absence d’outils de cryptographie appropriés. Aussi en intégrant cet outil à PHP, cela obligerait l’équipe de CMS à implémenter une meilleure sécurité dans le CMS. Par ailleurs, cela permettra également aux développeurs PHP et des autres CMS d’intégrer des outils avancés de cryptographie dans leurs applications qui sont exécutées sur les fournisseurs d’hébergement mutualisé, ce qui n’était pas possible jusqu’à présent.

En plus des caractéristiques citées plus haut, Arciszewski considère Libsodium comme une bibliothèque de cryptographie moderne, car selon lui, elle remplit les deux critères essentiels à savoir l’usage des primitives rapides conçues pour résister à une cryptanalyse par canal latéral et l’exposition d’une API de haut niveau simple et sécurisée par défaut. Ainsi en intégrant cet outil au noyau de PHP, ce langage devient, selon Arciszewski, le premier langage de programmation à supporter une bibliothèque de cryptographie « ;moderne ;» dans son noyau.

Il ajoute que certains langages comme Go, Ruby, Erlang ou encore Node.js intègrent une pile de sécurité, mais qui ne présente pas de caractéristiques de cryptographie moderne (couche cryptographique et exposition d’API simple et par défaut) telles qu’il le conçoit.

Source : News PHP, Blog Scott Arciszewski

Et vous ?

Que pensez-vous de cette nouvelle fonctionnalité de sécurité qui sera intégrée à PHP ?

Pourra-t-elle changer l’opinion des personnes qui trouvent que PHP n’est pas sécurisé ?

Voir aussi

WordPress est de loin le CMS le plus ciblé par les cyberattaques, en grande partie en raison du mauvais entretien et la négligence des webmasters

WordPress : Plus de 90 000 sites et blogs seraient victimes d'attaques lancées par quatre groupes de hackers altérant ainsi leur contenu

PHP 5.3.9 corrige une faille de sécurité critique pouvant entrainer un déni de service et plus de 90 bogues

La Rubrique PHP, Forum Bibliothèques & Frameworks PHP, Cours et tutoriels PHP, FAQ PHP

Discussion forum

32 commentaires

rawsrc
Expert éminent sénior

Salut

Envoyé par SurferIX

Je suis 100% d'accord avec toi : améliorer les perfs, c'est super, mais le vrai ralentisseur aujourd'hui à notre époque du big data, c'est les données, et le moteur BD. Si tu fais une Ferrari (Php) mais que tu ne peux rouler qu'en campagne (MariaDB,MySQL), au mieux route nationale (PostGreSQL), ça ne sert à rien...

tu pousses loin la mauvaise foi dis donc..., je te ferai remarquer que c'est valable pour tous les langages.
D'ailleurs si tu veux des perfs coté BDD, c'est pas le choix qui manque. PHP s'interface avec à peu près tout ce qui se fait en la matière.
La vélocité de PHP 7+ n'est plus à démontrer (même face à python 3 qui est clairement derrière). Après les problèmes des autres briques logicielles qui se traînent c'est clairement autre chose. Tu ne peux pas faire d'amalgame si grossier.

Pour ce qui est des transtypages exotiques, c'est très bien documenté et au pire tu fais comme moi que des comparaisons strictes avec des casting explicites.
Bref, les raisons de ce comportement remontent à la préhistoire du web à l'époque ou PHP était en version 1.0

Pour finir sur le typage :

Typage strict

Par défaut, PHP va convertir les mauvais types vers le type scalaire attendu tant que possible. Par exemple, une fonction, qui attend comme paramètre un integer (entier), à laquelle est passée une string (chaine de caractères) recevra une variable de type string.

Il est possible d'activer un typage strict fichier par fichier. Dans ce mode, seule une variable du type exact correspondant au type attendu dans la déclaration sera acceptée sinon une exception du type TypeError sera levée. La seule exception à cette règle est qu'un entier (integer) peut être passé à une fonction attendant un nombre flottant (float). Les appels aux fonctions depuis des fonctions internes ne seront pas affectés par la déclaration strict_types.

Pour activer le typage strict, l'expression declare est utilisée avec la déclaration strict_types :

le 08/12/2017 à 10:31
Eric30
Membre actif

Depuis la v7, PHP est en train de supprimer peu à peu les derniers arguments objectifs que l'on pouvait reprocher à ce langage.
Nouveau moteur avec des performances qui n'ont plus rien à envier à Python, typage des variables*, POO moderne... on y arrive!

* Malheureusement pas géré par tous les frameworks avec notamment les classes compilées avant exécution.

le 04/12/2017 à 8:58
sabotage
Modérateur

Ce n'est tout de même pas compliqué d'intégrer que PHP est un langage faiblement typé avec tout ce qui en découle.

le 08/12/2017 à 10:34
Tsilefy
Membre émérite

Envoyé par bilbot

Je vois pas en quoi cette librairie va faire que Wordpress sera mieux sécurisé. Pour moi, les problèmes de sécurité de WP sont plus lié à la conception, qu'a des manques de fonctions de cryptographie. A l'heure actuelle il y a déjà des outils de chiffrement de mot de passe qui existent et qui sont performants.

- Libsodium ne se limite pas aux mots de passe (qui ne ne doivent pas être chiffrés, mais hashés). Les mots de passe ont d'ailleurs déjà les fonctions de la famille password_hash()

- Jusqu'à l'année dernière, le générateur de nombres pseudo-aléatoires de Wordpress n'était pas si aléatoire que ça (or il est utilisé dans les cookies par exemple, ce qui veut dire qu'il était possible de générer un faux cookie avec les risques que cela entraîne)

- Depuis un ou deux ans, Wordpress peut faire une mise à jour automatique. Imagine le problème si un hostile venait à s'interposer entre les serveurs de WordPress et le reste du monde, ou à prendre le contrôle des serveurs de WordPress: il pourrait installer ce qu'il veut sur plus d'un quart des sites. Pour sécuriser cette mise à jour, il faut un système d'authentification des mises à jour, qui repose sur une cryptographie sûre (qui n'existe pas dans Wordpress)

- À ma connaissance, WordPress n'a pas de fonctions de cryptographie, ce qui force les auteurs de plugins désireux de chiffrer les données (ex: données personnelles des clients dans une base de données) à écrire leur propre crypto, avec tous les risques que cela implique. Maintenant, ils vont pouvoir utiliser libsodium parce qu'ils savent que la bibliothèque sera toujours présente.

le 23/02/2017 à 12:37
grunk
Modérateur

Envoyé par JPLAROCHE

rien ne t’empêche de faire une class une lib ou une fonction et d'utiliser cela plus simplement

Si , mes compétences en cryptographie.
Aujourd'hui combien de développeur on les connaissances nécessaires pour utiliser des lib comme mcrypt ou openssl sans faire d'erreur et sans copier betement un exemple trouvé sur internet ?
Faire quelque chose qui marche , on sais tous le faire. Mais en garantir la robustesse , rien n'est moins sur

le 15/03/2017 à 8:43
rawsrc
Expert éminent sénior

@Eric30
C'est clair qu'au fil des versions PHP s'est grandement bonifié. Avec l'avènement de la version 7, on a carrément basculé dans une autre dimension : typage, sucres syntaxiques bien à propos, des performances à tomber à la renverse, une POO solide. Bref, je dois t'avouer que depuis que j'ai goûté à la version 7+, j'ai beaucoup de mal à revenir sur des scripts anciens version 5.6-.
Dans les entreprises, c'est pareil. PHP est en train de revenir en odeur de sainteté. Vu que le langage s'est rigidifié, il est devenu plus difficile de faire du code sale (bon, c'est toujours possible, je te rassure, mais si tu te donnes les moyens d'utiliser les nouveautés de PHP 7+, c'est presque mission impossible). Tous les échos sont vraiment supers positifs.

Le support natif de la bibliothèque de sécurité Sodium par le moteur v 7.2 est carrément une "killer feature".

Go PHP

PS : La prochaine version majeure 8.0 devrait intégrer une moteur JIT, là, en terme de perfs, ça devrait être le nirvana et laisser les autres accessoirement à la traîne

le 04/12/2017 à 12:52
Vadrygar
Membre habitué

Pendant ce temps je suis bloqué en PHP5.5.

Tristesse et desespoir :'(

le 05/12/2017 à 10:28
Aizen64
Membre confirmé
Pour revenir sur les différents commentaires :

@rawsrc : c'est pas parce que la conversion de type est documentée qu'elle n'est pas un bug donc non je ne suis pas d'accord. Sur le typage optionnel en PHP, c'est un peu mi figue mi raisin selon moi. Il me semble de declare(scrict_types=1) fait à moitié le travail.

Pourquoi ne pas autoriser de typer toutes les variables ?
Code :
```
1
2
3
4
5
6
7
8
<?php

int unEntier = 1;
string uneChaine = "un truc";

uneChaine.length; // merde c'est plus court que strlen( $uneChaine ):
?>
```
Une fois de plus, les perfs ne sont pas forcément l'essentiel, du SQL exécuté pour rien c'est 500 ms de perdues soit bien plus que l'impact d'un framework, cela dit, je trouve très intéressant d'avoir de gros gains de perfs entre version. Pourquoi ? Si tu ne traines pas de code déprécié, l'upgrade de PHP ou un autre langage c'est gratuit donc autant en profiter.

Aujourd'hui, j'ai du mal à comprendre pourquoi Ruby par exemple a des perfs aussi mauvaises, c'est tous des dérivés du C non ?

Quand aux débats de langages, tous les gros framework font un peu la même chose, c'est surtout une question de "goût" sur la langage et de structure de code pour la maintenabilité d'une app.

Sur les frameworks, ils ne sont pas forcément indispensables pour la création de petits outils par exemple et même certains outils minimalistes (Slim 3) peuvent très bien faire l'affaire.
le 16/12/2017 à 11:59
Tsilefy
Membre émérite

Il était temps! Et pour tous ceux qui veulent en profiter sans attendre et qui ne peuvent pas installer l'extension libsodium, il y a la librairie paragonie/sodium_compat qui fonctionne sur PHP 5.2.4 et plus. Le code est encore sous audit, mais ça sera toujours mille fois mieux qu'écrire soi-même sa propre crypto (sauf si vous êtes un expert en crypto!).

le 22/02/2017 à 20:45
jopopmk
Membre expert

Je préviens je connais à peine le PHP.
Ma petit question : au niveau chiffrement, qu'offre libsodium qu'openssl n'a pas ?

le 23/02/2017 à 7:52

Poster une réponse