2

標準は、次のような認証の課題を解決する必要があります-

リプレイ攻撃 中間者平文攻撃 辞書攻撃 ブルート フォース攻撃 偽造サーバーによるスプーフィング

私はすでにアマゾン ウェブ サービスを見てきましたが、それは 1 つの可能性です。さらに重要なことは、2 つの最も一般的なアプローチがあるように思われることです。

  1. AWS と同様の方法でエンコードされているが、リクエストへのポスト パラメータである apiKey を使用する
  2. Http AuthenticationHeader を使用し、AWS のような同様の署名を使用します。

署名は通常、暗号化された共有シークレットで日付スタンプに署名することによって取得されます。したがって、この署名は apiKey として、または Http AuthenticationHeader で渡されます。

1 つまたは複数のオプションを使用している可能性があるコミュニティから両方のオプションを比較検討し、私が検討していない他のオプションも検討したいと考えています。また、HTTPS を使用してサービスを保護します。

4

2 に答える 2

2

「認証」とは、あなたが本人であることを証明することを意味します

「あなたが誰であるか」は、エンティティのアイデンティティです（人、コンピューターユーザー、ソフトウェア、サーバーなど...）

「ID」は各エンティティに固有の属性です (DBA はここで主キーと言うでしょう)

したがって、何らかの方法でその固有の属性を持っていることを証明する必要があります。ここでのエンティティが HTTP クライアントである場合、HTTP Auth は、サーバーに対して一意の ID (ユーザー名と呼ばれるもので表される) を証明する標準化された方法です。

チャネルのセキュリティに煩わされることはありません。それがプレゼンテーション層 (つまり、SSL) の目的であり、パーツ間の共有シークレットが必要です。「共有秘密」とは、両方の部分がそれを知っている必要があり、他の誰も知らないことを意味します。これは、2 つの部分が秘密を開示しないこと、または開示された場合に適切な措置を講じること (たとえば、秘密の変更) について相互に信頼していることを意味します。

プロトコルとしての HTTP には、承認を行う他の方法が含まれておらず、他のレイヤーに残されています。たとえば、SSL は、公開鍵インフラストラクチャ (証明書と認証機関) を使用して秘密を共有することなく、2 つの当事者の身元を証明できます。

最終的には：

  • 当事者間でシークレットを共有しても問題ない場合は、認証に HTTP Auth を使用し、チャネルを保護するために SSL を使用できます。共有シークレットを安全に交換および保存するかどうかは、当事者次第です。

  • 秘密を共有したくないが、両当事者が共通の信頼できる第三者に同意できる場合は、プレーンな HTTP を話し、SSL を使用して、チャネルを保護し、PKI を使用して一方または両方の当事者の身元を証明することができます (>証明書)

  • 他にも多くの可能性がありますが、この2つは私が考えることができる最も標準的なものであり、既存のHTTPソフトウェア/ライブラリ/そこにあるもののほとんどと互換性があるはずです.

  • 自作システムは、技術的には有効ですが、受け入れられている標準に違反するか、アプリケーション層に実装されたアドホック (したがって非標準) システムになります (別の層で対処する必要がある問題を解決するため)。

共有秘密に同意する (そしてそれを秘密に保つ) か、その一意性 (PKI) を処理するために他の誰かを信頼することに同意することなしに、何かの一意性を証明する方法はありません。それ以外はすべて実装の詳細です。

于 2010-04-08T16:34:04.397 に答える
1

基準が1つあるかどうかはわかりません。存在する場合は、HTTP Auth（BasicまたはDigest）である可能性があります。前述の両方はかなり貧弱な解決策です。

AWSは、「独自のロール」認証ソリューションがどのように機能するかを示す良い例ですが、セキュリティ/認証について話している場合、セキュリティ/暗号でない限り、通常、独自のロールはお勧めできません。達人。

私の好みの選択は、実際にはクライアント側の証明書を使用することです。認証とセキュリティのプロセスを処理します。証明書自体がクライアントユーザーを識別するため、APIキーは必要ありません。

于 2010-04-08T13:29:50.563 に答える