$ _POSTデータとしてusername
とpassword
のみを含むphpログインフォームを作成しています。しかし、フォームを送信する前に、JS関数check()
はpassword
入力をbase64_encodeし、最後に次のようにフォームを送信します(カスタマイズされたbase64_enc関数は、単なるbase64よりも少し進んでいますエンコード)
function check() {
var pwd = $_get_by_id('loginPw').value;
$_get_by_id('loginPw').value = base64_enc(pwd);
$_get_by_id('loginFrm').submit();
}
もちろん、それとは別に、ブルートフォース(セッションID、csrfトークン、キャプチャ、テンポ禁止...)を防ぐために、セキュリティに関して十分な知識があることは知っています。
しかし、この時点で、この単純なjavascriptトリックが攻撃の速度を低下させる可能性があるのでしょうか。 (攻撃者でさえ、彼/彼女の辞書の別の処理されたバージョンを生成する必要があります)
たとえば、hydraツールがスレッドを実行する前にワードリストの各行を処理できる場合(javascript check()fnにあるシェルコードバージョンを使用)
パスワード入力データをエンコードすることにより、ブルートフォース攻撃を遅くできますか?
はい、クライアントに高価なタスクを実行させることにより、ブルートフォース攻撃を人為的に遅くすることができますログイン試行ごとに。この概念は 作業の証明 と呼ばれます。これは、大量のスパムと戦うためのよく知られたアプローチであり、技術的には、Web上の認証システムにも適用できます。
ただし、具体的な提案は作業証明プロトコルとしては認められません。これは、base64はまったく高価ではなく、サーバーが検証するのと同じように、クライアントが生成するのと同じ量の作業が必要だからです。また、攻撃者は暗号化されたパスワードを再計算することなく、何度でも再利用できます。他のアカウントを攻撃する。
実際の作業証明の実装では、たとえば、 challenge-response scheme を作成し、ユーザーがログイン試行ごとに高価なハッシュ計算を実行するように要求します。チャレンジは、ハッシュを部分的に反転することです。ランダムなシーケンスを提供し、そのシーケンスで終わるSHA-256ハッシュを生成するようにユーザーにチャレンジします。シーケンスの長さを増やすと、クライアントによる指数関数的により多くのハッシュ計算が必要になりますが、結果の検証は常に単なる文字列比較です。
プロジェクト "proof-of-work-login" は、ログインにPOWを使用するという考えを取り入れた、私が見つけた数少ない実例の1つです。 (ただし、実装の品質についてはコメントできません。)説明から:
ログインを許可する前に、クライアント側のSHA256ハッシュを計算する必要があります。これにより、Hidden ServicesのようにIPで禁止できない環境でのブルートフォースログイン攻撃が制限されます。
それにもかかわらず、Webアプリケーションの場合、CAPTCHA、アカウントごとのログイン試行の制限、IPのブラックリスト化など、ブルートフォース攻撃を阻止するためのより簡単な方法があることに留意してください。
いいえ、エンコードされたパスワードがパスワードであるため、このアイデアは攻撃者を遅くしません-これは、HTTPクライアントがアクセスする必要がある値ですシステム。その時点では、元のパスワードはほとんど付随的ではありません。代わりに、ハッカーはパスワードの代わりにBase64文字列を反復することに注意を向け、合計エントロピーはまったく同じになります。また、ハッカーがパスワードのディクショナリを持っている場合、まったく同じリストを構成するBase64文字列のディクショナリを生成するのは簡単です。
しかし、攻撃者に複雑な問題を解決するように依頼することで、攻撃者を遅くすることはひどい考えではありません。 [〜#〜] captcha [〜#〜] が最も一般的な例です-ハッカーツールはCAPTCHAを解決する方法を理解できますが、少しのCPUが必要であり、 1秒あたりの総当たり攻撃。複雑な問題を解決することも同じです。パスワードの送信に加えて、スクリプトはサーバーから提供された(ランダムで無関係な値に基づく)ハッシュの背後にある値も推測する必要があった場合。ただし、そのメカニズムをパスワードとは完全に切り離しておく必要があります。
それは攻撃者に何も変更しません。辞書を更新する必要もありません。
攻撃はパスワードを生成し、HTTPリクエストを実行する関数に送信します。攻撃者はターゲットとするURLを選択し、パラメーターに名前を付ける必要があります。その関数でのパスワードのエンコードは遅くありません。これはHTTPリクエストよりも桁違いに速く、リクエストサイズへの影響は非常に小さいため、まったく影響がありません。