0

私は小さな webapp を書いていますが、ログイン パスワードをクリアテキストとして送信したくありません。私は SSL を利用できないので、クライアント側で HMAC-SHA256 を使用してパスワードをハッシュするために使用されるログイン フォームでランダムな文字列を送信する 1 回限りのチャレンジ システムを作成しました。ランダム チャレンジ文字列をメッセージとして使用し、ユーザーのパスワードを HMAC の秘密鍵として使用します。

自作のソリューションは一般的に悪い考えであることを知っているので、ここで間違いを犯していないかどうかを尋ねたかった.

4

2 に答える 2

1

私はこれが許容できる解決策であるとは思わない。

HMACの目的は、データの整合性と信頼性を検証することです。したがって、これを使用して情報が変更されていないことを確認し、ユーザーが秘密鍵(この場合はパスワード)を持っていることを確認できます。

それができないことは、チャネルを暗号化し、エンドユーザーのサーバーのIDを確認することによって盗聴から保護するなど、SSLが実行できる他のいくつかのことです。

盗聴:中間者(MITM)がこのトランザクションを監視し、リターン応答(HMACダイジェスト)を傍受し、それを自分の要求として送信することを妨げるものは何もありません(他のユーザーからの応答を停止することさえあります) 。

サーバーのIDの確認:ここで欠落している最も重要な部分の1つは、フィッシング詐欺師にだまされないようにユーザーを保護することです。有効なSSL証明書があれば、ユーザーはそのサイトがあなたのものかなりすまし者かを確認する方法がありません。エンドユーザーの信頼性を検証することで自分自身を保護しようとしていますが、これはすばらしいことですが、エンドユーザーを保護することを忘れています。

なぜSSLが利用できないのか知りたいです。私はこれをよく耳にしますが、通常の理由は、誰かが証明書のために50ドルをポニーにしたくないからです。しかし、証明書はそれだけの価値があり、セキュリティが重要な環境では、SSLが利用できないという技術的な理由は実際にはありません。

于 2011-09-06T18:33:39.833 に答える
0

これを行うには、サーバーから送信されたランダムな文字列を送信先のクライアントにリンクする何らかの方法が必要です。そうしないと、攻撃者はハッシュ化されたパスワードとランダムな文字列をサーバーに送信して、アクセスを取得することができます。

ただし、ランダムな文字列をある種のサーバー セッションに保存すると、セッション スプーフィングが攻撃ベクトルとして利用される可能性があります。

攻撃者はユーザーのパスワードを発見することはできませんが、ユーザーになりすます可能性があるため、パスワードをプレーンテキストで送信するよりも優れたソリューションです。

于 2011-09-04T12:51:14.463 に答える