前回の記事で、Zix|AppRiverはSolarWinds攻撃の責任者がどのようにして感染チェーンの一部としてトークンと証明書を悪用したかを議論しました。 悪意のあるアクターは、他のエンティティをターゲットにした追加のキャンペーンで、同じ種類の資産を悪用しました。 これにより、電子メールセキュリティプロバイダーで証明書セキュリティインシデントが確認されました。
これらの悪意のある活動を認識し、Zix|AppRiverは、影響を受ける認証方法の種類とその仕組みについて議論する一連の記事を顧客に提供する必要があると感 まず、トークンベースの認証から始めます。
トークンベース認証:概要
トークンベース認証は、セッションベース認証のいくつかの制限に対処します。 後者では、サーバーはユーザーがログインするときにセッションを作成します。 これは、ユーザーがログインしたままである場合、後続のすべての要求に付随するcookieにセッションIDを格納します。 次に、サーバーは、cookieをメモリに格納されたセッションデータと比較することによって、ユーザーのidを検証します。
ここでの問題は、セッションベースの認証には特定の欠点があることです。 まず、サーバーがセッションをメモリに格納する必要があります。 また、異なる媒体（webやモバイルなど）の複数のデバイスでcookieが機能するという問題もあります。
それがトークンベースの認証の出番です。 この形式の認証には、一連のユーザー資格情報の検証時に署名付きトークンをクライアントに提供するアプリケーションが含まれます。 クライアントはそのトークンを保存し、要求ごとに送信し、その時点でサーバーはトークンを検証して情報を送信します。
この意味で、トークンベースの認証は、ステートレスであるという点で、セッションベースの認証とは異なります。 ユーザーに関する情報をサーバーやセッションに保存することはありません。 そのデータはクライアント側のトークンに格納されます。
トークンベース認証の利点と課題
トークンベース認証には多くの利点があります。 Chop-Chopは、トークンは異なるウェブサイトや媒体でも機能し、特にモバイルデバイスを使用しているユーザーの多様性を高める機会を作り出していると指摘しています。 トークンを侵害したユーザーは、影響を受けるユーザーのアカウント資格情報に自動的にアクセスすることはありません。
そうは言っても、トークンベースの認証には課題がないわけではありません。 Devbridge Groupは、セッショントークンの中には、たとえば安全な方法で生成されないものがあると指摘しています。 これにより、セッションIdのサンプルが十分に大きい攻撃者がパターンを把握し、より大きなユーザープールのトークンを推測することが可能になります。 また、攻撃者が安全でないトークンストレージ、複数のログイン、および/または長いトークン検証時間を活用して認証秘密を盗むという問題もあります。
トークンベース認証を安全に使用する方法
上記のリスクを認識して、トークンベース認証を安全に使用するためのいくつかのベストプラクティスを:
- 強力なトークンを生成します。 特に、Devbridgeは、トークンが可能な値の大きなセットを特徴とし、ある程度の擬似ランダム性を組み込み、少なくとも16バイトの長さで構成することを推奨し
- トークンに有効期限を与えます。 トークンが有効である期間の条件を設定することが重要です、Auth0に注意してください。 明らかに、ユーザーがまだアクティブな場合、トークンは自動的に更新できます。 しかし、ユーザーがログアウトし、一定期間が経過した後にトークンを終了したときにトークンが期限切れになることを許可することにも知恵があります。
- 複数のログインを禁止します。 Devbridgeが指摘しているように、キー属性を使用して、複数の人が同じユーザーアカウントと同時に対話している並列認証を防ぐことができます。
- ローカルストレージはここに行く方法ではありません。 開発コミュニティは、クロスドメイン要求でcookieを渡すことができる条件を指定するために、SameSiteと呼ばれるcookieポリシーを使用することをお勧めします。 厳密なSameSiteポリシーと、この機能をサポートするブラウザのバージョンが必要であるという要件は、セッショントークンを安全に保つのに役立ちます。