Discussion :

[Olivier Famien]

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

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

[Tsilefy]

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

[jopopmk]

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

[Tsilefy]

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

Essentiellement un API plus simple. Pour pouvoir utiliser OpenSSL de manière sécurisée, il faut comprendre la signification de toutes ses options. J'ai vu trop de mauvais exemples ici ou ailleurs, où on voit clairement que le dévelopeur n'a aucune idée de ce qu'il fait mais s'est contenté de piquer un code sur Stack Overflow, et l'a utilisé (et pire, le recommande) en faisant l'équivalent du "je ferme les yeux et j'espère que ça passe". Cette approche marche peut-être pour d'autres chose, mais pas en sécurité.

Libsodium propose des fonctions simples à comprendre et utiliser pour générer des nombres aléatoires, chiffrer avec une clé ou un certificat, hasher un mot de passe, etc...

Cette simplicité évite de se tirer une balle dans les pieds en modifiant des paramètres qu'on ne maîtrise pas.

Pour ceux qui lisent l'anglais, je conseille très fortement le blog de Paragonie/Scott Arciszewski, pour tous ceux qui désirent s'informer sur la sécurité sous PHP et la cryptographie en particulier.

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

[Tsilefy]

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.

[grunk]

D'un autre coté ca imposerait l'utilisation de PHP 7.2 pour tous les WP. Donc autant dire que c'est pas près d'avoir un impact quelconque sur la sécurité de WP dans les années à venir (y'a qu'à voir le taux d'utilisation de php 7).
D'autant plus que rien n'impose à WP d'utiliser ces nouvelles fonctionnalités , à moins que tout ce qui est en doublon avec libsodium deviennent déprécié.

C'est une très bonne chose que d'intégrer cette librairie , par contre vendre le truc en disant que ça va sécuriser les CMS c'est un peu borderline.

[jopopmk]

@Tsilefy : merci pour la précision.
Mais du coup on n'y gagne ni en perf ni en fonctionnalité pure, juste en simplicité d'utilisation -ce qui n'est pas rien je l'accorde ?
En C OpenSSL c'est assez bourrin, j'aurais pensé que pour un module PHP ils auraient wrappé ça dans une API plus simple.

[Tsilefy]

D'un autre coté ca imposerait l'utilisation de PHP 7.2 pour tous les WP. Donc autant dire que c'est pas près d'avoir un impact quelconque sur la sécurité de WP dans les années à venir (y'a qu'à voir le taux d'utilisation de php 7).
D'autant plus que rien n'impose à WP d'utiliser ces nouvelles fonctionnalités , à moins que tout ce qui est en doublon avec libsodium deviennent déprécié.

C'est une très bonne chose que d'intégrer cette librairie , par contre vendre le truc en disant que ça va sécuriser les CMS c'est un peu borderline.

WP et les autres CMS qui le veulent auront la bibliothèque PHP pur sodium_compat pour ceux qui n'auront pas PHP 7.2, tout comme WP a déjà random_compat pour les PRNGs, tout comme certains utilisent password_compat pour password_hash

[grunk]

Mouais , utiliser sodium_compat ca revient à utiliser la crypto de de PHP. On va certes retrouver les même fonction que libsodium mais qu'est ce qui garantie qu'elle sont implémentées correctement ?
Il semblerait que l'auteur veulent la faire auditer mais d'ici là rien ne garantie qu'on puisse lui faire confiance plus qu'un autre code.

En gros ca revient à changer la crypto actuelle par une faite par quelqu'un d'autre. Donc potentiellement autant de risque de mauvaise utilisation et en plus on maîtrise plus le code.

[SurferIX]

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

Vraiment, vraiment du grand n'importe quoi...

https://pypi.python.org/pypi/pysodium

Ca fait déjà 8 mois que c'est disponible pour Python...... donc accessible sur Django / Python.... donc en service Web...

[Tsilefy]

Vraiment, vraiment du grand n'importe quoi...

https://pypi.python.org/pypi/pysodium

Ca fait déjà 8 mois que c'est disponible pour Python...... donc accessible sur Django / Python.... donc en service Web...

L'article parle d'une intégration dans le core, pas dans un module externe.

Si tu veux, comparons ce qui est comparable: package vs package. Le package pecl de libsodium existe depuis 2014. C'est exactement ce même package qui va etre intégré dans PHP 7.2

[SurferIX]

L'article parle d'une intégration dans le core, pas dans un module externe.

Si tu veux, comparons ce qui est comparable: package vs package. Le package pecl de libsodium existe depuis 2014. C'est exactement ce même package qui va etre intégré dans PHP 7.2

Ah bon. Le 06/03/2013. Il y a presque 5 ans de ça. Python avait juste un an d'avance sur pecl/Php. Tu as raison ce n'est pas beaucoup, je m'excuse de ma bourde.

https://umbrella.cisco.com/blog/2013...aphic-library/

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
PYTHON EXAMPLE
Installing the PyNaCl package
$ git clone git@github.com:dstufft/pynacl.git
$ cd pynacl
$ python setup.py install

J'ignore quel est le rapport de performance entre PHP, Python, Java et je pense que sur une appli web, ce n'est pas le point essentiel sachant qu'une requête SQL de trop c'est 500 ms de perdues, aucun framework ne rattrape ça. Je trouve que c'est tout de même une bonne chose d'en améliorer les perfs, si la MAJ ne coûte rien pourquoi refuser le gain de perfs et conso de mémoire à la baisse ?

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

Ne pas autoriser $nom = "Inconnu" transformé en 0 si typecast en entier ? C'est pas normal ce dernier bug.

C'est une fonctionnalité de Php. Je dirais une immondice, ou comme toi, un bogue, mais bon... Allez du troll, j'aime me faire haïr, mais pourtant c'est quelque part constructif, vous saurez qu'un langage haut niveau gère ça proprement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
python3
Python 3.6.3 (default, Oct 25 2017, 17:21:40) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> int("0")
0
>>> int("0.5")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: '0.5'
>>> int("test")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: 'test'
>>>

[rawsrc]

Salut

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 :

[SurferIX]

Tu pousses loin la mauvaise foi dis donc..., je te ferai remarquer que c'est valable pour tous les langages.

En quoi il y a de la mauvaise foi ? Je n'ai jamais dit que c'était spécifique à Php, tu vois le mal partout dis donc....
J'ai juste dit (et c'est valable pour Python, LUA, C#, VB et tous les langages utilisés pour le Web) que le vrai ralentisseur aujourd'hui c'était la base de données...

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.

Faut arrêter la parano.... bien sûr que Php 7 est plus performant que Python ... vraiment bizarre ton comportement.

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

Tu as raison. Mais cela rajoute du code. En Python c'est natif. Pas de code à ajouter, pas de lignes de code qui polluent inutilement les sources. Quoi que tu en dise, Php ne permet pas de développer des sites Web aussi vite et avec une aussi bonne qualité qu'en Python, mais on s'éloigne du début : le seul point que je tenais à souligner c'est que même si on a un langage ultra performant, même si tout est écrit en assembleur, on attendra les retours de la base de données, et on sera limité à la vitesse de la BD, quel que soit le langage Web utilisé : Python, LUA, C#, VB etc. Il n'y avait rien de méchant ni d’agressif dans mon commentaire précédent.

[sabotage]

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.

[JPLAROCHE]

je comprends pas le C le cryptage existe depuis un bon bout de temps alors en quoi PHP est le premier langage ????

[grunk]

PHP est le premier langage à intégrer une librairie de cryptographie sécurisée et facile d'utilisation.
Tu peux évidemment faire de la crypto avec n'importe quelle langage , mais en général pas avec la librairie standard et encore moins facilement.

En gros en C pour faire de l'aes 256 t'es obligé de passer par mcrypt et de te bourrer les vecteurs d'initialisation, les tailles de bloc et tout le bazar. (c'est aussi le cas en php aujourd'hui).
Tu peux te faciliter (un peu) la vie en utilisant openssl , mais ca créer une dépendance externe.

Alors que demain en php on fera juste un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

aes256_encrypt($message,$nonce,$key);

[JPLAROCHE]

PHP est le premier langage à intégrer une librairie de cryptographie sécurisée et facile d'utilisation.
Tu peux évidemment faire de la crypto avec n'importe quelle langage , mais en général pas avec la librairie standard et encore moins facilement.

En gros en C pour faire de l'aes 256 t'es obligé de passer par mcrypt et de te bourrer les vecteurs d'initialisation, les tailles de bloc et tout le bazar. (c'est aussi le cas en php aujourd'hui).
Tu peux te faciliter (un peu) la vie en utilisant openssl , mais ca créer une dépendance externe.

Alors que demain en php on fera juste un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

aes256_encrypt($message,$nonce,$key);

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

mcrypt est fait pour un public très large et mcrypt4 est corrigé des défauts et amélioré beaucoup, quand je vais sur l'utilisation (doc ) beaucoup sont donné avec des exemples PHP et C ou JAVA

sache que je ne suis pas contre PHP . mais pour PHP sera le top quand il y aura un exécutable (résultant) protégeant des intrusions interne..et la rapidité sur de grosse application... (je ne parle pas d'attaque ect...) mais les sources d'un coté et les exécutables de l'autre.
sinon depuis le commencement php2(mon commencement juste après php1) et aujourd'hui quel belle evolution...

[grunk]

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