web-dev-qa-db-ja.com

API認証、ワンタイムトークンVSダイナミックトークン

私たちは新しいプロジェクトに取り組んでいます。私たちは2人のリード開発者であり、トークンを使用してサーバーとクライアント間の通信を保護する方法についての岐路に立っています。

最初の提案：（1回限りのトークン、つまり静的トークン）

  1. ユーザー名とパスワード、およびcurrent_time（この変数はサーバーのデータベースとクライアント側にも保存されます）をAPIに送信することにより、クライアントはプライマリトークンを要求し、サーバーは入力を解釈してハッシュトークンをレンダリングします（例： 58f52c075aca5d3e07869598c4d66648）はデータベースに保存し、クライアントに返します。

  2. これで、クライアントはプライマリトークンを保存し、プライマリトークン+認証要求で送信されたcurrent_time変数を使用して新しいハッシュトークンを作成します（この新しいトークンmain_tokenを呼び出します）。サーバーも同じことを行い、同じアルゴリズムを使用して同じトークンを作成します。 。

  3. クライアントがサーバーAPIにクエリを送信するたびに、サーバーはmain_tokenをサーバーに送信し、サーバーはその中で生成されたトークンをクライアントが送信したmain_tokenと比較します。一致する場合、ユーザーは本物であることを意味します

2番目の提案：（動的トークン）

  1. クライアントは2つのランダムキーを生成します（$ key1 = Rand（10000,90000）; $ key2 = Rand（10000,90000）;）APIでの各リクエストで、クライアントはクエリタイプを使用してハッシュを作成し、2つのキーを使用して複雑なアルゴリズム。これら2つのキーとハッシュをサーバーに送信します

  2. サーバーは、クライアントで使用されているのと同じアルゴリズムを使用して、ハッシュを作成し、クライアントから送信されたものと比較します。一致する場合、サーバーはクエリの処理に進みます

さて、問題は、APIリクエストを保護するために使用する最も論理的で安全な方法はどれかということです。

securityapi
13
SAFAD

私は一般的に最初のアプローチが本当に好きです。

  • 理解して実装するのは簡単です
  • 安全です（私の知る限り）
  • それは私が過去に使用されたのを見た珍しいアプローチではありません

最初に覚えておくべきことの1つについて、覚えておくべきことは1つあります。トークンのハッシュに使用するタイムスタンプには、TTL有効期限が非常に短い（1秒など））必要があるため、メッセージが12時間前に同じタイムスタンプとトークンで送信されていないことを確認します。明らかに、正当なものとして計算されますが、この場合はそうではありません。

これらがあなたが検討している唯一の2つのオプションである場合、私は他にも多くの方法があるので、他のアプローチも検討したことを確認したいと思います。実際にリストアップする以上のものです。これらはいくつかの一般的なauthアプローチであり、目的に適しているかどうかを確認するためだけに検討する価値があります。他に何も理解していない場合は、どのアプローチを強化するためのアイデアも得られます。

注意してください、私はセキュリティの専門家ではありませんではありません。

OAuth /フェデレーション

このアプローチでは、サードパーティの保証人がいて、使用するコードがトークン/証明書/何を持っているかをリクエストし、それをあなたに渡します。この時点で行う必要があるのは、与えられたキーが合法。

プロ：

  • 標準ベース
  • 他の人のシステムで他の人が問題を発見するので、不安が発生するかどうかを確認できます
  • あなたが必要とする認証作業ははるかに少ない

短所：

  • サードパーティのサービサーとそのAPIを処理するか、独自の「サードパーティ」を作成してホストし、メインサービスから認証を分離する必要があります。
  • 多くのサービスについてはやりすぎですが、概念的には検討する価値があります

非同期証明書

ここでは、クライアントがユーザーを作成したときに共有した公開証明書を使用して、クライアントに通信を暗号化させます。あなたの側では、そのユーザーに関連付けられた秘密鍵を使用して復号化します。一般に、チャレンジレスポンスを使用して通信を開始し、暗号化/復号化できることを示します。チャレンジ/レスポンスを使用しない「同期」アプローチも可能ですが、セキュリティが少し低く、時間同期の問題があり、トリッキーになる可能性があります。

