SecuPress v2.4 aka Midas

Une majeure, la 2.4, seulement 2 mois après la 2.3, ça c’est pas mal, ça fait surtout moins peur que la précédente, le changelog est petit, le risque de voir une 2.4.20 est plus que faible. Voyons voir quelle est cette nouveauté et pourquoi avoir ajouté celle-ci précisément.

SecuPress 2.4

Midas, la Mark XXI de l’armure de Iron Man, elle est spécialisée dans le vol supersonique, un vol ultra rapide, un peu comme la vitesse de sortie de cette majeure…

3 corrections & quelques détails

Seulement 3 corrections très simples :

La première pour éviter d’indexer les URL de SecuPress du type https://example.com/wp-admin/admin-ajax.php?action=secupress_dcts_timer&timer=1765432988

Alors… habituellement ces URLs même en front ne sont pas indexées, WP lui même ajoute via des « localize_script » une variable du genre « ajaxurl », mais bon… allez, je l’enlève, je fais sans, je modifie deux trois trucs et ça passe quand même.

Puis deuxième fix en pro vous avez peut-être rencontré des notifications dupliquées de mise à jour de la base de données des malwares, le message apparait X fois dans la fenêtre, c’est maintenant réglé.

Enfin le dernier fix est que la réinitialisation du mot de passe n’était pas possible pour certains rôles, en raison de l’activation et de la désactivation du module PasswordLess et si le module des mots de passe forts est actif.

Pour les détails, il s’agit de mieux informer sur le fait que le lien vers la page d’un auteur ou autrice sera redirigé vers la page d’accueil du site si le module « Interdire l’énumération des comptes » est actif, c’est une demande cliente, c’est écouté !

Aussi dans le module PasswordLess, si votre rôle est dans la liste des personnes devant utiliser la 2FA, alors la demande de réinitialisation du mot de passe sera interdite, puisqu’inutile.

Enfin une autre demande cliente, le hook de type filtre secupress.get_wp_directory a été ajouté sur notre fonction secupress_get_wp_directory() afin de pouvoir écraser la valeur pour la rendre plus compatible avec BedRock (avec qui nous ne sommes pas spécifiquement compatible justement).

Passons à la chose sérieuse :

Forcer un meilleur système de chiffrement

On parle ici de l’algorithme de chiffrement des mots de passe de WordPress. Même si vous (et même si tout le monde sur votre site) utilisez une 2FA, restez là, car cette fonctionnalité peut quand même empêcher des piratages, suivez bien.

Pourquoi alors ?

Pourquoi vouloir forcer un meilleur système de chiffrement ? J’en reviens à ce que je disais dans l’article de la v2.3 « À chaque fois que je découvre un nouveau type de malware dédié à WP, j’essaie de trouver le moyen de le contrer avec SecuPress. Parfois c’est juste une signature de malware, mais parfois je dois en faire bien plus. », on est dans le cas du « bien plus » ici.

La 2.3 bloque énormément les façons par lesquelles des comptes pourraient être ajoutés, interdisant alors à ces comptes de se connecter. Mais certains malwares sont très malins et s’ils ne peuvent pas créer de comptes… alors pourquoi pas utiliser ceux qui sont déjà présents ! Et c’est là que cette fonctionnalité est intéressante et puissante.

Le meilleur système de chiffrement

Mais comment on sait que c’est un « meilleur » déjà ? Nous avions PHPass avant (utilisant Blowfish) et depuis WP 6.8 nous avons Bcrypt. Bcrypt est déjà meilleur que PHPass, mais Bcrypt commence déjà à dater. Rappelons que Bcrypt est l’algo par défaut depuis PHP 5.5 sorti en juin 2013 (WP 6.8 date de avril 2025, ça fait 12 ans que ça existe…), nous aurions dû l’avoir plus tôt dans WP, en fait, même moi j’aurais dû l’ajouter à SecuPress plus tôt, c’était même dans la TODO, mais voilà, priorités tout ça tout ça.

Mais il y a t-il encore mieux que Bcrypt et en quoi c’est mieux ? Et bien déjà c’est un peu comme dire que « Linux est mieux que Windows » pour la raisons des virus qui sont quasi inexistants sur Linux, si 100% des sites WP à jour utilisent Bcrypt, alors un malware inclura dans son dev des contournements utilisant le Bcrypt et non plus PHPass.

