4

私は ASP.NET を使用しています。自分で作成したカスタム認証プロバイダーを使用しています。ハッシュとソルティングが適切に行われているため、比較的安全です。

このように機能するカスタム認証セッションメカニズムも実装しました。

  1. ユーザーが Web アプリにサインインすると、パスワードは mssql db のデータに対して検証されます。
  2. 「sessions」テーブルに新しい行が挿入されます。この行には、ログオンしているユーザーへの参照、認証トークン、および有効期限が含まれています。
  3. 認証トークンは cookie と共に返され、クライアントのコンピューターに保存されます。
  4. 認証トークンは、ユーザーを識別するために使用されます。

それは完全に機能しますが、たとえば誰かがデータベースにハッキングしてユーザー ID を変更したり、認証トークンを取得したりした場合など、潜在的なセキュリティ リスクを確認できるため、それが正しい方法であるかどうかはわかりません。私が間違っている？

PS 残念ながら、組み込みの認証/セッション処理を使用することはできません。これは、顧客が要求したためです。さらに、mysql、oracle/etc などの他のデータベース エンジンをサポートする必要があるため、それを提案しないでください :)

4

1 に答える 1

1

これでほぼ安全だと思います。

データベースを見たときにすべてが危険にさらされるという懸念を軽減するために、これを回避する方法がいくつかあります。複数のサーバーにスケーリングする心配がない場合は、アプリケーションの起動時にキーを生成できます。そして、このキーを使用して各セッションに「署名」します。したがって、次のようなハッシュを作成auth token+server key+expirationし、セッションからの各リクエストでこれを確認できます。

認証トークンを盗むことができる人々に関しては、ここには非常に多くのオプションしかありません。参考までに、これを「リプレイ攻撃」と呼びます。ウェブサイトを煩わしくすることなく防ぐのは非常に困難です (この 1 つのページから 3 つのタブを開きたい場合、リプレイなのでサインインする必要があります) 詳細については、ウィキペディアを参照してください。それは、必要な「安全性」に大きく依存します。

于 2013-02-26T15:49:33.180 に答える