から Novell （ええ、私は知っています、小説？本当に？）

トークンは、ワンタイムパスワードを生成するための基礎として変数を使用します。この変数はチャレンジと呼ばれます。パスワードの生成に使用される変数を決定するための2つの主な方法は、非同期または同期です。

非同期またはチャレンジ/レスポンス方式では、サーバーソフトウェアはトークンデバイスに暗号化するための外部チャレンジ（ランダムに生成された変数）をトークンに送信します。トークンは、このチャレンジ変数、暗号化アルゴリズム、および共有シークレットを使用して、応答、つまり正しく暗号化されたパスワードを生成します。

同期方式では、パスワードの生成に使用されるチャレンジ変数は、トークンとサーバーによって内部的に決定されます。各デバイス内の時間カウンター、イベントカウンター、または時間とイベントカウンターの組み合わせが、チャレンジ変数の基礎として使用されます。トークンとサーバーはそれぞれ個別に内部的にチャレンジ変数を独自のカウンターから決定するため、タイムカウンターとイベントカウンターの同期を維持することは非常に重要です。サーバーとトークンが同期しなくなるのは非常に簡単であるため、ほとんどの実装では、カウンター間で一定量のドリフトを許容しています。通常、これらのカウンター値の小さな範囲またはウィンドウがパスワードの計算に使用されます。ただし、トークンとサーバーがこのウィンドウを超えて同期しなくなった場合は、それらを同期するための特別な手順が必要です。

プロ：

  • 証明書にはCAルートがあり、信頼でき、偽造が困難です
  • オペレーティングシステムには、証明書ストアを簡単に管理および維持するための標準機能があります。
  • よく研究されたアプローチ、それに利用可能な多くの情報
  • 有効期限は他のさまざまなものと一緒に標準証明書の組み込み機能であり、一般的に堅牢です

短所：

  • 証明書はプログラムで操作するのが難しい場合があります
  • 外部CAが必要かどうかによって、無料ではない場合があります
  • 予想されるルート信頼が構成されていることを確認するために、証明書ストアを手動で保守する必要がある場合があります

NTLM

これが小規模なサービスまたは内部のみのサービスであり、Windows環境を使用している場合は、標準のNTLM認証を使用してアクセスを保証しても問題はありません。特にIISを使用している場合、これは最も簡単なアプローチです。web.configでの保守と設定も簡単です。

プロ：

  • 構成、実装、保守が非常に簡単

短所：

  • 最小限の相互運用性
  • 一般向けの認証には不十分

ノンス

認証アプローチでナンスを使用する場合、サービスでナンスを取得するメソッドを提供します。このメソッドは、リクエストごとに一意の任意の文字列またはデータ（「ノンス」）を返します。他のメソッドへのすべてのリクエストでは、ナンスを取得して、リクエストの暗号アルゴリズムで使用する必要があります。ここでの価値は、サーバーが使用されたナンスを追跡し、ナンスの再利用を決して許可しないことです。これにより、1つのナンスを含む要求が作成されると、そのナンスを含む要求を再び行うことができないため、リプレイ攻撃を完全に防ぎます。ナンスが要求されると、それらは使用可能なナンスのリストに追加され、使用されると、使用可能なリストから使用済みリストに移動されます。ナンスを生成するときは、生成したものが使用済みリストに含まれていないことを確認してください。使用可能なリストには古いリストが1つもないため、繰り返しはできません。

プロ：

  • リプレイ攻撃をうまく阻止する
  • 実装も理解もまったく難しいことではない

短所：

  • クライアントが1つの要求ごとに2つの要求を行う必要があります（ただし、certain要求のみにナンスを要求することで軽減できる場合があります）
  • ナンスの管理が必要であり、トランザクションである必要があります
  • Nonceに対する追加の要求を要求することにより、パフォーマンスに悪影響を及ぼします（トランザクションはnonceでの作業のリソースコストをさらに増加させます）
14
Jimmy Hoffa