問題タブ [brute-force]

最近の WiFi 暗号化は、最新の GPU の並列処理能力を使用することによって力ずくで行われました。 同様の手法が役立つと思われる実生活の問題は他に何があると思いますか?

職場では、塩について 2 つの競合する理論があります。私が取り組んでいる製品では、ユーザー名や電話番号などを使用してハッシュをソルトしています。基本的に、ユーザーごとに異なるものですが、私たちはすぐに利用できます。他の製品は、ユーザーごとにソルトをランダムに生成し、ユーザーがパスワードを変更するたびに変更します。その後、ソルトはデータベースで暗号化されます。

私の質問は、2 番目のアプローチが本当に必要かどうかです。純粋に理論的な観点からは、最初のアプローチよりも安全であることは理解できますが、実用的な観点からはどうでしょうか。現在、ユーザーを認証するには、ソルトを暗号化せずにログイン情報に適用する必要があります。

考えてみると、このアプローチによる実際のセキュリティの向上は見られません。アカウントごとにソルトを変更すると、攻撃者が各アカウントのソルトをすばやく判断する方法を知っていたとしても、誰かがハッシュ アルゴリズムをブルート フォースしようとすることは依然として非常に困難になります。これは、パスワードが十分に強力であることを前提としています。(明らかに、すべて 2 桁のパスワード セットの正しいハッシュを見つけることは、8 桁のパスワードの正しいハッシュを見つけるよりもはるかに簡単です)。私の論理が間違っていますか、それとも何かが欠けていますか?

編集：さて、ソルトを暗号化するのは本当に無意味だと思う理由は次のとおりです。（私が正しい軌道に乗っているかどうかを教えてください）。

以下の説明では、パスワードは常に 8 文字で、salt は 5 文字で、すべてのパスワードは小文字で構成されていると仮定します (計算が簡単になるだけです)。

エントリごとに異なるソルトを持つということは、同じレインボー テーブルを使用できないことを意味します (実際、技術的には、十分なサイズのテーブルがあれば使用できますが、それは今のところ無視しましょう)。これは、私が理解しているソルトへの本当の鍵です。なぜなら、すべてのアカウントを解読するには、いわばそれぞれのアカウントを再発明する必要があるからです。正しいソルトをパスワードに適用してハッシュを生成する方法を知っていれば、ソルトは実際にはハッシュされたフレーズの長さ/複雑さを拡張するだけなので、それを行います。したがって、ソルトが何であるかを知っているため、パスワード + ソルトを 13^26 から 8^26 に「知る」ために生成する必要がある可能な組み合わせの数を削減します。これで簡単になりましたが、それでも本当に難しいです。

それでは、ソルトの暗号化について説明します。ソルトが暗号化されていることがわかっている場合は、最初にそれを復号化しようとはしません (十分なレベルの暗号化があることがわかっている場合)。私はそれを無視します。それを解読する方法を見つけようとする代わりに、前の例に戻って、13^26 のすべてのキーを含むより大きなレインボー テーブルを生成します。ソルトを知らないと間違いなく遅くなりますが、最初にソルト暗号を解読しようとするという記念碑的なタスクが追加されるとは思いません. だからこそ、もったいないと思います。考え？

ブルート フォース攻撃に対してパスワードが保持される期間を説明するリンクは次のとおりです: http://www.lockdown.co.uk/?pg=combi

私は中学生で、アルゴリズムの設計と分析というコースを受講していました。コースはクールですが、インストラクターはそうではありません。総当たりと操作回数の数え方と時間の複雑さ（最悪、最良、平均）の数え方が分からず、ネットで検索してみましたが毎回デカイオで終わります私が望んでいない表記と分割統治。このリンクからインストラクターのスライドをダウンロードして、私が話していることを確認できる人がいれば....

スライド

私はこれについて本当にあなたの助けが必要です、そして私は最善を尽くすことを約束します

私は初心者の C++ プログラマーであり、私の心を伸ばすために、projecteuler.netでいくつかの問題を試してきました。学校で数学に興味を持っていたにも関わらず、合理化されたものや洗練されたものを探すのではなく、自動的に力ずくで問題を解決しようとしていることに気づきました。

これは悪い考え方のように聞こえますか？こんなことをするのは少し罪悪感がありますが、場合によっては、迅速で汚いことも問題ないかもしれません...

最近のTwitter のハイジャックとJeff の Dictionary Attacks に関する投稿への回答として、ブルート フォース ログイン攻撃から Web サイトを保護する最善の方法は何ですか?

Jeff の投稿では、ログインを試行するたびに遅延を増やすことを提案しており、2 回目の試行に失敗した後にキャプチャを追加することをコメントで提案しています。

どちらも良いアイデアのように思えますが、「試行回数」をどうやって知るのでしょうか? セッション ID (攻撃者が毎回変更する可能性があるため) または IP アドレス (より優れていますが、ボットネットに対して脆弱です) に依存することはできません。ユーザー名に対してログを記録するだけで、遅延メソッドを使用して正当なユーザーをロックアウトできます (または、少なくともログイン プロセスが非常に遅くなります)。

考え？提案？

脆弱なパスワードで保護されたアカウントをボットがハッキングするのを防ぎたいです。(たとえば、これは ebay や他の大きなサイトで起こりました)

そこで、IP、試行回数、最後の試行のタイムスタンプ (memcache-fall-out) を使用して (mem-) キャッシュ値を設定します。

しかし、たった 1 つのパスワードでアカウントを開こうとするボットはどうでしょうか。たとえば、ボットはパスワード「password123」を使用して 500.000 個のユーザー アカウントすべてを試行します。たぶん10は開きます。

