Hachures Bruteforce
Vous pouvez brutaliser le hachage stocké dans la base de données.
WordPress utilise phpass pour le hachage. Par défaut, WordPress n'utilise pas Blowfish ou similaire, mais juste md5 avec un nombre d'itérations de 8192. Si vous voulez juste trouver des mots de passe vraiment mauvais, le bruteforcing est certainement faisable.
Mais je considérerais cela comme une violation assez importante de la confiance que les utilisateurs placent en vous, donc je ne recommanderais pas cette approche.
Analysez leurs mots de passe lors de la connexion
Vous pouvez ajouter un script qui intercepte toutes les demandes aux scripts de connexion WordPress, et enregistrer ou analyser les mots de passe, car ils sont en texte clair à ce stade.
Bien sûr, cela n'attrape les mots de passe faibles qu'une fois qu'un utilisateur se connecte. S'ils ont abandonné leur site ou sont plutôt inactifs, cela peut prendre un certain temps avant que vous découvriez qu'ils utilisent un mot de passe faible.
Je considérerais cela comme une violation encore plus importante que le renforcement brutal des hachages, et cela comporte également des problèmes de sécurité (si vous stockez les mots de passe en texte clair, ce serait évidemment un problème, mais même si ce n'est pas le cas, vous pouvez accidentellement stocker des informations de l'analyse qui peut aider un attaquant).
Mettre en œuvre une politique de mot de passe (et forcer les utilisateurs à changer leurs mots de passe)
Vous pouvez implémenter une politique de mot de passe. Lorsqu'un utilisateur soumet un nouveau mot de passe, vous vérifierez s'il est conforme à votre politique ou non (idéalement, cela se produirait côté serveur, pas côté client via JavaScript).
La rédaction d'une bonne politique de mot de passe est difficile, alors jetez un œil aux politiques existantes pour vous aider ici.
Bien sûr, les anciens mots de passe ne sont pas affectés par la politique, vous devez donc forcer les utilisateurs à modifier leurs anciens mots de passe pour se conformer à la politique
Limiter les dommages
L'application de mots de passe forts peut certainement être une bonne idée, mais idéalement, une instance WordPress piratée ne devrait pas vraiment vous affecter en tant que webmaster.
Vous devriez vouloir limiter les dégâts une fois qu'un attaquant a accédé à une installation WordPress. Idéalement, vous voudriez que seule une instance soit affectée, pas l'ensemble de votre serveur (vous pouvez donc vous inquiéter qu'un attaquant place du contenu indécent sur un site Web - tout comme un utilisateur valide pourrait le faire -, mais pas sur l'exécution de code ou d'autres programmes malveillants activité).
C'est un sujet assez large, mais certains points incluent DISALLOW_FILE_EDIT
:, l'utilisation limitée des plugins (car ils sont beaucoup moins sécurisés que WordPress lui-même), interdire JavaScript (par exemple avec les multisites, seuls les super-administrateurs ont le droit de publier JavaScript, pas admins), etc.