HTTP経由でパスワードを安全に送信する方法は？

ログイン画面でユーザーがユーザー名とパスワードを使用してフォームを送信すると、パスワードはプレーンテキストで送信されます（POSTを使用していても、間違っている場合は修正してください）。

それで問題は、通信データを盗聴している可能性のある第三者からユーザーとそのパスワードを保護する正しい方法は何ですか？

HTTPSが問題の解決策であることは承知していますが、標準のHTTPプロトコル（POSTリクエスト）を使用して、少なくともある程度のセキュリティを確保する方法はありますか？（おそらくJavaScriptを何らかの方法で使用しています）

編集 私はいくつかの重要なことを省いたかもしれません。

私が言っていたのはページでした。つまり、PHPで生成されたログインページです。もちろん、HTTP GETリクエストでHTMLファイルとしてユーザーに送信されます。サーバーとクライアントの間に（@Jeremy Powel）接続が確立されていないため、このようなハンドシェイクプロトコルを作成できません。そして、私は完全なプロセスがユーザーに透過的であることを望みます-彼は暗号を扱うのではなく、パスワードを提出したいと考えています。

ありがとう。

SSLでHTTPを使用すると、生活がはるかに簡単になり、安心して休息することができます（少なくとも私よりも賢いです！）

安全な認証は幅広いトピックです。一言で言えば、@ jeremy-powellが述べたように、HTTPではなくHTTPS経由で資格情報を送信することを常に優先します。それは多くのセキュリティ関連の頭痛を取り除くでしょう。

TSL / SSL証明書は最近かなり安価です。実際、お金をかけたくない場合は、無料のletsencrypt.orgがあります。自動認証局があります。

さらに一歩進んでcaddyserver.comを使用できますで、バックグラウンドでを呼び出すcaddyserver.comます。

さて、邪魔にならないようにHTTPSを取得したら...

POSTペイロードまたはGETパラメータを介してログインとパスワードを送信しないでください。代わりに、次のように構成されるAuthorizationヘッダー（基本アクセス認証スキーム）を使用します。

• ユーザー名とパスワードは、コロンで区切られた文字列に結合されます。例：ユーザー名：パスワード
• 結果の文字列は、Base64のRFC2045-MIMEバリアントを使用してエンコードされますが、76文字/行に限定されません。
• 次に、認証方法とスペース、つまり「Basic」がエンコードされた文字列の前に置かれます。

ソース：ウィキペディア：承認ヘッダー

少し複雑に見えるかもしれませんが、そうではありません。すぐに使えるこの機能を提供する優れたライブラリがたくさんあります。

Authorizationヘッダーを使用する必要がある理由はいくつかあります

1. 目安です
2. 簡単です（使用方法を学んだ後）
3. 次のように、URLレベルでログインできるようになります：（https://user:password@your.domain.com/loginたとえば、Chromeは自動的にAuthorizationヘッダーに変換します）

重要：
以下のコメントで@zaphが指摘しているように、機密情報をGETクエリとして送信することは、サーバーログに記録される可能性が高いため、お勧めできません。

チャレンジ/レスポンス方式を使用できます。クライアントとサーバーの両方が秘密のSを知っているとしましょう。次にサーバーは、クライアントがパスワードを（それを明かすことなく）知っていることを確認できます。

1. サーバーは乱数Rをクライアントに送信します。
2. クライアントはH（R、S）をサーバーに送信します（HはSHA-256のような暗号化ハッシュ関数です）
3. サーバーはH（R、S）を計算し、それをクライアントの応答と比較します。それらが一致する場合、サーバーはクライアントがパスワードを知っていることを認識しています。

編集：

Rの鮮度とHTTPがステートレスであるという事実に問題があります。これは、サーバーだけが知っている秘密をQと呼ぶサーバーに作成させることで処理できます。次に、プロトコルは次のようになります。

H（R、Q）はクライアントによって偽造できないため、H（R、Q）はCookieとして機能します（したがって、実際にはCookieとして実装できます）。

別の編集：

H（R、Q）を観察した人は誰でも正しいハッシュでそれを再生できるように見えるので、プロトコルの以前の編集は正しくありません。サーバーは、どのRが最新でないかを覚えておく必要があります。私はこの答えをCWしているので、皆さんはこれを編集して、良いものを見つけ出すことができます。

