従来のASPとASP.Netの間のログインシステムの共有

Question

クライアントは従来のASPを使用してWebベースのバックオフィスにログインします。

私はバックオフィスに新しいASP.Netアプリケーションを作成しました。既存のログインシステムを利用する必要があります。そのため、ログインしたときに再びログインする必要はありません新しいASP.Netアプリで。

ログインとパスワードは、ASP.NetアプリケーションからアクセスできるSQL Serverデータベースにクリアテキストとして保存されます。

これらのシステムを統合する効果的な方法は何でしょうか？

現時点でのベストアイデアは です。私のASP.Netアプリケーションへのリンクでは、ユーザーIDとハッシュパスワード+共通シークレットをクエリ文字列に持つ「ゲートウェイ」ログインページにリンクします。私はこれをデータベースのユーザーのパスワードと比較します...しかし、問題は、このクエリ文字列が傍受されると、実際にユーザー名とパスワードを知らずにasp.netサイトにアクセスすることができるということです。

私はおそらく単純なものを見落としています。

Answer 1

あなたのアイデアは正しい道にあると思います。

古典的なaspとasp.netは同じセッション状態を共有できないため、一方から他方にログオンするメカニズムが必要です。

私は誰かがログインするときに、そのユーザーのデータベースに保存する一意のGUIDを作成します。あるサイトから別のサイトにジャンプするときは、そのGUIDをクエリ文字列に渡します。それらを別のサイトに自動ログオンしようとすると、そのGUIDを参照して、誰にも接続されているかどうかを確認します。そうであれば、ログインしてください。

このようにして、ユーザーが推測または解読できるものはすべて渡しません。

Answer 2

従来のASPシステムはどのようにログイン状態を維持していますか？ "ピギーバック"は、これまでのところ、あなたの最良の賭けになるでしょう。

私が取り組んだ従来のASPシステムでは、認証情報を追跡するためにCookieが使用されていました。そのため、これらを読み、アクセスできるデータベースと比較するだけです。

---

情報はクラシックASPセッションに格納されているように、あなたは新しいモジュールへの「入り口」であるものの古典的なASP側に「ページをリダイレクトする」を追加し、これを書くために引き起こす可能性があります有用なデータをクッキーとして使用したり、スタートページにPOSTをトリガしたりできますか？クッキーやPOSTリクエストを使用することで、誰かがユーザー名/パスワードなしでASP.netサイトにアクセスできるようにするために、URLを「ハイジャック」させる心配が最小限に抑えられます。

Answer 3

フォームを介して提出することはできませんでしたか？それは、URLで傍受される可能性を排除します。

Answer 4

インターセプトが重大な問題である場合は、HTTPS経由でサイトを実行する必要があります。さもなければパスワードによってハッシュされるUserID + Nonceを使用することは相当に強力です。

また、ログインが完了したらGUIDセッションCookieを追加し、そのGUIDをDBテーブルに格納することができます。 ASP.NETはログオンが達成されたかどうかを確認するためにCookieからGUIDを検索できます。テーブルにASPセッションCookie値を含める場合、現在のASPセッションがGUIDの作成時に使用されたものと同じセッションであることを合理的に確認できます。

Answer 5

おそらく、DNSキャッシュポイズニングなどによって、MITMタイプの攻撃が心配です。状況に応じて、アプリケーションの境界を越えて渡されるログイントークンに時間制約を追加することで、潜在的な影響を緩和するだけで十分です。

「データベースアプローチのGUID」は、同じ認証データベースを共有する2つのアプリケーション間でユーザーを渡すため、また「パスワードリセットの電子メール」タイプのシナリオでも過去に成功したものです。レコードにGUIDが追加された日付を指定する列を追加し、x分/時間/日未満のGUID認証のみにログインするようにアプリケーションコードを変更することで、これを期限切れにすることができます。他のアプリケーションであなたのアルゴリズムを複製および生成された2つの値を比較し、その後、その後、それをハッシュ..

UserId + [Value representing current time to nearest x minute/hour /day] + Salt 

：

代替のようなものを連結することで、データベース内の追加のフィールドを避けるためである可能性があります。

一般に、あなたの提案された解決策は問題に適していると思います。確かにそれほど複雑ではありません。