PHPass a des mots de passe commençants par « $P$« , ceux de Bcrypt par « $2y$ » mais WP ajoute son préfixe et cela donne « $WP$2y$« .

On peut alors demander à PHP si on a autre chose ?! Oui on a ARGON2i et ARGON2iD qu’on retrouve dans les choix de la fonction password_hash() voyez la doc php à ce sujet. Et ça commence par « $argon2i$ » et « $argon2id$ » comme par hasard (ou pas).

ARGON2i est mieux car il n’est pas le choix par défaut, rien que pour ça on a bon, mais en vrai, ARGON2i est mieux car il demande plus de ressources pour créer et vérifier un mot de passe. Je rappelle qu’une vitesse élevée est un mauvais point, une faible consommation de mémoire aussi, il FAUT que l’algo coute cher afin d’éviter de pouvoir dépenser peu de ressources seveur pour le découvrir par brute force par exemple. Aussi ARGON2i et surtout 2iD est fait pour résister à des attaques spécifiques. Bon ok, moins de 1% des sites sous WP devraient en avoir véritablement besoin (sauf si vous êtes une institution gouv ou bancaire), mais qui peut le plus, peu le moins.

Faisons le point rapidement

Je vais peut-être vous apprendre quelque chose… 3 choses, 3 points de sécurité sur WordPress que je trouve étranges…

Duplicated Hash

Si vous créer un site WP en local, que vous mettez en mot de passe azerty, que vous prenez son hash, puis vous allez sur un site en ligne, dans sa base de données et vous remplacez le user_pass du compte ciblé par votre attaque par ce hash du site en local, alors vous pourrez vous connecter à ce compte avec le pass azerty sans la moindre suspicion de la part de WP. Car non, les mots de passe de dépendent pas du site où ils sont créés, les clés de sécurité (les « salt keys« ) ne sont pas prises en compte pour la création et vérification des mots de passe (normal car on peut les changer à tout moment, cela rendrait 100% des connexion caduques en 1 seconde). En plus, on ne donne pas de sel à ces nouveaux algorithmes, ils la choisissent eux même pour des raisons de sécurité (on vous voit mettre « foobar » ou « 0 » ou même « time() » pour faire vite…)

Obsolete Hash

Ensuite encore plus « drôle », vous remplacez directement sur le site visé dans sa base de données le user_pass d’un compte par un hash MD5, ou si vous avez déjà opté pour BCrypt ou même ARGON2i vous remplacez par un ancien hash PHPass, vous vous connecterez tout de même, par soucis de rétrocompatibilité. Rétrocompatible avec le MD5 qui a été rendu obsolète en 2005, il y a 20 ans. Qui a besoin d’une sécurité rétrocompatible sur 20 ans en arrière ? Personne, nous sommes bien d’accord.

Collided Hash

Allez encore un « rigolo », vous savez surement qu’un hash est généré aléatoirement et que la probabilité d’en avoir 2 identiques pour 2 mots de passes différents (et même 2 pass identiques en fait) est improbable, même les ordinateurs quantiques actuels de chez Alphabet ne sont pas parvenus à trouver une collision (2 hashs identiques pour 2 chaines différentes), cela se fait en MD5 facilement depuis 2004, et en SHA128 ça se fait depuis 2017.

Mais dans WordPress le champ user_pass permet pourtant d’avoir 2 valeurs identiques, je peux donc me créer un compte client sur un site, légitimement, j’ai donc mon propre hash, avec la bonne méthode de chiffrement, SecuPress a tout validé, je suis bon.

Maintenant l’attaque est simplement de copier/coller mon hash dans celui de l’admin, nous aurons le même hash mais c’est autorisé (et inutile !), je connais donc son mot de passe puisque c’est le mien ! Comme je le disais, le hash des mots de passe ne prends aucune graine/sel en compte, ni du site, ni d’un compte.

Vous ne saviez pas tout ça ? Ça vous choque ? Je l’ai toujours été, voilà pourquoi j’ai décidé d’ajouter 2 options pro à cette nouvelle fonctionnalité pour contrecarrer cela.

Point bonus

