私はセキュリティの専門家ではないので、私が考案した認証スキームに大きな穴を開けてくれる人を探しています。または、同じ目標を満たすより優れた既存のスキームを教えてくれる人を探しています。
問題の概要
クライアントがセッションのライフサイクルを維持するインターフェイスがあります (これは Web サーバー上の HTTP セッションですが、実際には問題ではありません)。
ステートレス サーバーは、呼び出し元の認証を必要とするいくつかのサービスを提供します (サーバーにはこの認証を実行する機能があります)。
ただし、サーバーが各呼び出しで呼び出し元を認証する必要がないことが望ましいです。たとえば、各呼び出しで資格情報を渡すことによってです。(認証プロセスにはコストがかかる場合があります。)
サーバー上でセッション状態を維持しないことも望ましいです。1 つには、クライアントとサーバーの両方で独立したセッション タイムアウト (クライアントのセッション タイムアウトを取り除くことはできません) を持つ脆弱なソリューションを求めているだけであり、信頼できるセッション ライフタイムを維持するにはサーバー タイムアウトが必要なようです。サーバー上で (適切な時間に明示的にセッションを終了するためにクライアントに依存するのではなく)。別の理由として、サーバーはこの種の状態を保存するように設定されていません。
サーバーには明示的なauthenticateメソッドがあります。問題は、別のメソッドが呼び出されたときに、サーバーにセッション状態を保存せずに、呼び出し元がそのメソッドを使用して以前に認証されたことをサーバーがどのように確認するかということです。authenticate
提案された解決策
これが私が思いついたスキームです：
このauthenticateメソッドは、資格情報を入力パラメーターとして受け入れます。認証が成功すると、サーバーは次の 2 つを返します。
- 認証が実行された時刻を示すタイムスタンプ。
- 秘密鍵で暗号化された、{ユーザー名、タイムスタンプ}のタプルの暗号化バージョン
その後のメソッド呼び出しでは、クライアントはこれらの値の両方をサーバーに返します。次に、サーバーは暗号化された { ユーザー名、タイムスタンプ } タプルを復号化します。復号化されたタイムスタンプがクライアントから送信された暗号化されていない値と一致する場合、サーバーはクライアントが以前に認証されたことを認識します (有効な暗号化された値を取得する唯一の方法であるため)。復号化されたユーザー名は、どのユーザーが認証されたかをサーバーに伝えます。
暗号化されたキーの有効期間は、現在の時刻からx時間以内のタイムスタンプのみを許可することで適用できます。これはセッション タイムアウトと同じではありませんが、侵害されたタイムスタンプが悪意のある人物によって使用される可能性があるウィンドウを制限します。
そう
このスキームは多くの点でナイーブなのではないかと心配しています。どのような弱点や悪い論理が見られますか?