1

動作するblowfishのphp/javascript実装を見つけることができないため、SHA1ハッシュを使用してWebベースの認証を実装することを検討していますが、この特定の分野の知識が不足しているため、選択した方法が十分に安全かどうかわかりません。

計画されたロードマップ：

  1. ユーザーのパスワードは、MD5ハッシュとしてサーバーに保存されます。
  2. サーバーは公開鍵を発行します（ミリ秒単位の現在時刻のMD5ハッシュ）
  3. クライアントのjavascript関数は、ユーザーパスワードを入力として受け取り、そのMD5ハッシュを計算します
  4. 次に、クライアントは公開鍵とパスワードのハッシュを上から連結し、結果の文字列のSHA1を計算します
  5. クライアントはSHA1ハッシュをサーバーに送信します。サーバーでは、公開鍵とユーザーのパスワードMD5ハッシュを使用して同様の計算が実行されます。
  6. サーバーはハッシュを比較し、一致は認証が成功したことを示します。
  7. 不一致は認証の失敗を示し、サーバーは新しい公開鍵を発行し、すでに使用されている公開鍵を事実上期限切れにします。

さて、問題のある部分は、SHA1の前に2つのキーを連結することです。これは、ある種の統計的攻撃やその他の攻撃を受けやすいのでしょうか。

全体的な品質を向上させるためにキーを連結する必要がある特定の順序はありますか（つまり、暗号化の信頼性にとってより高いビットがより重要です）？

前もって感謝します。

4

2 に答える 2

6

'公開鍵'のみを使用している場合（実際には公開鍵ではありませんが、これはナンスであり、特定の時間枠で使用できるようにしたい場合を除いて、実際にはランダムである必要があります。その場合は、次のことを確認してください。秘密鍵を使用してHMACを使用して生成し、攻撃者がナンスを予測できないようにします）。これは固定サイズであり、連結は問題にならない可能性があります。

とはいえ、よく考えられたセキュリティモデルがないのではないかと少し心配しています。とにかく、これはどのような攻撃を防ごうとしているのでしょうか？ユーザーのパスワードハッシュは無塩であるため、パスワードデータベースを壊すと、とにかくプレーンテキストのパスワードが簡単に明らかになります。時間制限のあるナンスを使用すると、パッシブスニファからのリプレイ攻撃が軽減されますが、このようなパッシブスニファはユーザーのセッションキーを盗む可能性があります。とりあえず。そういえば、タイムスタンプベースのシステムではなく、セッションキーをナンスとして使用しないのはなぜですか？

しかし、実際には、SSLを使用しないのはなぜですか？暗号化を正しく行うのは非常に困難であり、あなたや私よりもはるかに賢い人々が、SSLのセキュリティを正しく確認するために何十年も費やしてきました。

編集：MITM攻撃が心配な場合は、SSL以外の何物もあなたを救うことはできません。限目。マロリーは、非常に安全なログインフォームを、パスワードをプレーンテキストで送信するものに置き換えることができます。ゲームオーバー。また、受動的な攻撃者でさえ、セッションCookieを含め、すべてがネットワーク上を通過しているのを見ることができます。EveがセッションCookieを取得すると、それをブラウザに挿入するだけで、すでにログインしています。ゲームオーバー。

SSLを使用できないと言う場合は、保護しようとしているものと、軽減する攻撃の種類を正確に確認する必要があります。暗号化を行うには、おそらく何らかのデスクトップアプリケーションを実装する必要があります。MITMが使用されている場合、HTMLやJavascriptを信頼することはできません。Malloryはそれらを自由に置き換えることができます。もちろん、デスクトップアプリは、データストリームにキー交換、暗号化、認証を実装する必要があります。さらに、リモートホストの認証も実装する必要があります。これは、SSLが行うこととまったく同じです。また、正しく実行すれば、SSLとほぼ同じアルゴリズムを使用して実行できます。

MITMが範囲外であると判断したが、受動的攻撃から保護したい場合は、おそらくJavascriptで深刻な暗号化を実装する必要があります-決してないセッションキーを生成するためのDiffie-Hellman交換について話している有線（HTML5 Webストレージなど）、キーを保護するためのJavascriptのAESなどを介して送信されます。この時点で、基本的にJavascriptでSSLの半分を実装しましたが、バグが増える可能性があります。これは、Javascriptで安全なランダム番号を取得するのが非常に難しいという問題です。

基本的に、次のいずれかを選択できます。

  1. 実際の暗号化セキュリティを実装していない（これらの複雑な認証プロトコルをすべて実装しているため、明らかに選択肢ではありません）
  2. SSLに非常によく似たものを実装しますが、おそらくそれほど良くはありません
  3. SSLを使用します。

つまり、セキュリティが重要な場合は、 SSLを使用してください。SSLをお持ちでない場合は、インストールしてください。私が知っているJSを実行できるすべてのプラットフォームはSSLも処理できるので、言い訳はできません。

于 2011-01-09T13:08:00.367 に答える
1

bdonlanは絶対に正しいです。指摘されているように、攻撃者はJavascriptフォームを邪悪なコードに置き換えるだけで済みます。これはHTTPでは簡単です。その後、ゲームオーバーです。

また、適切な暗号化乱数ジェネレーターを使用して生成された（つまり、サーバーの時計を使用してシードされていない）ソルトを使用してパスワードをSHA-2に移動することを検討することをお勧めします。また、ハッシュを複数回実行します。http://www.jasypt.org/howtoencryptuserpasswords.htmlセクション2および3を参照してください。

MD5が壊れています。MD5は使用しないでください。

安全なスキームは、次のようになっている必要があります。

  1. すべてがSSLで発生します。認証フォーム、フォームを検証するサーバー側スクリプト、画像など。SSLがすべてのハードワークを実行するため、ここで特別なことを行う必要はありません。SSLはすべてを暗号化するため、実際に必要なのは「プレーンテキスト」でユーザー名/パスワードを送信する単純なHTMLフォームだけです。

  2. ユーザーが新しいパスワードを作成します。ランダムなソルトを生成します（サーバー時間に基づくのではなく、適切な暗号ランダムソースから）。ソルトと新しいパスワードを何度もハッシュし、ソルトと結果のハッシュをデータベースに保存します。

  3. パスワードの確認：スクリプトはユーザーのソルトを検索し、ソルト+入力されたパスワードを何度もハッシュします。データベースで一致を確認します。

データベースに保存する必要があるのは、ソルトとハッシュ/ダイジェストだけです。

サポートする必要のあるMD5ハッシュのデータベースがあるとすると、解決策は、新しいSHA-2ハッシュとソルトのデータベース列を追加することです。ユーザーがログインすると、これまでと同じようにMD5ハッシュをチェックします。動作する場合は、「ユーザーが新しいパスワードを作成する」の手順に従って、SHA-2とsaltに変換してから、古いMD5ハッシュを削除します。ユーザーは何が起こったのかわかりません。

これから実際に逸脱するものには、おそらくセキュリティ上の欠陥があります。

于 2011-01-11T17:22:16.747 に答える