Bruteforceハッシュ
データベースに格納されているハッシュをブルートフォースにすることができます。
WordPressはハッシュにphpassを使用します。デフォルトでは、WordPressはブローフィッシュなどを使用せず、反復回数8192のmd5のみを使用します。本当に悪いパスワードを見つけたいだけであれば、ブルートフォーシングは確かに可能です。
しかし、これはユーザーがあなたに与えた信頼に対するかなり大きな違反だと思うので、このアプローチはお勧めしません。
ログイン時にパスワードを分析する
WordPressログインスクリプトへのすべてのリクエストをインターセプトするスクリプトを追加し、その時点ではプレーンテキストであるため、パスワードをログに記録または分析することができます。
もちろん、これはユーザーが実際にログインしたときにのみ弱いパスワードをキャッチします。ユーザーがサイトを放棄したか、または非アクティブな場合、弱いパスワードを使用していることを発見するまでに時間がかかる場合があります。
私はこれをハッシュの総当たりよりもはるかに大きな違反と見なし、それにはセキュリティ上の懸念も伴います(パスワードをプレーンテキストで保存する場合、これは明らかに問題になりますが、そうでない場合でも、誤って攻撃者を助けるかもしれない分析)。
パスワードポリシーを実装する(ユーザーにパスワードの変更を強制する)
パスワードポリシーを実装できます。ユーザーが新しいパスワードを送信するとき、それがポリシーに準拠しているかどうかを確認します(理想的には、JavaScriptを介してクライアント側ではなくサーバー側で発生します)。
適切なパスワードポリシーを作成するのは難しいため、ここで役立つ既存のポリシーを確認してください。
もちろん、古いパスワードはポリシーの影響を受けないので、ポリシーに準拠するようにユーザーに古いパスワードを変更するように強制する必要があります
ダメージを制限する
強力なパスワードを適用することは確かに良い考えですが、理想的には、ハッキングされたWordPressインスタンスがWebマスターとしてのあなたに実際に影響を与えるべきではありません。
攻撃者がWordPressインストールへのアクセス権を取得したら、被害を制限する必要があります。理想的には、サーバー全体ではなく、その1つのインスタンスのみが影響を受けるようにする必要があります(したがって、攻撃者が正当なユーザーが行うのと同じように、悪質なコンテンツをWebサイトに配置することを心配するかもしれませんが、コードの実行やその他の悪意のあるものについては心配しないでください)アクティビティ)。
これはかなり広いトピックですが、いくつかの点は次のとおりです:DISALLOW_FILE_EDIT
、プラグインの使用を制限(それらはWordPress自体よりもはるかに安全にコーディングされていないため)、JavaScriptを許可しない(たとえば、マルチサイトでは、スーパー管理者のみがJavaScriptを投稿する権利を持ち、管理者など)