ユーザーにAPIキーとシークレットの両方を提供する多くのAPIに出くわしました。しかし、私の質問は、両方の違いは何ですか？
私の目には、1つのキーで十分です。私が鍵を持っていて、私とサーバーだけがそれを知っているとしましょう。このキーを使用してHMACハッシュを作成し、API呼び出しを行います。サーバー上で、HMACハッシュを再度作成し、送信されたハッシュと比較します。同じ場合、通話は認証されます。
では、なぜ2つのキーを使用するのでしょうか。
編集：またはそのAPIキーはAPIシークレットを検索するために使用されますか？
回答:
秘密鍵暗号化は、同じ鍵を使用してメッセージをエンコードし、後でデコードすることに依存しています。したがって、「秘密」を知っている人だけがメッセージを読むことができます。
RSAセキュリティは、2つの一致するキーに基づいています。ユーザーごとに公開鍵があり、誰もがそれを知ることができます（すべきです）。ユーザーだけが知っておくべき秘密鍵もあります。公開鍵で暗号化されたメッセージは、秘密鍵でのみ復号化できます。その逆も同様です。
したがって、あなただけが読むことができるメッセージを送信したい場合は、（ネットワークから）公開鍵を取得し、その鍵でメッセージを暗号化します。これを復号化できるのはあなただけです。
または、メッセージを送信したことを証明したい場合は、秘密鍵を使用してメッセージを暗号化し、暗号化の方法を（オープンテキストまたは別のメッセージで）伝えます。次に、私の公開鍵を使用してメッセージを復号化できます。メッセージが読み取り可能になった場合は、それが私からのものであることがわかります。
この形式の暗号化はかなりコンピュータを集中的に使用するため、RSAテクノロジを使用して1回限りの「秘密鍵」を暗号化し、残りのメッセージを秘密鍵で暗号化してから、2番目の方法で署名を暗号化することがあります。次に、このプロセスを逆にして、メッセージと署名が読み取り可能である場合、あなたとあなただけがそれを読み取ることができ、私がメッセージを送信したことを確認します。
または
詳細な説明については、このリンクにアクセスしてください。
2つの別々のキーが必要です。1つはあなたが誰であるかを示すもので、もう1つはあなたがあなたが誰であるかを証明するものです。
「キー」はユーザーID、「シークレット」はパスワードです。彼らは「キー」と「シークレット」という用語を使用しているだけです。それが彼らがそれを実装した方法だからです。
Bearer:はそのために認証を使用しないのですか？そこにIDとpwdがあります。
簡単な答え、私がそれを正しく理解していれば...
暗号化にAPIキーを使用する場合、サービスは誰がそれらに連絡しているかをどのように知るのでしょうか？彼らはそのメッセージをどのように解読しますか？
APIキーを使用して、自分が誰であるかを示します。これは、プレーンテキストで送信するものです。誰にも送信しない秘密鍵。暗号化に使用するだけです。次に、暗号化されたメッセージを送信します。暗号化に使用されたキーを送信しないと、目的が損なわれます。
secretプレーンテキストで送信するのを見たことがありません。リンクを教えていただけますか？私が見たのは、secretいくつかのデータを暗号化するために使用しています。そして、暗号化されたデータとともにapiKey、サーバーがデータを復号化する方法を知っているように送信します。
secretを呼び出しているようでありapiKey、実際に行っていることはusernameとpasswordです。これは完全に異なるものがある...
秘密鍵と（公開）鍵が何であるかを説明する答えがあります。これは、彼らが紛らわしい名前を付ける公開鍵と秘密鍵のペアです。しかし、APIが両方を必要とする理由は誰も言いません。多くのAPIは、1つの秘密しか提供しません。また、APIのドキュメントで2つのキーがある理由を説明しているのを見たことがないので、私ができる最善のことは推測することです...
リクエストには公開鍵のみを入れ、秘密鍵を使用してローカルでリクエストに署名することをお勧めします。これ以上送信する必要はありません。しかし、一部の人は、リクエストに秘密を持っているだけで逃げます。わかりました。優れたAPIは、TLS（通常はHTTPS経由）などのトランスポートセキュリティを使用します。ただし、その方法で秘密鍵をサーバーに公開しているため、秘密鍵が何らかの形で誤って処理されるリスクが高まります（最近発見されたGitHubとTwitterのパスワードロギングのバグを参照）。また、HTTPSは理論的には同じくらい安全ですが、実装上の欠陥は常に存在します。
しかし、多くの（実際にはほとんどのように思われる）APIでは、ユーザーに独自の署名を行わせるよりも簡単なので、リクエストで両方のキーを送信する必要があります。そうでなければ、純粋なcURLの例を持つことはできません！その場合、それらを分離することは無意味です。個別のキーは、後でそれらを利用するためにAPIを変更する場合に備えていると思います。または、より安全な方法で実行できるクライアントライブラリを持っている人もいます。
それは、マーカス・アダムスの答えを拡張したものですが、私は、ここで言及見なかったことの一つは、あなたが可能性があるかどうかを確認し、ユーザを認証の両方に単一の情報を使用してはならないことであるタイミング攻撃は、そのことができます応答時間の違いを使用して、文字列の比較がどこまで進んだかを推測します。
「キー」を使用してユーザーまたは資格情報を検索するシステムを使用している場合、その情報は、何千ものリクエストを送信し、データベースが検出するのにかかる時間を調べることで、時間の経過とともに段階的に推測される可能性があります。検索）レコード。これは、「キー」がキーの一方向ハッシュではなくプレーンテキストで格納されている場合に特に当てはまります。ユーザーにキーを再度表示できるようにする必要がある場合は、ユーザーのキーをプレーンテキストまたは対称的に暗号化して保存することをお勧めします。
2番目の情報、つまり「シークレット」を用意することで、タイミング攻撃に対して脆弱である可能性のある「キー」を使用してユーザーまたは資格情報を最初に検索し、次にタイミングセーフ比較機能を使用しての値を確認できます。秘密"。
その関数のPythonの実装は次のとおりです。
そしてそれはhmaclib（そしておそらく他のもの）で公開されています：
https://docs.python.org/3/library/hmac.html#hmac.compare_digest
ここで注意すべきことの1つは、入力文字列の文字が変更されるたびに比較される値がランダムに変更されるため、ルックアップの前にハッシュまたは暗号化された値に対してこの種の攻撃が機能するとは思わないことです。私はここでこれの良い説明を見つけました。
APIキーを保存するためのソリューションは次のようになります。
なかでも、セキュリティと利便性のバランスは3がベストだと思います。キーを発行するときに、これが多くのWebサイトに実装されているのを見てきました。
また、実際のセキュリティ専門家にこの回答を批評してもらいます。別の議論のポイントとして、これを公開したかっただけです。