security - HTTP経由でWebフォーム認証データを送信するための最良の方法は何ですか？

Question

私が知っている会社は、すべてのWebアプリケーション製品でパスワードセキュリティポリシーを強化するために話し合っています。

現在、HTTPを介してPOSTフォームでユーザー名/パスワード認証を送信しているため、プレーンテキストで送信されています。

この問題の最も簡単な解決策は、すべてのアプリケーション間でログオンするためにHTTPSを要求することです。

さて、代わりに、パスワードのある種の独自のクライアント側暗号化（パスワード+ソルトなど）を実行することについて、いくつかの内部的な議論があります。

受け入れられているHTTPのみのソリューションはありますか？

意見は...まあ、誰もが意見を持っているので、私はあなたの推薦をサポートすることができる信頼できるセキュリティ文献を探しています。ただグーグルしてブログ投稿に送ってはいけません...私はすでにそれ以上のことをしました。

OWASPの推奨事項を見つけました： http ：//www.owasp.org/index.php/Top_10_2007-A7#Protection

Microsoftと同様に：http： //msdn.microsoft.com/en-us/library/aa302420.aspx

編集： SSLの使用を推奨するだけでは不十分です。ある種のサポートドキュメントが必要です。私たち自身のクライアント側の暗号化をローリングするのは悪いことだと私は知っています。私はそれを同僚や経営者に確実に売ることができる必要があります。

また、HTTPダイジェストについても言及されています。良さそうですが、ダイジェストはHTTP認証専用であり、POST経由で送信されるデータ用ではありません。

score 12 · Accepted Answer

（セキュリティに敏感な環境では）独自のソリューションを使用しないことを強くお勧めします。SSLを使用してください。これは実証済みのテクノロジーであり、実装は簡単です。

独自のセキュリティソリューションを導入することは非常に危険であり、適切に実装されていても（0.000001％の確率）、費用がかかります。

score 5 · Accepted Answer

データ自体は機密性が高くなく、パスワードは機密性が高い場合は、HTTP ダイジェスト認証を使用することをお勧めします(これは、HTTP 基本認証とはまったく異なります)。これはストレートな HTTP を介して非常に安全であり、サーバーに実装するのはまったく難しくありません。パスワードが何であるかを明らかにする可能性のあるネットワーク経由で送信されるものは何もありません。クライアントが正しいパスワードを持っていることをサーバーに示すことができる情報だけです。

アプリケーションに HTTP ダイジェスト認証を実装する方法について適切な説明が必要な場合は、Paul James の優れた記事があります。

HTTP 認証の唯一の問題はブラウザー自体にあります。UI はひどいものですが、Javascriptを使えば解決できます。

A1 ハッシュを保存することで、パスワードを安全に保存できます。

更新:他の回答で述べたように、サーバーは基本認証を受け入れないことで MITM 攻撃を回避できますが、クライアントは依然として脆弱です。

更新: (a) クライアントの JavaScript で暗号化を行うか、(b) SSL 経由ですべてを行う場合を除き、POST 経由でデータを保護することはできません。

少し魔法をかけるだけで、フォームで HTTP 認証を使用できます。上でリンクした記事は、結局のところ、「HTML フォームを使用した HTTP Auth」と呼ばれています。しかし、それは POST では行われません。

本当に必要な場合は、POST を使用し、SSL を使用して、データベース内のパスワードをソルトします。

CSRF を回避したい場合は、formkeysを使用することをお勧めします。アイデアにはさまざまな名前が付いていますが、数年前に自分で使用するために Slashcode をハッキングしたことからその名前を選びました。

score 3 · Accepted Answer

Mehrdadの答えに+1 。自家製の暗号化を進めるのは危険です。

ここでの経験から言えば、自家製のクライアント側暗号化ソリューションの脆弱性を見た後です。ほとんどの脆弱性は同じ理由によるものです。データ転送は秘密鍵による暗号化によって保護されていましたが、鍵自体は安全でない方法で交換されました。

TLS / SSLは、安全な鍵交換だけでなく、安全なデータ転送の問題も解決します。

TLS / SSLセッションが確立されると、非対称キー暗号化を使用して情報の暗号化に使用される対称キーを交換することにより、TLS/SSLが機密情報を保護します。対称鍵は実行時に生成され、クライアントとサーバーの間で共有される秘密です。セッションでデータ転送の準備ができたら、他のすべてのトラフィックを暗号化するために使用されるのはこのキーです。

サーバーの公開鍵と秘密鍵は、この共有秘密を交換するためにのみ使用されます。共有キーを侵害する唯一の既知の方法は、サーバーの秘密キーを侵害することです（これにより、秘密キーを復号化できます）。実際には、サーバー管理者の側に過失または悪意が必要です。

独自の暗号化ソリューションを導入する場合は、安全な方法で対称鍵を交換する必要があります。これを行う最も簡単な方法は、TLS/SSLを使用することです。より難しい方法は、独自の非対称鍵交換暗号化ソリューションを実装することです。

score 2 · Accepted Answer

HTTP のみのソリューションは、常に中間者攻撃の影響を受けやすくなります。

編集: ネットワークトレースは、HTTP が安全でないことを証明する簡単な方法です。

score 2 · Accepted Answer

クライアント側の暗号化は、ほとんどの MITM 攻撃に対して無力です。攻撃者はスクリプトを簡単に削除できます。

受動的なスニッフィングからのみ保護します。それで十分な場合は、次を使用できます。

Javascript で実装されたハッシュ。最初のログインにチャレンジ/レスポンスを実装するのは簡単ですが、攻撃者にとってセッション Cookie はパスワードとほぼ同じであることを忘れないでください (ログインを単一の IP に制限するか、スクリプトを使用してワンタイム Cookie を生成する必要があります)。困難で脆弱な解決策になると思います）。
HTTP ダイジェスト認証。ワンタイムハッシュや相互認証などを使用できるため、より安全ですが、標準の UI は完全に反発的です。

...SSLを使用するだけです。

score 2 · Accepted Answer

独自のソリューションを展開するために、より多くの時間とお金を費やすことになり、それが安全であるという確信が持てなくなります。業界標準の SSL は実装が簡単で、独自のソリューションを作成するよりもはるかに安全です。

時間 == お金

証明書を購入して、安全なログインフォームの代わりにアプリケーションの作業に時間を費やしてください。

score 1 · Accepted Answer

さて、これがあなたが必要とする唯一の答えです：あなたの銀行はSSL経由のログイン/認証のみをサポートしています。それを行うためのより良い方法があれば、彼らはそうするでしょう。

score 1 · Accepted Answer

このようなことを行うための Web/モバイルアプリを公開しました。HTTPS とデータベースストレージのハッシュ/AES 暗号化方式を使用して、ログイン用のランダムな URL を作成します。UI なしで使用するためのシンプルな JSON API があります。

score 0 · Accepted Answer

あなたは独自の暗号化とソルトを行うことについて言及しました... javascript md5を使用することをお勧めします（ヤフーでも非 SSL ページで使用されているか、そう主張しています）...

そして、パスワードを二重にハッシュします...パスワードを二重にハッシュすると、衝突攻撃を受けやすくなると主張する人もいるかもしれません。これまで、大量のデータが md5 されているファイルに対してのみ md5 署名の衝突を行うことができたので、私は反対しなければなりません...

それが大企業の Web サイトである場合 (侵入する理由がある場合)、SSL を使用しない言い訳はありません。

security - HTTP経由でWebフォーム認証データを送信するための最良の方法は何ですか？

10 に答える 10

Related

Reference