ASP.NET FormsAuthenticationクッキーのコピーを別のマシンに再作成し、2台目のマシンがログインする必要なく認証できるようになったことに気づきました。ASP.NET FormsAuthenticationクッキーをセッションIDに関連付けると、より安全にすることはできますか？
これを解決するには、セッションIDはFormsAuthenticationTicket.UserDataになり、2つの値がApplication_AuthenticateRequest()に一致することを確認してください。
我々が使用している：
FormsAuthenticationTicket.IsPersistent = false;
は、セッションIDは良いアイデアををFormsAuthenticationクッキーを関連付けるこのアプローチですか？
私はあなたがこの問題を思い描いていると思います。クッキーをコピーする機能は、クッキーの固有の問題です。だれかがクッキーを傍受し、他のマシンに設定することでそこにあるデータを偽装することができます。
認証クッキーの「セキュリティ」は、認証されたユーザーを偽造するために誰も（おそらく）クッキーを手作業で作ることができないという事実に由来します。しかし、いったんクッキーが作成されると、それはもちろん認証に使用することができます。これは、あなたの "問題"が起こるためには、有効なユーザーログインが最初に必要であることを意味します。そのユーザーが他のマシンに自分のクッキーをコピーしてシステムに悪用している場合、誰もがアクセスできるようにすることはまったく同じことです。したがって、問題はCookieのコピーではなく、ユーザー自身です。
ネットワークが侵害され、誰かがトラフィックを傍受してスニッファーなどを介してCookieをまとめることができますが、これはCookie自体に固有のものです。これはセッションハイジャックと呼ばれ、これに対して守る唯一の方法は、サイトでSSLを使用することです。
本当に心配な方は、認証とセッションのタイムアウトを同じにしてから、global.asaxファイルで、セッションが終了するたびにFormsAuthentication.Signout（）を呼び出してください。これにより、ユーザーがセッションを完了したときに認証が無効になり、後で再度ログインする必要があります。もちろん、これはあなたのユーザーに極端な迷惑であるかもしれません...
私はまた、This MSDN articleをお勧めします。それはおそらくあなたの質問に私ができるよりもはるかに優れています。
あなたの答えをありがとう - 実際には私が考えていたラインに沿っていましたが、実際に問題ではないものを修正しようとする前に第二の意見を求めました。 あなたの提案されたFormsAuthentication.Signout（）は、私のケースでは、とにかく認証Cookieがセッションの最後に期限切れになるため、ユーザーに新しいセッションごとにログインさせるようには思われません。または私は何かを逃したか？ – tjrobinson
ユーザーのマシンが自分のCookieを盗むウイルスに感染するケースはどうですか？ SSLはそれらを保護しません。私はそれがセッションハイジャックのバリエーションだと思う。 – tjrobinson
Re：最初のコメント。私はあなたが何かを逃したとは思わない。私はそれについてもっと昨夜考えて、あなたのIPアドレスや何かのような認証チケットにいくつかのユーザーデータを設定しようとすると、その情報が変更された場合、それらを自動的にログアウトすることができると考えました。そのため、別のマシンが偽装するのが難しくなります...しかし、IPアドレスも偽装することができます。それは少しでもより安全です。 Re：2番目のコメント - うーん、まったく別のバリエーションです。 – womp
実際に試したことはありますか？他のマシンからのクッキーを使用して実際に別のマシンのログインがありましたか？セッションごとの暗号化があると思いました。 –
同僚が試しました。暗号化が設定されているかどうかわかりません。 – tjrobinson