0

以下に示す多段階認証を実装しました。

角かっこ（[および]）はハッシュを表します

クライアントには、認証に使用されるキーとシークレットがあります。サーバーには、キー、ソルト、および[シークレット+ソルト]を含む行を含むデータベーステーブルがあります。

       Client                                    Server
         |                                          |
         ----------------- key -------------------->| 
         |                                          | 
         |                                          |
         |<--------- server-nonce -------------------
         |<------------ salt ------------------------
         |                                          |
         |                                          |
         ------------ key ------------------------->|
         ------------ client-nonce ---------------->|
         --[c-nonce + s-nonce + [secret + salt]] -->|
         |                                          |

次に、サーバーは受信したハッシュを自身の情報と照合します。

私の懸念は、これにより、攻撃者がサーバーからソルトを取得し、レインボーテーブルを作成してそのアカウントをハッキングできるようになることです。これについてどう思いますか？

4

3 に答える 3

0

なぜあなたはクライアントに戻るために塩が必要なのですか？純粋にユーザーの秘密を保護するためですか？c-nonceとs-nonceはどちらもとにかく送信されるので、隠されているのは[secret+salt]の組み合わせだけです。

私の感じでは、それが1回限りのソルトであれば、それは問題ではありません。そのソルトで1つの応答のみを受け入れ、失敗した場合は新しいソルトを生成して、プロセスを再度実行します。そうすれば、ソルトがインターセプトされた場合、レインボーテーブル攻撃は不可能になります。これは、最初のリクエストでのみ有効であり、非常に幸運な推測が必要になるためです。

また、プログレッシブタイムアウトや制限付きログイン数など、ユーザーへの影響はほとんどないが、何百回ものログイン試行を実行しようとする自動ツールに問題を引き起こす手法を使用することで、この種の攻撃を回避できます。セキュリティが重要な場合、これはとにかく実装する価値があります。

于 2010-02-25T12:27:22.123 に答える
0

あなたが正しい。攻撃者がこれがシステムの動作方法であることを知っている場合、データをキャプチャしてクラックする可能性があります。安全ではありません。

これらの落とし穴がない他の多くのシステム（SSL、公開鍵認証など）があるのに、なぜこのルートをたどるのかわかりません。

于 2010-02-25T12:27:47.883 に答える
0

接続が安全でなく、攻撃者がソルトとパスワードを手に入れることができた場合、レインボーテーブルがなくても、アカウントをハッキングする可能性があります。

ソルトだけ\パスワードは役に立たない。

アルゴリズムは次のようになります。

client-----pass------>server
client<----noonce----server
                     server--------getSalt---->back-end-service
                     server<-------salt------- back-end-service
                     server-------[pass+salt]->storage
于 2010-02-25T12:31:19.277 に答える