ASP.NETページが通信するサービス（WCF）があります。 WCFサービスは、データストア（実際にはファイル）にパスワードをハッシュしています。 WCFサービスでは、すべての呼び出しでユーザー名とハッシュされたパスワードが必要です。ユーザー名とパスワードの格納ASP.NET認証
Nowm私が遭遇する問題は、ASP.NETでフォーム認証を使用してユーザーを認証すると、ユーザーが認証された後にCookieがユーザーのコンピュータに保存されますが、ユーザー名とハッシュ値ユーザーがWCFサービスを使用できるようにパスワードも設定してください。この情報は安全で安全な場所に保存する必要がありますか？
セッション変数を使用する必要がありますか？そのオプションを選択した場合は、フォームベースの認証からセッション変数を使用して手動で認証するか、または Webページへのアクセスにフォームベースの認証を使用し、セッション変数にユーザー名とハッシュパスワードを格納する必要がありますか？それぞれの長所と短所は何ですか？
ユーザー名とパスワード（ハッシュされたもの）を別のクッキーに保存できますか？通信するたびに、Cookieを取得し、ユーザー名とともにWCFサービスに送信します。
WCFサービスの終了時に、ユーザー名とハッシュされたユーザー名とパスワードの組み合わせがあります。同じハッシングを適用する場合は、WCFの最後に格納されているのと同じ文字列で終わる必要があります。一致した場合は有効です。あなたの編集へ
よろしく：
ないあなたが提案しているとして、それらの間の区別の多くがあることを確認してください。フォーム認証を使用すると、セッション変数が作成され（クッキーを使用していると仮定して）、セッション変数をユーザーに関連付けることができるCookieが保存されます。したがって、フォーム認証を使用する場合でも、セッション変数を使用しています。
セッション/ Cookieにユーザーが入力したパスワードのハッシュバージョンを保存する場合は、唯一の質問です。プロは、どこかに格納されており、潜在的にセキュリティリスクが発生する可能性があるということです。
完全に別の方法は、パスワードを送信して各要求に再認証するのではなく、ユーザーのパスワードに関係しない認証トークンを送信することです。代わりにこのトークンを検証します。
トークンは正常なログイン時に発行される可能性があり、WCFと同じハッシュアルゴリズムを使用する必要があります。要求の一部としてユーザー名とトークンを送信し、それが有効で、権限があり、まだ最新であることを検証します。
明らかにクライアント側（クッキー）ではありません。 Cookieを使用して、ASPとセッションIDのユーザーを認証します。これがASP.NETのデフォルトです。セッションにユーザー名とPWを格納するよりも。
セキュリティが強化されるため、Windows認証などの推奨されるメカニズムの使用を検討してください。
@your edit：関連するコントロール（またはASP.NETのその他の事前実装されたメソッド）と共にフォーム認証を使用してください。あなた自身でそれを再実装することは、理由がないのに大きな影響を与えるでしょう - 少なくともあなたが.NET認証と同じ安全性を得たいなら、それは本当にハッシュされたパスワードを比較する以上のものです..！また、これは追加のユーザー関連データを保存するための自然な場所なので、セッションを使用します。セッションは簡単に設定でき、比較的安全です。
クッキーがハッシュされ、有効なユーザー名なしで使用できず、ソルトを知らなくても使用できない場合は、クッキーをクッキーしないでください。 –
があります。なぜなら、安全ではないチャネルに賢明な情報を不必要に公開するからです。私が質問を読む限り、通信はASPページ（サーバー側）とWCFの間でのみ行われます。したがって、クライアントがサービスと直接通信する必要はありません。クライアントは**本当に**必要な情報だけを持っているべきです。 – user492238
ハッシュされたパスワードの代わりにトークンを使用すると、どのような利点があるか詳しく説明できますか？セッションやクッキーのどこかにトークンを保存する必要があります。 – Tux
ユーザーのパスワードを変更せずにトークンを無効にすることはできますが、ユーザーのパスワードはおそらくどこでも使用するものと同じになるでしょう。別のユーザーがユーザーのトークンを侵害した場合、ユーザーのネットバンクにログインする可能性のあるパスワードが破られた場合、APIにアクセスすることができます。 –