SSLまたは事前共有キーなしでWebサイトログインを保護する最良の方法は何ですか？
今日、私は授業中に暗号化されていないwlanトラフィックを盗聴しましたが、wiresharkで「pass」と「user」を検索するだけでかなりの数のパスワードを見つけました。私たちが学校で使用しているサイトの約半分は、データを暗号化していないことがわかりました-ログイン時に？username = user123＆password = passwd123のようなGETリクエストを使用しています。私はこれについて考え始めました、そして今、私は疑問に思います。これを回避する最良の方法は何ですか？暗号化は簡単に元に戻すことができ、ワンタイムキーも「簡単に」キャプチャできます。これまでの私の最高の考えはクライアント側のハッシュですが、これはある意味で悪い考えでしょうか？
更新：ここでの制約については明らかにしていませんが、すべての回答に感謝します！サーバーにはSSLがなく、使用するすべてのものをphp/asp/asp.netサーバー側またはクライアントのJavaScriptに実装する必要があります。存在する唯一の事前共有キーはパスワードです。それ以外はすべて攻撃者に知られます。
私はハッカーからパスワードを隠そうとしているだけです。残りの情報は暗号化されないため、セッションの盗用が可能になります。それが次の問題です。多分あなたは通知でページ上の情報を暗号化することができます。暗号化されたテキストがたくさんあるので、辞書攻撃が効果的です。これが、ユーザーのパスワードを暗号化に使用したくない理由です。たぶん、512/1024ビットのようなものを使用できるかもしれませんXORキーをユーザーのパスワードで暗号化しますか？または、パスワードの一部を使用します。
クライアントで暗号化された通知は、彼/彼女のパスワードの最初の2文字が良い考えだと思いますか？最初の2文字がパスワードとXORされた乱数。ユーザーはキーを持っているので、これはユーザーが解読できるはずです（キーは入力されたパスワード文字列からjsを介して取得されます）。通知は乱数になるので、正しく解読されたかどうかは何もわかりません。
基本的に：1.ユーザーはユーザー名を入力し、サーバーに投稿/取得します。 2.サーバーは、暗号化された通知とパスワードボックスのあるページで応答します。 3. JavaScriptはnounceを復号化し、パスワードはそれとXORされます。 4.パスワードがサーバーに送信され、パスワードが復号化されてハッシュされます。5.ハッシュがデータベースに保存されているものと比較されます。
注：サーバーは無料でSSLをサポートしていますが、使用したくありません。 SSLが壊れているため、SSLは好きではありません。
ターゲットサーバーが、スニファーを利用した攻撃者ではなく、ユーザー名とパスワードにアクセスできるようにする必要があります。そのため、ターゲットサーバーは、攻撃者が実行できないことを実行できる必要があります。攻撃者はサーバーと同じ種類のPCを購入できるので、その追加の能力はサーバーが知っているものでなければならず、攻撃者ではないはずです。
ちょっと、そこにがありますそのようなデータ：パスワード！それがポイントですね。これは、実際にはクライアントとサーバー間の事前共有キーです。
パスワードは、人間の脳の制限のため、キーの点ではかなりお粗末です。それでも、それで作業できます。そのための最良のプロトコルは Password Authenticated Key Exchange ：共有の低エントロピーキー（パスワード）を共有の高エントロピーキーにエスカレートでき、対称のすべてのおいしいことを実行できます（ワイヤ）サメを寄せ付けない暗号化。そして、PAKEプロトコルはoffline辞書攻撃に抵抗しながらそれを行うことができます（ここでは「offline」が重要な言葉です）。
悪い知らせは、PAKEプロトコル、より一般的には、交換されたデータと後でリンクして認証が実際にアクティブな攻撃者に耐えられるようにすることができる認証プロトコルは、正しく理解することが難しいことです。最も単純だが安全なプロトコルは、SRPを使用したSSLであることがわかります（そのための [〜＃〜] rfc [〜＃〜] があります）。良いニュースは、SSL + SRPがクライアントとサーバー間のパスワードベースの相互認証を提供することです証明書をまったく使用しない（そして、人々が望まないと言ったとき） SSLを使用するために、彼らが通常意味することは、彼らがX.509証明書と最初のPKI市場に手を出したくないということです。
残念ながら、SSL + SRPサポートは広く普及していません（ GnuTLS はSRPを認識するオープンソースライブラリです）。
クライアント側のハッシュを使用する場合、それは実際のサイトパスワードになり、何も達成しませんでした。
最善の方法はSSLを使用です。メカニズムは理由のために存在します。代替スキームは、安全でないか、めちゃくちゃ複雑になる傾向があります。
SSLを使用せずにそれを実行したいと言っていましたが、理由も理由もありませんでした。現在の状況や、SSLの回避を正当化する理由については説明しませんでした。したがって、別の提案を提供したい場合でも、それらが要件を満たしているかどうかを判断することは不可能です。
サーバーにユーザーを認証することだけに関心がある場合（そして、後のデータの暗号化を気にしない場合）、Lamportのハッシュは、JavascriptとPHP/ASP/ASP.netにハッシュ関数ライブラリがすでに実装されているため、簡単に実装できます。 。
Lamportのハッシュは、次のように機能する一種のワンタイムパスワードスキームです（アリスがユーザー、ボブがサーバーです）。
初期登録
登録時に、Aliceは[n、hash ^ n（password）]をサーバーに送信します（hash ^ nはパスワードをハッシュした結果であり、その結果をハッシュしてから、その結果をハッシュします...、n回）。サーバーは[n、hash ^ n（password）]をデータベースに格納します。
認証
- アリスは自分のID（ユーザー名）をボブに送信します：「アリス」
- ボブは「n」で応答します
- アリスはボブにx = hash ^ {n-1}（パスワード）を送信します
- ボブはhash（x）を自分のデータベースに保存されているダイジェストと比較します
- 一致する場合、認証は成功し、ボブは[n、hash ^ n（password）]を[n-1、x = hash ^ {n-1}（password）]に置き換えます
- それ以外の場合、認証は失敗し、ボブはデータベースにあるものを保持します
実用上の考慮事項
- あなたはおそらくパスワードでソルトを使いたいでしょう（ボブは＃2でソルトを送ることができます）
- Nが十分に小さくなると、アリスは自分のパスワードを変更する（またはソルトを変更するだけでよい）必要があり、[n、hash ^ n（salt + password）]をボブに再送信する必要があります
- 再登録が頻繁に行われないように、十分な大きさのnを選択してください
- これは一方向の認証（ユーザーはサーバーに対して認証されるが、サーバーはユーザーに対して認証されない）にすぎないため、中間者が可能です。
Lamportのハッシュが要件を満たしていない場合（たとえば、相互認証が必要な場合）、SRPがおそらく最善の策ですが、JavascriptおよびPHP/ASP/ASP.netに実装した時点で、サーバーをレンタルした可能性があります。 SSLをサポートしています。SSLは最初から明らかに最適です。
たとえば、TLS、AES、およびWebSocketの組み合わせには既知の問題があるため、暗号化アルゴリズムとしてAESを使用しないTLS（SSLでさえない）が答えです。それ以外のすべて（JavaScriptを使用してクライアントのパスワードを暗号化するなど）は安全ではありません。もちろん、wiresharkを使用して直接読み取ることはできませんが、JavaScriptが途中の男性からのものである可能性があります。あなたの学校を説得してみませんか？ TLSサーバーに切り替える。これが最も簡単な方法であり、アプリケーションコードを変更する必要はありません。
SSLは、平文のパスワードほど壊れることはありません。 SSLを使用します。シャイアーは自分の暗号システムを設計する人々について何か言いたいことがあると思います。
SSLが壊れているため、SSLは好きではありません。
これは、説明も参考資料もないまま放棄するというかなり劇的な主張です。 TLSまたは具体的にはSSL v1-3を含むすべての形式のSSLを意味しますか？
それは他の多くの試みられた問題の解決策よりもはるかに優れています。
安全な通信を確立する唯一の方法は暗号化を使用することです。ブラウザベースのクライアントの場合、SSLの組み込み機能を使用していない場合は、暗号化を実装するためのコード（Javascript、ActiveX、Javaなど）を提供します。 flash ....）安全でない接続を介して。したがって、コードが危険にさらされる可能性があります。 PFSアルゴリズムでrot13または4096ビットのキーを使用するかどうかは関係ありません。安全に配信されないコードによって処理される場合は、コードを変更してパスワードを取得するのは簡単です。
SSLが壊れていると思われる場合は、修正してください。これは、時間を費やすためのはるかに有益な方法です。
クライアントでJavaScriptを実行できる場合は、パスワードのハッシュに基づいてDiffie-Helman鍵交換またはチャレンジ/レスポンスメカニズムをセットアップし（システムにプレーンテキストを保存しないでください）、それを使用して高度な認証プロセスを実行できます。暗号化された資格情報が認証のために返されます。
これらはアクティブなMITM攻撃を阻止しませんが、パッシブな攻撃者がパスワードを盗聴するのを防ぎます。
最初にチェックするのは、サーバーがダイジェスト認証を使用したhttp認証をサポートしているかどうかです。あなたはそれをphp経由で有効にすることができるかもしれません。
http://www.php.net/manual/en/features.http-auth.php
SSLほど安全ではありませんが、クラスの人々がパスワードを盗聴しないようにするのは簡単なトリックかもしれません。 http authを使用して、保護する必要のあるサイトの領域をブロックします。彼らはあなたがしているすべてを見るでしょうが、彼らはhttp認証パスワードを取得しません。 （セッション中に他のパスワードを取得します）