これは質問なのか要望なのかイマイチ分かりませんが『やる側』は言語など無関係なので、ログイン情報が2バイト文字にできたからといって攻撃が減るわけありません。
ログイン情報が一切分からないのに当てずっぽうで繰り返す、下手な鉄砲も数撃ちゃ当たる、当たれば儲けもの、それがブルートフォースアタックです。
ログイン情報に扱える言語が増えた場合のメリットは総当たり攻撃のヒット率が下がるだけです。
攻撃そのものは減りません。
プルートフォースは総当たりなので、その総たるを生成する環境が異なれば意図するところに向かうと思いますが逆に環境が合致すると意味ないのではないかと思います。
汎用性においてみなローマ字を多くつかわれておりますが、function.phpに20行ほど追加することで別の文字や画像をつかってログインなどに変更をすることは可能です。
ユーザーの環境や対象に特化するため画像ログインやコード番号ログインに変更する機能を作成した経験がありますが一般には必要ないかなと思います。
セキュリティとしては現時点において多くの方が取り組まれている形式のものが有用だと思います。
例をあげると、エラーの回数制限、本人確認を確実に個人に行わせる電話番号認証など、ユーザー名とパスワードを同時に入力しない、ではないでしょうか。
ユーザー名とパスワードというのはどうあってもあわせて鍵になってしまいますので「数うてば解決する」というブルートフォースの目的に完全に合致してしまいます。
「数で解決」の相対ならば「数を制限する」や「数が意味をなさない」といった「数」の制限または本人個人のみの特定端末にのみ鍵が届くが最も有効で、次に「鍵の条件を漏洩しにくくする」ユーザー名とパスワードの分離といった対策がよりよいかと思います。
三番目の分離についてはブルートフォースに対して実質的な試行回数を二乗することで複雑化するのと、通信の傍受において正回答を取得されにくくしてくれます。
私個人としては、文字に変化をつけたり入力の代替にて対策をすることと比較して、試行回数を一日3回までなどにすることはそれ以上に充分安全性を大きくとれるのではないかと思います。
こんにちは
実現できて、ユーザーが全角文字でID登録をすれば効果は絶大だと思います。
ブルートフォースアタックの本質はmanboさんの言われているとおり総当たりなので、その総当たりに必要な回数を天文学的な回数にすることで、破られる確率をほとんどゼロにすることができます。
SSLのSHA公開鍵のビット長が1024ビットから2048ビット変更されていったのも、似たような原理に基づくものです。
半角英数は36文字です。たとえば、一般的なIDの文字数を5文字として(ちょっと少ない気もしますが)、IDの最大試行回数は
6千万回
です。
Unicodeが何文字なのかちょっと良く知りませんが、65,536文字として、同じく5桁ですと
1,208,92,581京回
となり、1回あたり0.1秒で攻撃しても383京年必要となり、事実上不可能になるでしょう。
(当然ながら上記にパスワードも組合せた回数の攻撃が必要です)
当然ながら、全角文字でID登録する人が一定数存在することが前提ですが・・・
辞書攻撃では効果は薄めかもしれません。
確率は非常に上がり、全角の辞書(例えば「管理者」など)も追加していけば、早期にヒットするかもしれません。
ブルートフォースアタックに対する対策をコアに組み込むのは、守備範囲からして難しいかもしれませんね。
プラグインでは、全角化の影響を見切れないので、そちらも実装が困難かもしれませんが・・・
言葉足らずで申し訳ございませんでした。
ブルートフォースアタックが総当たり、であるということは
そう総たる鍵の山がどういったものであるか攻撃者はわからないので
もてる全部の文字列をあててくるわけです。
山が全角も含まれますと看板をだしておけば相手が辞書を倍増してくれば
実際には半角数字だけであったとしても当ててくる分母量がふえているため
アタックの回数だけは多くなります。
アタックの回数が多い、正答への到達率が下がる、それが安全性の高さといえる
ということではない ということをお伝えしたかったのがひとつです。
ログイン画面に
「全角半角すべての言語文字マップ何々に適合したシステムを使用しています」
と書くだけで攻撃者に対し文字形式攻撃鈍化は狙えるかもしれません。
次に、「藤いS0┬Α」というログイン名であればこれを生成する試行プロセスは
数字のぜろ一つからはじめてとても遠いものになりますが、それであれば
最大文字列のアスキー番号最後の文字を作成すれば最強ということになってしまいます。
あてずっぽうが効率的でないことは想像に難くないと思いますので、まず実在のものから
試していくと思うのですが、絶対的な文字列のコード位置ではなく人間の発想に近い
使用頻度の高く、人との親和性における相対位置の近いものから攻撃していくので、
安全性という意味では人間の解釈できるものを利用することにおいてマルチバイト・
シングルバイトの差はないと思います。
分母の数という「数量の大小」と「機械なら数をこなせる」という特性において
両者合致した方法、同軸線上の同じベクトルで攻防を行うより同じ土俵に乗らないようにする
工夫がより良いのではないかと思うのです。
ユーザー名とパスワードを分離することが二乗になる、の表現がよくなかったかと思うのですが
これが増えるのは「トライ回数」という「数」であるのですがこれは「組み合わせの数」ではなく
「トライ・アクセスするという接触回数」を表現したかったのでした。
ログイントライに対する通信タイミングが2倍になるということは、電算速度以外にも制限要因が増え
「回数試す」に対して問題が大きくなる、それは1度で解決するものにたいして試行回数の倍と、
あわせて必要項目の倍、と増えていくことをお話したかったのです。
もちろん、安全ではない接続からの読み取りがなされないように、ZIPファイルをメールで
送るときにパスワードと別送する要領が第一義ではなると思います。
攻撃に対して耐性をあげる、突破に対して安全性を高める、といった目的に対し
文字列の工夫はあまり効果がないと思うところをお伝えしたかったのですがなにかの参考にいただければ幸いです。
提言しておりますが、一言、当方にそれなりの知識と技術があれば、プラグイン化してみたいところですが、あいにくそこまでのリテラシーはございません。
cgi時代に、日本語入力を可能にするパッチか何かあった気がすることからの可能性の発掘です。
misioさんのコメントの「function.phpに20行ほど追加することで」は、ヒントになりました。
アイデアの狙いは、munyaguさんのおっしゃる383京年必要となり、事実上不可能にすることです。
WPのオープンソースの理念に基づき、アイデアもオープンな形で共有され、実現できる実力がある方には、実現していただければ、WPの発展に一役となるのではないでしょうか。
それと、なんせ、初心者の日本人ユーザーにとって、アイパスが、忘れにくくなるのではないでしょうか。
パスワードを、自分のペットの名前をカタカナで入力することができたなら、忘れないと思います。
ps
SiteGuard WP Pluginが、日本語入力を要求できているので、高いハードルではないはずと考えるのと、PCのスペックが、今後も高速化することから、半角英数の36文字を8ケタ程度での組み合わせでは、瞬時で突破されることが予測されます。
「百匹目の猿現象」に、例えると、やがてどこかの国で作られるプラグインだとすれば、他国に先んじられるよりも、日本人チームでやってみたらどうなんでしょう。