web-dev-qa-db-ja.com

JWT更新計画は安全ですか?

モバイルデバイスのログインシステムにJWTを使用する予定です。見つけることができるJWTトークンを更新するための実際の標準ワークフローはないため、以下のワークフローを作成しました。 JWTを使用する理由は、パフォーマンス上の理由によるものです。ユーザーが有効かどうかを確認する代わりに、JWTを信頼するすべてのリクエストに対してデータベース呼び出しを行います。

アプリに実装したいワークフローの提案があります。これは十分に安全ですか?効率的ですか?私が監督している明らかな問題はありますか?どのような合理的な改善を行うことができますか?

ユーザーがログイン

  1. HMAC署名済みトークンがlocalstorage内に存在しない場合、ユーザーはデバイスに名前を付けます。
  2. DeviceNameはサーバーに送信され、データベースに挿入されます。
  3. JWTトークン+ DeviceNameのHMAC署名済みトークンがユーザーに返送されます。 HMAC署名済みトークンが配置され、jwtトークン(DeviceNameを含む)が最初に呼び出されたのと同じデバイスから送信されていることを確認します。
  4. JWTトークンはX時間有効であるため、ユーザーはX時間の間すべての呼び出しを行うことができます。
  5. X時間後、JWTは期限切れになります。リクエストが行われると、サーバーはJWTが期限切れであることを確認できます。サーバーはJWTトークンの更新を試みます。サーバーはデータベースをチェックして、HMAC署名済みトークンで指定されたDeviceNameが、そのユーザーのデータベース内の有効なデバイス名と同じかどうかを確認します。
  6. ある場合は、さらにX時間有効な新しいJWTを作成します。ない場合は、メッセージを返信してログインを要求します。

アカウントが侵害された場合:

ユーザーは私のパスワードサービスにログインできます。ログインしたら、そのユーザーのすべてのデバイスを取得し、ユーザーは侵害されたデバイスを取り消すことができます。これが完了すると、JWTを更新する要求は、盗まれたトークンでは機能しなくなります。

もちろん、これはすべてSSLを介して行われます。

私の解決策がない私の懸念:

  • JWTトークンが盗まれた場合、攻撃者は被害者に基づいて電話をかけるのにX時間かかります。これはトークンの性質であり、リスクとして受け入れられていると思いますか?

  • JWTが盗まれた場合、デバイス名を含むHMACトークンもハイジャックされる可能性が高いため、被害者が自分のアカウントが侵害されていることを認識し、アクセスを取り消すまで、ユーザーはトークンを更新できます。これは受け入れられている習慣ですか?

20
user2924127

何の領域で安全に受け入れられますか?

すべての無記名トークンの基本的なフローについて説明しました。トークンを所持する者は力を持っています。トークンが取り消されたかどうかを確認する条件がありますが、それはトークンが期限切れになるか取り消されるまで有効であることを意味します。これは、ユーザーがデータベースで有効かどうかを確認することと基本的に同じですが、ユーザーをデバイス+ JWTに置き換えます。それは問題ありませんが、パフォーマンスはそれほど向上しません。

他のシステムは2つのJWT(またはJWTと不透明トークン)を使用します。最初のJWTは、説明したように使用されるアクセストークンですが、失効をチェックしません。このトークンは非常に短命です-おそらく20分-> 1時間であり、それからかなり長く存続するリフレッシュトークンがあります。アクセストークンの有効期限が切れたら、更新トークンを送信し、更新トークンがまだ有効な場合は、新しいアクセストークンを発行します。更新トークンの有効期限が切れている場合は、認証を再度強制するか、新しいアクセスと更新トークンを発行するだけです。

ここでの値は、データベースに対して更新トークンを検証するだけでよく、アクセストークンの有効期限が切れたときにのみ検証する必要があるということです。ユーザーが更新トークンを失効としてマークした場合、更新トークンは攻撃者に新しいアクセストークンを取得しません。

トレードオフは、データベースへのクエリを頻繁に行わないことですが、アクセストークンが有効である限り、攻撃者は何でも実行できます。これは、非常に短いトークン(オッズのゲーム)を使用することで軽減されます。これが許容されるリスクかどうかは完全にあなた次第です。リスクを受け入れるかどうかは決定しません。 :)

21
Steve