2017-10-09 23 views
1

プレーンテキストとしてパスワードを送信、WebクライアントへのHttpClientから変更普通のユーザー名とパスワードを送信しますか?もしそうなら、セキュリティを高める方法はありますか? (URLはHttpsアドレスです)私が使用する非同期メソッドのHttpClientを持って

+0

FYI [あなたはHttpClientを間違って使用しています](https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/)。 – maccettura

+0

@maccettura Oooo ...興味深い。ありがとう! – Yasskier

+0

HTTPSの使用であり、資格情報を保護するライブラリではありません。とにかくBase64エンコーディングは保護されていません。 – Crowcoder

答えて

0

はいプレーンテキストのユーザー名とパスワードを送信することで妥協しています。あなたは、あなたがhttpを介して送信してそれらを読むパッケージを拾うことができるネットワークスニファがあるかもしれません。ユーザー名とパスワードが平易な場合は、ああ、ああ。スニファは通常図書館や喫茶店のような公共の場所で嗅ぐ。

+0

あなたのソリューションは....でしょうか? – Yasskier

+0

あなたは正しいですが、WebClientとHttpClientの関係はありません。 – Crowcoder

+0

ソリューションはあなたがシークレットを使用して記述したもので、アルゴリズムはあなたの秘密を使って暗号化し、受け取ったときに復号化します。 – sdfbhg

1

いずれの場合も、資格情報を「プレーンテキスト」で送信します。どちらの場合も、送信前にベース64に変換されますが、これでセキュリティが強化されるわけではありません。唯一の違いは、2番目(Webクライアント)のWebクライアントでは、まず資格情報なしで要求を行うという点です。その後、401 Unauthorizedレスポンスが返され、その後は全く同じAuthorization Basic <base64_here>ヘッダーで2回目のリクエストが行われるため、すぐにそのヘッダーを適用するより効率的ではありません。しかし、再び両方のケースで全く同じAuthorizationヘッダーが送信されます。すでに述べたように、httpsエンドポイントへのリクエストを行う場合、クレデンシャルはサードパーティによる傍受に対して安全でなければなりません。既に暗号化されたチャネルを使用している場合は独自の暗号化を実装する必要はありません。

関連する問題