ウェブホストで許可されている場合、または機密データを処理する必要がある場合は、HTTPSを使用してください。（これは法律のafaikによってしばしば要求されます）。

それ以外の場合は、HTTP経由で何かを実行する必要があります。私はこのようなことをします。

1. サーバーはその公開鍵をログインページに埋め込みます。
2. クライアントはログインフォームを入力し、[送信]をクリックします。
3. AJAXリクエストは、サーバーから現在のタイムスタンプを取得します。
4. クライアント側のスクリプトは、資格情報、タイムスタンプ、ソルト（マウスの動き、キーを押すイベントなどのアナログデータからハッシュ化）を連結し、公開キーを使用して暗号化します。
5. 結果のハッシュを送信します。
6. サーバーはハッシュを復号化します
7. タイムスタンプが十分に新しいかどうかを確認します（5〜10秒の短いウィンドウのみを許可します）。タイムスタンプが古すぎる場合、ログインを拒否します。
8. ハッシュを20秒間保存します。この間隔の間、ログインの同じハッシュを拒否します。
9. ユーザーを認証します。

したがって、この方法ではパスワードが保護され、同じ認証ハッシュを再生できません。

セッショントークンのセキュリティについて。それは少し難しいです。しかし、盗まれたセッショントークンの再利用を少し難しくすることは可能です。

1. サーバーは、ランダムな文字列を含む追加のセッションCookieを設定します。
2. ブラウザは、次のリクエストでこのCookieを送り返します。
3. サーバーはCookieの値をチェックし、異なる場合はセッションを破棄し、それ以外の場合はすべて問題ありません。
4. サーバーは、Cookieを別のテキストで再度設定します。

そのため、セッショントークンが盗まれ、リクエストが他の誰かによって送信された場合、元のユーザーの次のリクエストでセッションが破棄されます。そのため、ユーザーが頻繁にサイトを閲覧し、リンクをクリックすることが多い場合、盗まれたトークンを盗むことはできません。このスキームは、重要な操作（アカウントの削除など）に別の認証を要求することで強化できます。

編集：攻撃者が別の公開鍵を使用して独自のページを設定し、サーバーへのリクエストをプロキシする場合、これはMITM攻撃を防止しないことに注意してください。これを防ぐには、公開鍵をブラウザのローカルストレージまたはアプリ内に固定して、この種のトリックを検出する必要があります。

実装について：RSAはおそらく最もよく知られているアルゴリズムですが、長いキーの場合は非常に遅くなります。PHPまたはJavascriptの実装がどれほど高速になるかわかりません。しかし、おそらくより高速なアルゴリズムがあります。

サーバー側とクライアント側のDiffie-Hellman鍵交換システムをAJAXまたは複数のフォーム送信（前者をお勧めします）で使用しますが、インターネット上での適切な実装は見られません。JSライブラリはMITMによって常に破損または変更される可能性があることに注意してください。ローカルストレージを使用して、ある程度これに対抗することができます。

あなたは使用することができますSRPを安全でないチャネルを介して安全なパスワードを使用します。利点は、攻撃者がトラフィックを盗聴したり、サーバーを危険にさらしたりしても、別のサーバーでパスワードを使用できないことです。https://github.com/alax/jsrpは、ブラウザーまたはサーバー側（ノード経由）でHTTPを介した安全なパスワードをサポートするJavaScriptライブラリです。

HTTPSは非対称暗号化を使用しているため、非常に強力です。このタイプの暗号化では、暗号化されたトンネルを作成できるだけでなく、ハッカーではなく適切な人物と話していることを確認できます。

これは、非対称暗号RSA（PGPで使用）を使用して通信するJavaソースコードです。http： //www.hushmail.com/services/downloads/

ホストにsslを使用できます。letsencrypthttps : //letsencrypt.org/のようなsslの無料プロジェクトがあり ます。

ここでhttpsを使用するのが最善の方法です（現在、証明書はそれほど高価ではありません）。ただし、httpが必要な場合は、いくつかの暗号化を使用できます-サーバー側で暗号化し、ユーザーのブラウザーで暗号化します（キーを個別に送信します）。

safevia.netを実装する際にこれを使用しました -暗号化はクライアント（送信側/受信側）側で行われるため、ユーザー層のデータはネットワーク層でもサーバー層でも利用できません。