したがって、私の試みは、IPを試行してキャッシュし、max-triesを〜50に設定することでした. ログインが成功したら削除します。したがって、グッドボットは、ロックのリセットを 49 回試行するたびに、有効なアカウントでログインするだけです。

それを正しく行う方法はありますか？大手プラットフォームはこれについて何をしますか? ばかが 50 回の再試行でプロキシ上のすべてのユーザーをブロックしないようにするにはどうすればよいですか?

ベスト プラクティスがない場合、どのプラットフォームも力ずくで攻撃できるということですか? 少なくともカウンターがいつリセットされるかについてのヒントはありますか?

まず、少し背景があります。CodeIgniterにauth + authシステムを実装していることは周知の事実であり、これまでのところ（いわば）勝っています。しかし、私はかなり重要な課題に遭遇しました（ほとんどの認証ライブラリは完全に見逃していますが、適切に処理することを主張しています）：大規模な分散型の可変ユーザー名ブルートフォース攻撃にインテリジェントに対処する方法。

私はすべての通常のトリックを知っています：

1. IP /ホストごとの失敗した試行の数を制限し、違反者のアクセスを拒否します（Fail2Banなど）-ボットネットがよりスマートに成長したため、これは機能しなくなりました
2. 上記を既知の「不良」IP/ホスト（DenyHostsなど）のブラックリストと組み合わせる-これは、ボットネットが1位に該当することに依存していますが、ボットネットはますますそうではありません
3. 従来の認証と組み合わせたIP/ホストホワイトリスト（動的IPユーザーとほとんどのWebサイトでの高いチャーンでは残念ながら役に立たない）
4. N分/時間の期間内に失敗する試行の数にサイト全体の制限を設定し、その後のすべてのログイン試行を数分/時間の間スロットリング（一時停止）します（DoSがあなたを攻撃するとボットネットの子供の遊びになるという問題があります）
5. ログイン/パスワードオプションがないすべてのユーザーに必須のデジタル署名（公開鍵証明書）またはRSAハードウェアトークン（確かなソリューションですが、閉じた専用サービスでのみ実用的です）
6. 強制された超強力なパスワードスキーム（例：記号付きの25を超える意味のない文字-繰り返しますが、カジュアルユーザーには実用的すぎます）
7. そして最後に、CAPTCHA（ほとんどの場合は機能しますが、ユーザーにとっては煩わしく、断固とした機知に富んだ攻撃者に対しては事実上役に立たない）

さて、これらは理論的に実行可能なアイデアにすぎません。サイトを大きく開いてしまうようなごみのアイデアはたくさんあります（たとえば、些細なDoS攻撃など）。私が欲しいのはもっと良いものです。そして、より良い意味で、私は意味します：

• DoSおよびブルートフォース攻撃に対して安全（+）である必要があり、わずかに卑劣なボットがレーダーの下で動作し続けることを可能にする可能性のある新しい脆弱性を導入してはなりません。

• 自動化する必要があります。人間のオペレーターが各ログインを確認したり、疑わしいアクティビティを監視したりする必要がある場合、実際のシナリオでは機能しません。

• それは主流のウェブの使用のために実行可能でなければなりません（すなわち、非プログラマーによって実行されることができる大量の解約、大量の、そしてオープンな登録）

• カジュアルなユーザーがイライラしたりイライラしたりする（そしてサイトを放棄する可能性がある）まで、ユーザーエクスペリエンスを妨げることはできません。

• 彼らが本当に安全な子猫でない限り、それは子猫を巻き込むことはできません

（+）「安全」とは、少なくとも、パスワードを秘密にしておくパラノイドユーザーの能力と同じくらい安全であることを意味します

だから-聞いてみよう！どうしますか？私が言及していないベストプラクティスを知っていますか（ああ、そう言ってください）？私は自分自身のアイデアを持っていることを認めます（3と4のアイデアを組み合わせます）が、恥ずかしい思いをする前に、真の専門家に話させます;-)

ユーザーのログイン試行が制限されている Web アプリを見てきました。

それはセキュリティ上の必要性ですか? もしそうなら、それはなぜですか?

例: ログインに 3 回失敗しました。10 分後にもう一度試してみましょう。

存在しない古いアプリケーションを使用している顧客がいます。彼はアプリケーションを作成した会社に問題があり、彼らは彼のデータベースのパスワードを公開しません。彼は、アプリケーションを「レンタル」しているようなものであり、何も開示する権利がないという契約書に署名した (当時) ことに気付きました。この顧客は、その会社で同じ問題を抱えているのは自分だけではないことに気付きました。彼は歯科医であり、同じ古いアプリケーションを使用している他の歯科医が、新しいソフトウェアを購入しようとして患者を新しいシステムに移行しようとしたときに、同じ問題を経験しました。

どちらの場合でも、彼は自分の小さな firebird データベースを開きたいので、少なくとも一部のデータを SQL Server に抽出できます。デフォルトの「マスターキー」（実際には、8文字の制限により「マスターキー」です）を試してみましたが、役に立ちませんでした。

今、私は彼が合法的に会社に彼の情報を公開するよう強制しようとすることができることを知っていますが、私はそれを手短にやりたいと思っています. 古いFirebirdパスワードをブルートフォース/クラックできるアプリを知っている人はいますか?

ありがとう。

編集: レガシー ソフトウェアは「STOMA-W」です。インターネット上でも見つけることができません。彼らはスペインのアストゥリアスにあります。