記事ディレクトリ
必要な 3 つのインターフェイス認証方法
最近は、L5 [コア] レベル データの関連インターフェイスに取り組んでいます. すべてのインターフェイスのやり取りは、データ セキュリティを確保するために認証および暗号化する必要があります. この機会に、一般的に使用されるいくつかのインターフェイス認証方法を簡単に紹介します。
注: すべて HTTPS TTL に基づいています
認証方法の分類
インターネットの誕生以来、データ/インターフェース認証には何千もの方法がありました。アプリケーションのシナリオや使い方によって、組み込みクラス【SDK】とインターフェースクラス【API】の2つに簡単に分けられますが、もちろん本質は同じです。
SDK
SDK シナリオでは、トークンを使用するのが一般的な方法です。クライアントとサーバーは、AppID、AppSecrit、および動的キーに同意します。
動的キー: 中程度の時間粒度の変更。多くの場合、C\S エンドは長い接続を維持するか、ハートビート検出中にデータ同期と更新を実行します。
トークン認証
- クライアントが起動すると、サーバーは合意された情報に従って暗号化されたフィールドを生成し、それをクライアントに送信します; その後、クライアントは対話するたびに身元認証のためにこのパラメーターを取得します。
- サーバー側は、クリネがアップロードしたデータを受け取った後、以前の制約の下で生成されたキーと比較および検証し、エラーがない場合にのみ後続の対話を実行できます。異常な要求。
現在、一部の大手ブランドまたは高度なセキュリティ要件を持つシナリオでは、これに基づいて対話プロセス中に比較するためのキー フィールドとして AES 暗号化された送信を使用します。これにより、タイムリーなデータがネットワーク伝送中に傍受され、識別および分析できないか、識別および分析コストが非常に高くなり、関連するブラック プロダクションや不正操作が防止されます。
さらに一歩進んで、銀行や、お金と個人情報が関係するシナリオの場合、そのようなインターフェースがトークン認証に成功したとしても、個人確認のために追加の認証が実行されます。たとえば、携帯電話の確認コード、グラフィック チェックなどです。
API
API インターフェイスのシナリオでは、2 者または複数の当事者間に長期的なリンクがないか、定期的なトークン同期メカニズムを追加で確立するコストが高すぎるため、SDK トークンを使用した従来の認証は適していません。
サイン認証
現在、業界での一般的な慣行は、署名検証またはインターフェース ソルティングを実行することです。実際には、これは相互作用する当事者間で合意された一種の静的キーであり、データ送信中、パラメーターは k=v + 反転/順序付けされた形式で編成され、文字列を生成し、最後に静的キーが追加されます. md5、暗号化された文字列。
インタラクションが発生するたびに、受信者は受信したパラメーターに従って同じ方法でキーを生成し、このフィールドに基づいて比較して、データが改ざんされていないかどうか、および要求が不正または異常であるかどうかを検証します。
もちろん、これに基づいて他の変換を実行することもできます。
AES アナモフィック
すぐに使える: AES 対称暗号化での ECB 実装。
ここでは 2 つの方法を紹介します. 1 つは、Web サイトまたは H5 がより一般的に使用され、リクエスト全体が AES 暗号化されることです. ウェブページのアドレスバーに文字化けしたキーの列があり、セキュリティが比較的高いことが示されています。
データ受信者は、合意された鍵を使用して暗号文を解読し、平文パラメータを取得します。しかし、このアプローチには問題があります。
- 送信されるデータ量が多い場合、双方の暗号化/復号化の複雑さが増し、サービスの CPU/パフォーマンスに大きな影響を与えます。
ということで、2つ目の方法「コンボパンチ」です。
暗号化されたデータのサイズを縮小し、コア データのみを暗号化し、非コア データは署名検証のためにプレーン テキストで送信します。
コアデータが不足しているためにサービスが提供できないことが多いため、データ受信者は最初にコアデータを復号化し、その後、すべてのパラメータの署名検証を実行します。もちろん、このような「結合された拳」のセットは、インターフェースとデータのセキュリティをある程度保証できます。
トークン + 記号変形
ここではTokenとSignを組み合わせた変形方法を紹介します。相互作用の両側は、非常に長いキーである「長い文字列」キーに同意します。このキーには、切り捨てポイントとも呼ばれるシードを生成する一連の動的戦略があります。
データがやり取りされると、「長い文字列」キーの特定の部分が同時に動的戦略に従って署名のキーとして使用され、署名検証方法が送信のために編成されます。
動的測定は時間と結び付けられることがよくあります。結局のところ、時間はまれな自己増加データです。
コア データの位置オフセット
導入のこの時点で、場所の移動に関連する方法を突然思い出しました。例えば、送信パラメータが「abc」の場合、送信時に「cde」となり、位置が3ビットずれます。
もちろん、これは単なる例であり、特定のオフセットは適用可能なシナリオと実装に関連しています。
…
もちろん、認証には多くの方法があります。ここでは、一般的なアイデアを提供するだけです。詳細な実装またはソリューションは、後でブログ投稿に追加されます。