Pour votre gouverne, quelques exemples de différents hachages de mots de passe. Je vous laisse les deviner, si vous en avez, twittez les moi @secupress 😉

• En MD5 : ab4f63f9ac65152575886860dde480a1
• ViaPHPass : $P$BkTFWd.sWcyDBj23k46IIAelnm4Axb0
• En BCrypt : $wp$2y$12$VqcTFP4kjCDpUs24F26QsOuXTaEUSYvaIPYMK/0iTqvPWh7gUoKm.
• En ARGON2iD : $argon2id$v=19$m=65536,t=4, p=1$6u1KLDET9M+YjLlucPquCQ$pJfcLxQOKxOMaiDV+tqwJLY81Nha3qt55+fAf1ahw2I

Oui, on y voit carrément des paramètres en clair (sauf MD5 qui a 0 param), le nombre d’itérations, la mémoire utilisée, et même la chaine aléatoire choisie et utilisée par l’algo ! Pourtant, même avec ces infos, vous ne reviendrez pas en arrière sur le mot de passe, c’est irréversible. Tout ce qu’on peut faire, c’est toujours comparer que le mot de passe donné donne bien ce hash avec ces paramètres, et en ARGON2I, c’est couteux et lent, donc c’est bien mieux !

Empêcher la connexion des autres méthodes de chiffrement

Une fois la nouvelle méthode forcée (cela peut rester la même, mais elle sera alors forcée), si un nouveau compte (les anciens peuvent encore le faire 1 fois, le temps qu’ils changent automatiquement de méthode de chiffrement) tente de se connecter, SecuPress détecte si c’est la bonne méthode demandée, sinon il refuse la connexion indiquant que le mot de passe est incorrect, ce qui en soit est vrai, le mot est bon mais pas sa méthode de chiffrement !

Actuellement WordPress laisse passer même un mot de passe en MD5 puis si besoin (là oui, besoin) il chiffre de nouveau cotre mot de passe pour mettre à jour le hash selon la méthode en cours. Cela est désormais interdit avec SecuPress 2.4.

Cela empêche alors TOUS les anciens malwares qui parviennent à modifier/jouer avec une requête SQL manuelle pour ajouter et modifier des comptes. Le blocage est simple et efficace.

Empêcher les hachages de mots de passe d’être réutilisés par d‘autres comptes

Mais comme je le disais, je peux alors aussi copier un hash d’un compte sur un autre. Mais, me direz vous, il suffit d’échanger le hash du compte ciblé avec le mien, comme ça pas de duplication et pourtant mon hash sera bien appliqué au compte attaqué !? Oui, et c’est là où cette fonctionnalité est bonne, car elle va rendre les hashs des mots de passe unique pour un utilisateur sur un site donné. Nous ne pourrez plus prendre le hash d’un site pour le coller sur un autre, ni d’un compte pour le mettre sur un autre. Aussi SecuPress résout le soucis de hash duplicables dans votre base de donnée en créant un INDEX UNIQUE sur le champ user_pass de la table wp_users. Côté performances, occupation sur le disque et mémoire, c’est imperceptible alors que le gain en sécurité est énorme.

À prendre en compte qu’avec cette option là, côté migration de compte entre recette/prod, etc, chaque installation de SecuPress va générer une « master key » qui sera sa propre graine aléatoire et qui ne changera pas, alors que d’un site à un autre elle changera, rendant les mots de passe inutilisables.

Mais pas grand soucis ici, une simple demande de « reset password » et ça repart, ou simplement n’activez pas en recette/dev cette fonctionnalité. L’activer et la désactiver ne permet pas non plus de s’assurer que la migration est fluide car techniquement parlant les mots de passe des comptes sont modifiés à l’insu de leur propriétaire avec une chaine supplémentaire inconnue et humainement illisible, et il faut 1 connexion pour le changer, dans un sens ou dans l’autre.

C’est tout ?!

Oui, dans cette 2.4 c’est tout, la 2.5 est déjà dans les starting-blocks avec une fonctionnalité de géolocalisation lors du login, empêchant ainsi la connexion depuis des lieux inhabituels, avec une granularité réglable de l’IP fixe à la ville et au pays en passant par la région, je vous spoil des captures :

Rendez vous en novembre pour la 2.5beta et une release avant Noël 😉