HTTPSを使用せずにログインし、セキュリティで保護する方法
Webアプリケーションの場合、HTTPSがセキュリティ対策として利用できない場合でも、ログインをある程度安全にすることは可能ですか？例えば。：
- ログインをトークン化し、繰り返し攻撃を困難にしますか？
- どういうわけか、送信されたパスワードをHTMLパスワードフィールドから暗号化しますか？
特に、私はCakePHPとAJAX POST提供されたユーザー名とパスワードを含む）を呼び出す呼び出しを使用しています。
問題の更新：
- HTTPSは使用できません。限目。状況が気に入らない場合は、理論的な質問と考えてください。
- 明示的な要件はありません。HTTP、PHP、およびブラウザ（Cookie、JavaScriptなど）が実際に提供しているもの（魔法のRSAバイナリ、PGPプラグインはありません）があります。
- 質問は、何が最良か、あなたはthisの状況から抜け出すことができ、それはパスワードを平文で送るよりも良いことです。そのような各ソリューションの欠点を知ることはプラスです。
- プレーンパスワードよりも優れた改善点は歓迎します。 100％l33tG0Dhx0r-proffソリューションを目指していません。クラックするのが難しいのは、ハッキングするのが難しいのよりも、パスワードを明らかにする些細なスニッフィングよりも優れています。
HTTPSはWebサイトとブラウザ間の安全な接続を維持する上で不可欠です。 パブリックwifiネットワークはユーザーを危険にさらします 、そして正しく使用された場合、HTTPSはユーザーアカウントを保護できる唯一のツールです- この脆弱性 。
ホストがHTTPSをサポートしていない場合、 Cloudflare Universal SSL などのサービスを使用して、サーバーがサポートしていない場合でも、すべてのブラウザーがHTTPSを使用してサイトに接続できるようにすることができます SSL/TLSをサポートします。 CloudflareとWebサイトの間の接続は引き続き保護されませんが、このCloudflareサービスは、パブリックWiFiネットワークで見つかった脅威からユーザーを保護することを目的としています。侵入テスターの観点から、HTTPSを提供しないことは非常に疑わしいです。トラフィックの配信として基本的なセキュリティ要件を提供していない場合、他にどのようなセキュリティ要件が欠けていますか？ HTTPS証明書は Let's Encrypt または SSLの開始 を使用して無料で取得できます。HTTPSをサポートしない正当な理由はありません。
HTTPSは、「パスワードを暗号化する」以上のことを行うため、非常に重要です。もう1つの重要な役割は、ユーザーが実サーバーになりすましている悪意のあるサーバーへのログインを許可しないようにすることです。システムを使用してパスワードのみを保護することは、依然として攻撃者が必要とするプレーンテキストでセッション資格情報を送信しているため、 OWASP A9-Insufficient Transport Layer Protection の違反です（ Firesheep ）。
「ログインのトークン化」：攻撃者がトラフィックを盗聴している場合、ユーザーはプレーンテキストのユーザー名/パスワードを取得し、これらの新しい資格情報でログインできます。 （リプレイ攻撃）
「送信されたパスワードを何らかの方法で暗号化する」：攻撃者がログインした後、トラフィックを盗聴して有効なsession id（cookie）を取得し、ログインする代わりにこれを使用します。セッション全体がSSL/TLSで保護されている場合、これは問題ではありません。
このシステムと現在のSSLインフラストラクチャの両方に影響を与える他のより複雑な攻撃があります。 SSLStrip 攻撃はより詳細になります。 Moxie MarlinspikeのBlackhat 2009トークをご覧ください をお勧めします。これは HTTP-Strict-Transport-Security標準 につながります。
WebサーバーでSSLを実行することはできず、セキュリティの専門家でもないため、利用できる既存の安全な認証サービスを探し、SSLと資格情報の処理の複雑さの両方を処理できるようにします。
特に、 OpenID などの無料のサードパーティ認証サービスを使用することをお勧めします。 [〜＃〜] php [〜＃〜] のライブラリがあり、 CakePHP のライブラリも含まれています。
編集：（リスクについて）
サードパーティのセキュア認証サービス（HTTPS自体を使用）を使用すると、HTTPS（サーバー上）を使用せずに認証自体を行う問題を軽減できますが、攻撃の可能性を完全に排除するわけではありません。
最も一般的な2つの攻撃は、replay攻撃、およびsession-hijackingで、攻撃者は後で真のログインセッショントークンを再利用できます、または悪意のある目的で有効なセッショントークンを使用します。
リプレイ攻撃は、セッショントークンを期限切れにすることで、できれば nonce を使用してセッションリプレイを防ぎ、セッションハイジャックのリスクを減らすことで軽減できます。ナンスの場合、正常なセッションはハイジャックに成功するとエラーを生成します。これは、ナンスの有効期限が切れている（使用されている）ため、独自のセッションが無効になるためです。
HTTPSを使用してサーバーとの間で送受信中にセッショントークンを暗号化できない場合、session-hijackingまたはman-in-などのアクティブな攻撃を完全に防ぐことはできませんthe-middle攻撃。このは、非営利的な使用のための小さなユーザーベースのWebサイトなど、場合によっては許容される場合があります。
簡単な答えは、SSLエンドポイントからエンドポイントへの暗号化がなければ、安全に実行することは不可能だということです...
この主な理由の1つは、ブラウザーで安全な暗号化を実行できないことです。 このリファレンス-有害と見なされるJavascript暗号化 を参照してください。
さらに、資格情報のソースが実際にあなたが話している人であると確信できる方法はありません。つまり、SSLなしでは Man-In-The-Middle攻撃 が進行していないことを確認する方法はまったくありません。
いいえ、できません。
また、試してはいけません。 SSLを取得します。無料の証明書を取得できます。通常、ホストは月に数ドルで専用IPを提供します。そして、本当にセキュリティに関心があるなら、少なくともVMを専用IPアドレスで使用することになります。
これを試みることでさえ、 Security Through Obscurity であり、最悪の場合は何もありません。 SSLは解決された問題です。そのソリューションを使用しない理由。セキュリティは推測するものではありません。適切な手法を使用してください。自分で発明しようとしないでください。うまくいきません...
提案したように、ページが作成されるたびに一意のトークンを生成できる場合があります。その同じトークンをフォームデータとともに送り返す必要があり、再利用できませんでした。ユーザーが有効にしていることに依存できる場合は、JavaScriptを使用してハッシュすることでパスワードを安全に保つこともできます。
ただし、このスキームはまだ安全ではありません。攻撃者は依然として、すべてがネットワーク上を行き交っているのを見ることができます。トークンをインターセプトし、ユーザーが応答する前に応答を送り返す可能性があります。または、誰かがログインするのを待って、その人の資格情報を盗んで（有線で送信されるため）、後で自分のログイン要求を行うこともできます。
ボトムライン -サイトが安全であることを保証するためにHTTPSを使用する必要があります。
Javascriptを使用してパスワードを暗号化し、サーバーで復号化できます。
サーバー上でRSAキーペアを生成し、公開キーと時間指定されたソルトをブラウザに送信し、Javascriptの公開キーを使用してソルトと組み合わせてパスワードを暗号化することをお勧めします。
JavascriptでRSA実装を見つけることができます こちら
プロキシの背後でのCookieの盗難を防ぐために、認証CookieにIPアドレスと X-FORWARDED-FOR hedaerの両方を含める必要があります。
機密データを扱う場合は、ランダムに JavascriptのAESキー を生成し、RSAで暗号化されたパスワードとともにサーバーに送信できます。
それから、アプリケーション全体で暗号化されたAJAX単一ページからのリクエストを使用し、認証Cookieをまったく使用しないようにすることができます。
SSLなしでアクティブな中間者攻撃から保護することはできないことに注意してください。アクティブな攻撃者は、自分のサイトを自分のプロキシに完全に置き換えることができますが、これを防ぐ方法はありません。 （既知の良好なコードは存在できないため）
HTTP Digest 認証を使用できます。これは、ほとんどのブラウザーでサポートされており、パスワードを平文で送信しません。
欠点は、ブラウザによって表示されるいログインボックスです。フォームに固執する場合は、フォーム認証でHTTPダイジェストとまったく同じプロトコルを実装できます。レルムとチャレンジを含む非表示フィールドを送信し、クライアントにJavaScriptにノンスを追加してダイジェストを計算させます。このように、独自のロールを作成するのではなく、よく知られた実績のある交換プロトコルを使用します。
HTTP Digestでは、ハッシュ操作のみが必要です。
HTTPSには多数のユースケースがあり、そのほとんどは中間者攻撃から防御するように設計されています。ハッカーの考え方を持っている人はだれでも、何かを成し遂げるために確立された方法以外の方法はないとあなたに言うために震えます。実際、TLS（現代のHTTPSが使用する標準）を使用しているからといって、それをうまく使用しているわけではありません。さらに、TLSを使用するだけでは、誰かが既知の弱点を悪用することを防ぐことはできません。データを保護するための創造的な方法を見つけようとしているように、セキュリティ対策を活用するための創造的な方法を見つけている人々がいます。
じゃあ何をすればいいの？
まず、TLSを使用しない場合、その仕組みを理解しておくと役立ちます。そして、それはすべて握手です。
クライアントとサーバーは、TLSの使用に同意すると、ハンドシェイク手順を使用してステートフル接続をネゴシエートします。[7]このハンドシェイク中に、クライアントとサーバーは、接続のセキュリティを確立するために使用されるさまざまなパラメーターに同意します。
- クライアントが安全な接続を要求するTLS対応サーバーに接続し、サポートされている暗号スイート（暗号およびハッシュ関数）のリストを提示すると、ハンドシェイクが開始されます。
- サーバーは、このリストから暗号化とハッシュ関数を選択し、それもサポートしてクライアントに決定を通知します。
- サーバーは、IDをデジタル証明書の形式で送り返します。[矛盾]証明書には通常、サーバー名、信頼できる認証局（CA）、およびサーバーの公開暗号化キーが含まれます。
- クライアントは、証明書を発行したサーバー（上記の信頼できるCA）に接続し、続行する前に証明書の有効性を確認できます。
- セキュアな接続に使用されるセッションキーを生成するために、クライアントはサーバーの公開キーで乱数を暗号化し、結果をサーバーに送信します。秘密鍵を使用して、サーバーのみが復号化できる必要があります。
- 乱数から、両方の当事者が暗号化および復号化のための鍵素材を生成します。
上記の手順のいずれかが失敗すると、TLSハンドシェイクは失敗し、接続は作成されません。
ソース： Wikipedia
だから、それは可能ですか？はい。何でも可能だと教えられました。高価かもしれませんが、常に可能です。
私はセキュリティの専門家ではなく、単なる愛好家であることを完全に開示したいと思います。実稼働グレードのプロジェクトや、あなた自身の教育以外のプロジェクトでこれを試みることはお勧めしません。必ずチェックアウトする必要があります this SO post これは、独自のセキュリティプロトコルのセットアップにおける障害について優れた説明を提供します。
ただし、先に進みたい場合は、ここで思い浮かぶいくつかの考えがあります。これらは、あなたがこのプロジェクトでどの方向に進んだかに関係なく存在する現実です。
HTTPSは、すべての主要な最新ブラウザーでサポートされています。この現実であっても、HTTPSのロード時間は単純なHTTPよりも遅いです。大規模な生産が行われないと、代替の実装の安全性が大幅に低下し、安全性が低下する可能性が高くなります。これは、ブラウザ機能を利用しない限り、自社開発の実装の欠点となります。これにより、現代のHTTPSが利用しているTLSの使用に完全に戻ることができます。
ブラウザ側でTLSを使用せずに、JavaScriptを使用してMiTM攻撃が困難になるほど予測不能な方法でパスワードを暗号化する場合は、休まないでください。また、送受信するデータを保護する必要があります。それ以外の場合、暗号化されるパスワードは実際には無関係です。確かに、攻撃者はbobsmith109のパスワードを知らないかもしれませんが、ネットワーク上のすべてのアクティビティを盗聴できるため、パスワードは必要ありません。彼は、bobsmith109が何回ログインするかを知っており、おそらく自分のIPや、送受信する機密データを追跡できます。
どのようなセキュリティ対策を講じても、徹底したセキュリティがあります。そのため、すぐにできることの1つは、データベース内のデータを暗号化しながら強力なパスワードを要求することです。
繰り返しますが、私はではなくセキュリティ専門家であり、これを強く落胆させますあなたの好奇心を満足させる以外の何か。 SSL/TLSが誇ることができるように、数十年とはいかないまでも何年もプロジェクトに貢献する非常に大きなセキュリティプロフェッショナルのグループなしで、TLSの実行可能な代替を作成できることは天文学的にはありえないことです。そうは言っても、先に進むことを選択した場合の良い出発点は、上記のハンドシェイクモデルを見て、TLSなしでこのバージョンを実装する方法を確認することです。
私の投稿では、HTTPSを使用する際の実際の障壁のほとんどが積極的に戦われていることを共有しないことを怠りません。最も大きなものの1つであるコストは、問題になりそうにありません。 2015年第2四半期に無料の認証局がリリースされる予定です。いくつかの例を挙げると、MozillaやAkamaiを含むいくつかの大きな銃によってサポートされています。 記事はこちら 。
HTTPダイジェスト認証 についてはどうですか？これは、サーバーに送信する前に、MD5ハッシュのユーザー名、パスワード、ナンス（など）によってセキュリティを提供します。 MD5は実際には安全ではありませんが、HTTPを使用した単純なセキュリティには良い方法です。
もちろん、これはハッカーによるメッセージの変更を妨げるものではありませんが、パスワードは保護されます。
HTTPSを使用せずにログインし、セキュリティで保護する方法
サーバーとクライアントの間に安全なチャネルがないため：
- 安全なチャネルがないため、誰でもトラフィックをスヌープできます。
- 誰でもトラフィックをスヌープできるため、MITM攻撃にさらされます。
- mITM攻撃にさらされているため、クライアントに正当なページが表示される保証はありません。
- ページが正当ではなく、ページが実際に提供されていない（中央の人がページを提供している）ため、サーバー側で使用されるすべてのトリックは役に立たなくなります。
何ができる？理論的には？
- クライアントとサーバーの両方が暗号化を使用して、スヌーピング/ MITMの影響を受けにくくする必要があります。
- 握手できないと仮定して、
- クライアントがすでにキーを所有しており、サーバーと同じ意味不明な言葉を話す方法を知っていると仮定します。
- hTTPを介したSSLについてはどうでしょうか？
しかし、待ってください...マジックバイナリやプラグイン、RSAでさえも言わなかったので、社内暗号化（場合によっては非常に弱い）を除いて、これが可能かどうかはわかりません。
-
公開キー暗号化（GPGかもしれません）を使用し、ブラウザーのキャッシュを利用することで、あるポイントに複製を試みることができます。
これは安全なものではありません。洗練された攻撃者にとってはSSLを適用するだけでは十分ではありません。HSTS、公開鍵のピン留めなどを使用して、Webサイトを安全に考慮する必要がありますtoday。
残りの答えは思考の糧です。
- 公開鍵と秘密鍵のペアを作成します。プライベートなものは安全に保管してください。
- 公開鍵と
encrypt関数を含むjsファイルを作成し、安全な暗号化アルゴリズムを見つけます。この関数は、レプリケーション攻撃を回避するために、追加のタイムスタンプで特定の文字列（シリアル化された形式）を暗号化する必要があります。 - このファイルを
Cache-Control:public, max-age=31536000HTTPヘッダーで提供します。攻撃者がスクリプトを置き換えようとするときの軽減を試みます。ファイルは常にブラウザのキャッシュから提供されます。 encrypt関数を使用して、すべてのフォームをJavascript経由で送信します。上記と同じヘッダーでこれらを提供します。- サーバー側で、データが
decryptの場合、タイムスタンプが有効である場合はチェックします。そうでない場合は、それを破棄します。 - 非常に短い時間に一度だけ使用できるCookieトークンを作成します。攻撃者がCookieをキャプチャした場合、何かをする時間はあまりありません。ただし、攻撃者が十分に速い場合、元のユーザーをログアウトさせる可能性があります。
- 応答ごとにCookieを変更します。しかし、ユーザーが一度に複数のリクエストを送信し、それらが逆の順序で到着したらどうしますか？どのクッキーが有効ですか？これは、誤った安心感を犠牲にして多くの問題を生み出します。
リスナーは、行き来するデータを利用できず、キャッシュが期限切れになるまでexistingJSファイルを変更/挿入することはできません。ユーザーがキャッシュをクリアします。ただし、高度な攻撃者であれば、HTMLファイル全体を置き換えることができます。これにより、今述べたすべてのセキュリティ測定が破棄されます。少なくともHTTPSを介してこのファイル/フォームを提供できる場合は、might逃げ、githubページなどに配置します。ただし、ファイルを他のドメインに配置する場合は、受信ドメインが機能するようにCORSを設定する必要があります。
別の試み
ワンタイムパスワードがメールで送信されます。
- ユーザーはメールに入力し、リンクをクリックして、ログインを可能にするトークンを含むメールへのリンクを送信します。
- ユーザーがリンクをクリックする
- サーバーはトークンをチェックし、ユーザーをログインさせます。
- 前の例のようにクッキーをロールします。
全体として、何をするにしても、それは安全ではないです。高速で洗練された攻撃者を考えると、邪魔になるものはありません。
インフラストラクチャがSSLをサポートしていない場合は、SSLを取得して変更します。上司がSSLを信じていない場合は、上司を説得してください。誤った安心感を作らないでください。ユーザーのデータを保護します。場所によっては、法的にユーザーのデータを保護する必要があります。
次に、SSLを使用してサイトを安全にする方法について説明します。
非対称暗号を使用して公開/秘密キーペアを作成します。
サーバーに対称キーを作成します。
クライアント側に公開鍵を送信します。
対称暗号クライアント側のランダムキーを作成します。
クライアント側の公開キーを使用して、そのランダムキーを暗号化します。
暗号化されたキーをサーバーに送信します。
サーバーは以下を実行します
a。秘密鍵を使用してランダム対称鍵を復号化します。
b。生成されたクライアントキーを含むトークンを作成します。
c。トークンに署名します。
d。サーバーの対称キーを使用してトークンを暗号化します。
e。すでに暗号化されたトークンをクライアント生成キーで暗号化します。
f。暗号化されたトークンを送信します。
クライアントはこのトークンを受け取り、以下を実行します
a。生成されたキーでトークンを解読します。
b。復号化されたトークンを保存します。
c。この時点で、保存されたトークンはサーバー対称キーでのみ暗号化されます。
クライアントからサーバーへのすべてで：
a。クライアントが生成したキーを使用して送信データを暗号化します。
b。トークン+暗号化されたデータを送信する
サーバーが受信するすべてのリクエストで：
a。サーバー対称キーを使用してトークンを復号化します。
b。署名を検証します。
c。トークンに保存されたクライアント生成キーを使用してデータを復号化します。
"The Secure Remote Password Protocol"をご覧ください。
自分で策定する代わりに、彼らのウェブサイトから引用させてください。
Secure Remote Passwordプロトコルは、人間が記憶できる短いパスワードの安全なリモート認証を実行し、受動的および能動的なネットワーク攻撃に抵抗します。
そして：
[The]プロトコルは、ゼロ知識証明の技術と非対称鍵交換プロトコルを組み合わせ、拡張EKEやB-SPEKEなどの盗難検証攻撃に対抗する比較的強力な拡張方法よりもパフォーマンスを大幅に向上させます。
スタンフォード大学はPHPとJavaScript自体の実装を提供していませんが、サードパーティの実装にリンクしています。
これらのリンクの1つは、オンラインパスワードマネージャーである "Clipperz"につながります。 GitHubのコミュニティエディションとしても利用できます。そこで、彼らは "javascript-crypto-library" をホストします。これはプロトコルと "password-manager" 自体を実装します。 PHPおよびPythonで記述されたバックエンドが含まれます。
コードの関連部分を抽出するのがどれほど難しいかは言えませんが、それらの実装を再利用できます（AGPLでライセンスされています）。
2014/10/24を編集：
SRPに関するウィキペディアの記事 には、さらにいくつかの実装がリストされています。 PHP/JSに関連：