1

パスワードの安全な保管について少し混乱しています。ユーザーアカウントテーブルを持つデータベースがあるとしましょう。そして、これは私がパスワードを保管する場所です。今回はsalted sha1を使用しています。

Blowfish ベースの関数は、リクエストの処理に時間がかかるため、sha1 よりも優れていると読みました。

ブルートフォース攻撃に対する「ファイアウォール」として、salted sha1 を使用せず、ログイン試行回数を適切な数 (たとえば、1 時間あたり 50 回) に制限する理由はありますか?

このデータベースを使用している人は、クエリでレコードを変更できるため、総当たり攻撃を行う必要はありません。

4

3 に答える 3

5

フグベースの関数とは、確かにBCryptハッシュ関数を意味します。すでに述べたように、BCrypt は遅くなるように設計されています (計算時間が必要です)。それが他の高速ハッシュ関数に対する唯一の利点ですが、これは非常に重要です。

市販の GPU を使用すると、1 秒あたり約3 ギガのハッシュ値を計算できるため、 2 ミリ秒未満で 5'000'000 語の英語辞書全体を総当たり攻撃できます。SHA-1 が安全なハッシュ関数であっても、パスワードのハッシュには不適切です。

BCrypt にはコスト要因があり、将来のハードウェアに適応できるため、より高速になります。コスト係数は、実行されるハッシュの反復回数を決定します。最近、パスワードのハッシュに関するチュートリアルを書きました。ぜひご覧ください。

ログイン試行を制限するというあなたの主張は理にかなっていますが、攻撃者がデータベースにアクセスした場合 (SQL インジェクション) に備えて、ハッシュによってパスワードを保護する必要があります。もちろん、ログイン試行を制限することはできますが、それはハッシュとは関係なく、このシナリオではパスワードをプレーンテキストで保存することもできます.

于 2012-10-31T08:07:08.133 に答える
1

現在のところ、Blowfish で暗号化された文字列の値を取得する方法は報告されていないため、Blowfish にパスワードを保存することは SHA-1 よりも安全です。一方、SHA-1 では、暗号化された文字列からデータを取得する方法が報告されています。誰かがそのデータを取得するのを防ぐために SHA-1 を信頼することはできません。

提案を受け入れる場合は、パスワードを保存しているため、双方向の暗号化を使用する必要はまったくないと思います。ソルト化されたSHA-256メソッドを使用してユーザーのパスワードをハッシュすることもオプションの 1 つです。ユーザーが電子メールを介して自分のパスワードをリセットできるようにすることは、一般に適切なポリシーと見なされており、簡単にクラックできないデータ セットが作成されます。

何らかの理由で双方向の暗号化が必要な場合は、Blowfish を除いて、 AES-256 (Rijndael) またはTwofishも現在、機密データを処理するのに十分安全です。暗号化されたデータを保存するために複数のアルゴリズムを自由に使用できることを忘れないでください。

ブルート フォースに関して言えば、暗号化されたデータベース ストレージとはほとんど関係がありません。攻撃方法について言及するときは、完全なセキュリティ モデルを見ています。非推奨のアルゴリズムを使用し、ポリシーを実装して攻撃の容易さを防ぐことで「それを補う」ことは、セキュリティに対する成熟したアプローチとは見なされません。

要するに

  • パスワードの保存に一方向ハッシュを使用し、ユーザーがメール経由でリセットできるようにする
  • 複数の方法を使用して暗号化されたデータを保存することを恐れないでください
  • 暗号化/復号化スキームを使用する必要がある場合は、鍵を安全に保管し、実績のあるアルゴリズムのみを使用してください
  • ブルート フォース攻撃を防止することは良い考え方ですが、誰かを遅らせたり、別の侵入ポイントを探すよう促したりするだけです。

これを正しいとは思わないでください。セキュリティに関して言えば、要件は人それぞれ異なります。調査を行えば行うほど、方法が改善されます。完全なセキュリティ ポリシーを使用して機密データを完全にカプセル化しないと、後で驚くべき事態が発生する可能性があります。

出典: ウィキペディア、http ://eprint.iacr.org/2005/010

于 2012-10-30T22:55:04.877 に答える
0

ブルートフォース攻撃に対する「ファイアウォール」として、salted sha1 を使用せず、ログイン試行回数を適切な数 (たとえば、1 時間あたり 50 回) に制限する理由はありますか?

まともなアルゴリズムでパスワードを暗号化しないと、基本的なセキュリティ対策に失敗しています.

ログイン試行を「単に」ブロックするだけでは安全ではないのはなぜですか?

可能性のあるすべての入り口をブロックする必要があるという事実に加えて、たとえば：

  • ssh
  • webservices (webapp、phpmyadmin、openpanel など)
  • ftp
  • さらに多く

また、データベースとサーバーにアクセスできるすべてのユーザーを信頼する必要があります。私は人々に私のパスワードを読まれたくないのですが、私がさらに嫌いなのは、比喩的に言えば、あなたが私のために決定することです:-)

他の誰かが Blowfish と SHA の議論に光を当てることができるかもしれませんが、その部分がスタックに値するフォーマットされた質問であるとは思えません

于 2012-10-30T22:25:40.180 に答える