1

これは、私のセキュリティ プロセスが、保存している情報の種類に適しているかどうかについての質問です。

SQL バックエンドで ASP.NET 4.0 を使用して Web サイトを構築しており、パスワードやハッシュなどに関してセキュリティがどのように維持されるかを知る必要があります。

私は誰かに関する重要な情報を保存しません -real names, addresses, credit card詳細やそのようなものはありません... ただemail and username.

今のところ、いくつかの詳細を意図的に省略していますが、それを伝えることが私のセキュリティを弱めるかどうかはわかりませんが、そうでない場合は、もう少し明らかにすることができます.

これが私がそれを行う方法です：

  1. ユーザーは、電子メールと一意のユーザー名を使用して登録し50 charsます
  2. 彼らはパスワードを作成します（6 chars)キーボード上の任意の文字を最小限使用します（入力をHTMLエンコードし、parameterizedストアドプロシージャを使用しているため、文字を制限しません）
  3. それらが本物であることを確認するためのリンクを記載したメールを送信します。
  4. FormsAuthentication を使用して認証 Cookie を設定しますがSSL、現時点では使用していません...プレーンで認証の詳細を送信することの意味は理解してhttpいますが、ホストに証明書を追加するように依頼したので、すぐに準備が整います。

それは私が確認する必要があるハッシュビットです!

次の文字セットからランダムな100文字ソルトを作成します ( System.Random クラスを使用するだけで、何も使用しませんcryptographic) -abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNOPQRSTUVWXYZ0123456789!£$%^*()_{}[]@~#<,>.?

これはパスワードとマージされ、SHA-512 (SHA512Managed class)何万回も使用してハッシュされます (2 seconds on my i7 laptop最終的なハッシュを生成するのにほぼかかります)。

この最終的なハッシュはbase64文字列に変換され、データベース内の既にハッシュされたパスワードと比較されます (ソルトは DB 内の別の列にも保存されます)。

いくつか質問があります (現時点では証明書の不足は無視しSSLてください。まだ証明書を購入していませんが、1 週間ほどで準備が整います):

  1. これで十分安全だと思いますか？セキュリティにはある程度のレベルがあり、十分な時間とリソースがあればどんなものでも壊れやすいことは理解していますが、重要なデータを保存していないことを考えると、それで十分だと思いますか?

  2. パスワードをハッシュした実際の回数を明らかにすると、セキュリティが弱まりますか?

  3. キャラクターソルトは、100キャラクターソルトと比べて何か違いがあり20ますか?
  4. パスワードを結合する方法を明らかにすることsaltで、セキュリティが弱まりますか?
4

2 に答える 2

4

それでは、質問に 1 つずつ答えてみましょう。

これで十分安全だと思いますか？セキュリティにはある程度のレベルがあり、十分な時間とリソースがあればどんなものでも壊れやすいことは理解していますが、重要なデータを保存していないことを考えると、それで十分だと思いますか?

いいえ、それは間違いなく「十分に安全」ではありません。

コードを見なければ、それ以上のことは言えません。SHA512しかし、 HMAC を実行する代わりにストレートを実行しているという事実は、 1 つの問題を示しています。HMAC を使用する必要があるからではなく、この目的のために設計されたほとんどのアルゴリズムが (いくつかの理由で) 内部で HMAC を使用するためです。

そして、あなたはhash = SHA512(hash)（あなたの言葉遣いから）悪いことが証明されているようです。

したがって、コードを見ずに確実に言うのは難しいですが、正しい方向を指していません...

パスワードを実際にハッシュした回数を明らかにすると、セキュリティが弱まりますか?

いいえ、そうすべきではありません。そうであれば、アルゴリズムのどこかに問題があります。

100 文字のソルトは、たとえば 20 文字のソルトと比べて何か違いがありますか?

いいえ。ソルトが行うのは、ハッシュを一意にすることだけです (攻撃者は各パスワードを個別に攻撃する必要があります)。必要なのは、統計的に一意になるのに十分な長さのソルトだけです。誕生日問題のおかげで、1/10^12 の確率で衝突するには 128 ビットで十分です。これで十分です。つまり、16 文字が塩効果の上限です。

それは、より長い塩を使用することが悪いという意味ではありません. これは、16 文字より長くしても、提供されるセキュリティが大幅に向上しないことを意味します...

パスワードとソルトを結合する方法を明らかにすることで、セキュリティが弱まりますか?

もしそうなら、あなたのアルゴリズムには重大な欠陥があります。存在する場合、それはSecurity Through Obscurityに相当します。

本当の答え

ここでの本当の答えは、車輪を再発明しないことです。PBKDF2 や BCRYPT などのアルゴリズムは、まさにこの目的のために存在します。だからそれらを使用してください。

詳細情報 (これらは PHP に関するものですが、概念は ASP.NET および C# に 100% 適用可能であることに注意してください):

于 2013-05-28T15:42:43.420 に答える
2
  1. 理論的には、あなたのハッシュ スキームは問題ないように思えます。実際には、自分の暗号を転がしたように聞こえますが、これは悪いことです。bcrypt、scrypt、またはpbkdf2を使用します。これらはすべて、セキュリティの専門家によって設計されています。
  2. そうではありませんが、とにかく誰もそれを知る必要はないと思います。
  3. いいえ。すべてのユーザーに対して一意である必要があります。ソルトの目的は、ハッシュ/レインボー テーブル攻撃の事前計算を防ぐことです。
  4. これは、bcrypt (または scrypt または pbkdf2) を使用すると適用されません。

http://security.stackexchange.comには、このテーマに関するトピックがいくつかあります。ぜひチェックしてください。

いくつかの追加メモ - 深刻な攻撃者は、ラップトップよりもはるかに速く sha512 ハッシュをクラックします。たとえば、Amazon などから数個の Tesla GPU を搭載したサーバーを借りて、数十億ハッシュ/秒の速度でクラッキングを開始できます。Scrypt は、メモリを集中的に使用する操作を使用して、これを防止しようとします。

パスワードに最低6文字では不十分です。少なくとも8文字を使用してください. パスワードクラッキング回数

于 2013-05-28T09:25:51.150 に答える