署名アルゴリズムに基づくシンプルで安全なAPI認証メカニズム

[[384489]]

広告システムに取り組んでいたとき、接続されたプラットフォーム上のほとんどの広告システムはトークンを使用してインターフェースを認証しており、このトークンは常に変更されず、広告主によって提供されていることに気付きました。これはネイキッドインターフェースと言えますが、このタイプのインターフェースには高いセキュリティ要件はありません。悪意のある呼び出しを防ぎ、チャネルの身元を確認することしかできません。

昨年、私は API 統合認証プラットフォームを作成しました。これは、サードパーティのシステム コールに対する内部サービス インターフェイスの統合認証管理を提供します。インターフェイス認証の管理を容易にする以外に用途はありませんが、導入にはコストがかかります。これはおそらく私がこれまでに行った中で最も無意味なプロジェクトです。

今回紹介したAPI認証メカニズムも、広く使われているAPIインターフェース認証メカニズムかもしれません。私がWeChatの支払い機能に取り組んでいたとき、WeChatが提供する支払いインターフェースもこの署名方式を採用していたことを思い出しました。利点: シンプル、パフォーマンスに影響なし、追加コストなし。

この認証方法の実装ロジックは、認証者が各アクセス プラットフォームに対して一意の ID (キー) と独立したキー (実際にはアカウント パスワードに相当) を設定するというものです。アクセス システムは、リクエストを開始するたびに、リクエスト ヘッダーに 3 つのパラメータ (ID 識別子 (キー)、リクエストのタイムスタンプ、署名) を含める必要があります。承認システムは、リクエストを受信すると署名を検証し、検証に合格した場合にのみリクエストをリリースします。

署名を検証するプロセスは、リクエスト ヘッダーからキーとタイムスタンプを取得し、同じアルゴリズム (呼び出し元と承認された当事者が同じ署名アルゴリズムを使用) を通じてキーに基づいて署名を生成し、最後にリクエスト ヘッダーから取得した署名が等しいかどうかを比較することです。等しい場合は検証は成功し、そうでない場合は検証は失敗します。

署名アルゴリズムに基づく認証方式の実装プロセスは次のとおりです。

承認者:

1. 署名アルゴリズムを定義し、署名生成アルゴリズムをアクセスパーティに提供し、アクセスパーティのキーと ID を生成します。

2. プロジェクト内の署名を検証する必要があるインターフェースを傍受し、リクエスト ヘッダーからタイムスタンプと ID を取得し、キーと署名アルゴリズムに基づいて署名を生成し、生成された署名をリクエスト ヘッダーから取得した署名と比較します。同じ場合は手順 3 に進み、そうでない場合はリクエストを拒否します。

3. リクエストの適時性を確認します。現在のシステム タイムスタンプとリクエスト ヘッダーから取得したタイムスタンプを比較します。リクエストが有効な時間範囲内であれば、リクエストは解放されます。それ以外の場合は、リクエストは拒否され、応答署名は期限切れになります。

アクセスパーティ:

1. 権限のある当事者から接続文書を入手し、権限のある当事者にキーと ID を要求します。

2. 文書で提供される署名生成アルゴリズムに従って署名方法をカプセル化する。

3. リクエストを開始するときに、ID、現在のタイムスタンプ、および署名をリクエスト ヘッダーに書き込みます。

署名生成アルゴリズムは、ID 識別子 (キー)、タイムスタンプ (タイムスタンプ)、およびキーを連結し、MD5 アルゴリズムなどの不可逆なアルゴリズムを使用して文字列を暗号化して署名を生成するなど、カスタマイズできます。ルールが複雑になればなるほど、破るのが難しくなります。

署名とタイムスタンプの利点は何ですか?

1 つは、署名にタイムリーさを追加することです。認証システムは、要求のタイムスタンプをシステムの現在のタイムスタンプと比較し、署名の有効期間を 1 秒または 5 秒に制限できます。ただし、双方のシステム時刻は正確でなければなりません。

2 つ目はセキュリティです。ハッカーがシステムからのリクエストを傍受し、リクエストを変更して再度リクエストを開始すると、間違いなく時間がかかります。そのため、システムが改ざんされたリクエストを受信すると、署名の有効期間は終了しています。リクエスト ヘッダーで渡されたタイムスタンプが変更されると、認証システムによって生成された署名はリクエスト ヘッダーで渡された署名と異なるものとなり、リクエストは無効になります。

承認者（ゾンビ）システムの署名ルールを知っていても、キーがわからない場合は有効な署名を生成することはできません。また、署名には非対称暗号化アルゴリズムが使用されているため、ブルートフォース攻撃でキーを解読することはほぼ不可能です。

では、フォーマットされた時間文字列の代わりにタイムスタンプを使用するのはなぜでしょうか?

これは、タイム ゾーンの互換性を考慮したためである可能性があります。異なるコンピュータ ルームが異なるタイム ゾーンにある場合、時刻は異なりますが、タイムスタンプは同じになります。

この認証方法のセキュリティを確保するには、まず、署名を生成するためのルールが十分に複雑でなければならず、次に、署名の暗号化アルゴリズムが不可逆で、Base64 などのアルゴリズムを決して使用しないことが必要です。最後に、署名生成ルールがわかっていても、ブルート フォースでキーを解読することが不可能であるように、キーは十分に長く複雑でなければなりません。

署名ルールとは、キー+キー+タイムスタンプ+キー+キーなどの、暗号化前に署名文字列を生成するルールを指します。キーが「app」、秘密キーが「123」、タイムスタンプが「11111111111111」と仮定すると、暗号化前の署名は「app1231111111111111app123」となります。最後に、連結された文字列を暗号化アルゴリズムで暗号化して、最終的な署名を生成します。

インターフェースごとにシグネチャロジックを書くのは面倒ではないでしょうか？

不要。承認された当事者にとって、署名検証ロジックはフィルターまたはインターセプターを通じて完了できます。呼び出し元にとって、さまざまなフレームワークを使用したさまざまな方法がありますが、署名ロジックを 1 回だけ記述する方法を常に考えることができますよね?

この記事はWeChatの公開アカウント「Java Art」から転載したものです。以下のQRコードからフォローできます。この記事を転載する場合はJava Art公式アカウントまでご連絡ください。