2

わかりました、ちょっとしたゲームです:

プロジェクトの仕様がいくつかあります。ある時点で、彼らはネットワーク上でパスワードを暗号化するために次のように要求し、それはチャレンジ レスポンス プロトコルであると述べています。

クライアントサーバー

(1)挑戦を求める -------------->

(2) <-------------------------------- 時刻から取ったSHA1を送信
                                       （これが課題です）
(3) make SHA1 xor PASSWORD --------> SHA1 xor 保存されたパスワードと等しい場合

(4) <-------------------------------- アクセス許可

ご存じない方のために説明すると、SHA は Secure Hashing Algorithm の略で、暗号化の標準アルゴリズムです。

私はそれが明確であることを願っています。質問: パケット 2 と 3 (「チャレンジ」と「チャレンジ xor パスワード」) を盗聴した場合、実際のパスワードはそれらの間に別の xor があるだけです!?!? この種のプロトコルを実装する他の方法があります。 ??

4

10 に答える 10

4

パスワードをリバースエンジニアリングすることができます。パスワード自体ではなく、パスワードの SHA を送信する必要があります。独自のセキュリティ プロトコルを展開することは、ほとんど良い考えではありません。SSL等は使えないのですか？

http://en.wikipedia.org/wiki/Cryptographic_nonce

于 2008-10-09T16:26:51.657 に答える
3

以下はどうでしょう。

  1. サーバーはランダムなチャレンジを送信します
  2. クライアントが (チャレンジ + パスワード) の SHA1 チェックサムを送信
  3. サーバーは、(チャレンジ + 保存されたパスワード) の SHA1 チェックサムと比較します
于 2008-10-09T16:40:08.947 に答える
2

それはかなり恐ろしいプロトコルです。これが誰かがあなたに実装して欲しいものであるならば、それを拒否してください。このタイプのものには、既存の精査されたプロトコルがあります。これがあなたがすべての欠陥を指摘するゲームであるならば-大丈夫。

  • 手順2と3を聞いた人は誰でも、パスワードを知っています
  • 手順3を聞いて時刻をメモした人は誰でも、サーバー上の時刻の正確さを知っていれば、パスワードを総当たり攻撃できます。
  • 私はサーバーのふりをして（arpポイズニング、DNSレディクションなど）、パスワードを取得できます。ステップ4を完了せず、タイムアウトを装うことはありません。
  • クライアント/サーバー間またはサーバー上の証明書間で共有シークレットがないため、中間者攻撃に対して脆弱です。
  • SHA1（time）を格納し、応答を待機しているサーバーに依存しているため、チャレンジの要求でサーバーを過負荷にし、応答することはありません。

そして、私は間違いなくもう少し欠けています。

于 2008-10-09T16:37:14.397 に答える
1

その通りです。チャレンジをキャプチャして (XOR パスワードにチャレンジ)、パスワードを抽出するのは簡単です。

ステップ 3 では、XOR ではなく、適切な暗号化を使用する必要があります。チャレンジをパスワードで暗号化します。

攻撃者の生活をより困難にするために、暗号化するものにランダム データを追加することができます。サーバーはパディングが何であるかを気にせず、チャレンジを探す場所を知っていますが、攻撃者はプレーンテキスト全体が何であるかを知りません.

于 2008-10-09T16:27:04.213 に答える
1

他の方が指摘されている通り、あなたは正しいです。また、誰かが通信を傍受し (3)、実際のユーザーがネットワークの問題 (例: DDOS) を経験している間にそれを再送信する可能性があることにも注意してください。 、多くのシステムでは、ログイン後にパスワードを変更するためにパスワードを入力する必要はありません)。

HMAC (keyed-Hash Message Authentication Code) を検討することをお勧めします。詳細については、http: //blog.ciscavate.org/2007/09/creating-a-secure-webauth-system-part-1-hmac.htmlにブログを投稿しました。以下に簡単な要約を示します。 .

HMAC は、共有シークレットにアクセスできる人物によってメッセージが生成されたことを確認する方法です。HMAC は、ある種の一方向ハッシュ関数 (MD5 や SHA-1 など) を使用して、メッセージと共にシークレットを暗号化します。これにより、メッセージとシークレットの組み合わせのフィンガープリントとして機能する 16 ～ 20 バイトの短いダイジェストが生成されます。ダイジェストがメッセージと共に送信されると、受信者 (サーバー) は同じ HMAC 計算でハッシュを再生成し、ローカルで生成されたダイジェストをメッセージと共に送信されたダイジェストと比較できます。覚えておいてください: サーバーにもシークレットがあるため、ダイジェストを確認するのに十分な情報があります。(これはメッセージの発信元を検証する問題のみを考慮していますが、別の秘密、たとえば公開鍵のセットを使用する場合、同じアプローチを使用してメッセージ全体を暗号化できます。)

于 2008-10-09T16:39:18.963 に答える
0

私がこれを行う方法は次のとおりです。

  1. サーバーに挑戦します。

  2. サーバーは、デジタル署名された公開鍵 (RSA 暗号化など) で応答します。

  3. クライアントは PK を検証し、キーを使用してパスワードを暗号化し、暗号化されたパスワードにデジタル署名します。

  4. サーバーは署名を検証し、パスワードを復号化して保存/チェックします。

デジタル署名は中間者攻撃を防止する最初の手段として機能するため、ここでは重要です。

于 2008-10-09T16:43:03.540 に答える
0

Diffie-hellman はよく知られた堅実な鍵交換プロトコルだと思いますか?

于 2009-11-18T18:07:12.563 に答える
0

他の人が指摘しているように、はい、これは貧弱なチャレンジ レスポンス アルゴリズムです。

HTTP で使用されているDigest Authenticationを調べてみてください。実際、プロトコルが HTTP を介している場合は、独自の記述をスキップして、これを使用または実装するだけでかまいません。

于 2008-10-10T11:14:03.860 に答える
0

公開鍵暗号？サーバーの公開鍵を使用してパスワードを暗号化します。

于 2008-10-10T11:32:15.290 に答える
0

独自の暗号化プロトコルを展開することは決して良い解決策ではありませんが、私はお勧めしません....

あなたが直面している問題を克服するには... F - パスワードと単調に増加する値を疑似乱数で取り、数値を返す関数。例えば ​​Hash(Hash(Password) ^ Timestamp)

  1. サーバー : チャレンジを要求し、(タイムスタンプ) を送信します。最後に送信されたタイムスタンプを記憶します。
  2. クライアント、応答を送信 (F(パスワード、タイムスタンプ) およびタイムスタンプを送信)
  3. サーバー: クライアントから送信されたハッシュ (パスワード) とタイムスタンプ (> チャレンジで送信されたタイムスタンプ) を使用してクライアントを確認します。
  4. クライアントが正しければ、アクセスを許可します。
  5. リプレイ攻撃を防ぐために、現在のタイムスタンプが次のチャレンジの前にすべてのクライアントが送信したタイムスタンプよりも大きいことを確認してください。

敬具、アシッシュ・シャルマ

于 2008-10-10T11:33:32.060 に答える