web-dev-qa-db-ja.com

APIの保護：SSLおよびHTTP基本認証と署名

Webアプリ用のAPIを設計するとき、サブドメインを「ユーザー名」として使用し、APIキー/共有シークレットを生成します。まず、サブドメインをユーザー名として使用しても大丈夫ですか？別のキーを生成することの利点がわかりません。

異なるAPIは、次の2つのいずれかを実行するようです。

  1. SSLでHTTP基本認証を使用する

すべてのリクエストで、ユーザー名はサブドメインに設定され、パスワードはAPIキーに設定されます。 SSLを使用しているため、これはなりすましから安全です。

注目すべきAPI：Google Checkout 、 Freshbooks 、 GitHub 、 Zendesk

  1. 共有シークレットを使用してリクエストの署名を作成します

通常、キー/値ペアを注文し、共有シークレットでHMAC-SHA1を使用して署名を生成することで実現します。次に、署名がリクエストとともに送信され、もう一方の端で検証されます。

注目すべきAPI：Google Checkout 、 Amazon AWS

PS：間違いなく、Google Checkoutは両方をサポートしています

編集：OAuth 2は、SSL経由でユーザー名/パスワードを送信するために署名を削除しています。

何を選ぶべきかについての誰かからの意見：SSL vs Signature？

securityapiauthenticationrestdigital-signature
64
Marcus

私の研究では、SSLを介したHTTP基本認証は完全に安全です。

結局、SSL（現在は厳密にTLS）を使用することは、トランスポート層が暗号化されていることを意味します。

したがって、署名を生成せずにユーザー名とパスワードを渡すだけで十分です。

38
Marcus

イゴールの答えは完全に真実ではありません。 TLSはトランスポート層が暗号化されて安全であることを保証しますが、たとえば、クライアントがデジタル署名の形式で「強力な暗号化」を使用して認証する相互認証でTLSを使用するほど安全ではありません。これがTLS経由の基本認証よりも優れている主な理由は2つあります。

  • パスワードはパスワードであり、地球上の現在の70億人のうち3人は、完全にランダムな30文字のパスワードを使用していると思います。私たちの残りは、エントロピーがはるかに少ないものを選択しました。したがって、攻撃者がデジタル署名の代わりにパスワードを使用するサービスをブルートフォースするのは、はるかに簡単です。

  • クライアント側のデジタル署名には、通常は秘密鍵にアクセスするためのパスワードも含まれていると主張できます。ただし、これは基本認証とはまったく異なる状況です：最初に秘密鍵はクライアントのマシン上のリソースとして存在するため、たとえ回復されたとしても、通常の鍵の場合は全員ではなく1人だけに影響しますPKCS＃12などのコンテナ形式には、キーへのアクセスに使用されるパスワードベースの暗号化もあります。これらのアルゴリズムは、攻撃者の速度を低下させて単位時間あたりの総当たり攻撃の割合を減らすように特別に設計されており、これもデジタル署名の利点です。

TLS Basic Authの設定と使用がはるかに便利であることは間違いありませんが、セキュリティの高い環境では、ユーザー/パスワードソリューションよりも常に「強力な暗号化」を好むでしょう。

36
emboss

OpenSSLのHeartbleedの問題は、APIを保護するためにSSLのみに依存する潜在的な落とし穴を示しています。 SSLトランスポートが危険にさらされた場合のAPIの使用と影響に応じて、Embossの回答に記載されているように、追加のセキュリティ対策を講じる必要があります。

4
Matt H

何らかの形式の秘密がある限り、サブドメインをユーザー名として使用しても構いません。

共有シークレットを使用する利点は、リクエストを実行する「パーティ」がシークレットを知る必要がなく、リクエストを実行するために署名を知るだけでよいことです。これは、たとえばユーザーがブラウザーを介してリクエストを許可できるようにする場合に役立ちます。

S3を使用すると、署名を作成し、ブラウザーに送信して、ブラウザーからS3に直接アップロードできます。

HTTPダイジェストを使用することもできますが、これには両方の利点があります。ブラウザはダイジェストとベーシックをサポートしており、プレーンテキストのパスワードがネットワーク経由で送信されることはないため、ブラウザでAPIを簡単にテストできます。

3
Evert

Security.stackexchange.comで言及されているいくつかのことを指摘したいと思います。「SSLを介したHTTP基本認証は、私の研究から完全に安全だ」と言っているからです。以下のポイント3と4は、REST APIに対してはほとんど有効ではありませんが、実装方法によって異なります。

「HTTP基本認証にはいくつかの問題があります。

  • パスワードは、base64エンコード（簡単にプレーンテキストに変換可能）でネットワーク経由で送信されます。
  • パスワードは、リクエストごとに繰り返し送信されます。 （より大きな攻撃ウィンドウ）
  • パスワードは、少なくともウィンドウ/プロセスの長さの間、webbrowserによってキャッシュされます。 （サーバーへのその他の要求、たとえばCSRFによって静かに再利用できます）。
  • パスワードがブラウザに永続的に保存される場合があります（ユーザーが
    リクエスト。 （前のポイントと同じですが、さらに盗まれることもあります
    共有マシン上の別のユーザー）。

そのうち、SSLを使用しても最初の問題が解決するだけです。また、それでも、SSLはWebサーバー（内部ルーティング、サーバーロギングなど）がプレーンテキストパスワードを参照するまでしか保護しません。

そのため、全体像を見ることが重要です。 HTTPSは転送中のパスワードを保護しますか？ - はい。

それで十分ですか？通常、いいえ。 （私は常に言いたいのですが、それは本当にあなたのサイトが何であるか、そしてそれがどれだけ安全である必要があるかに依存します。）

3
Ogglas

誰も要点に触れていないので、古いスレッドで答える

SSL/TLSには根本的な欠陥すべてのPKIと同様に、 MiM攻撃の影響を受けやすくなることが証明されている信頼チェーンに依存しているため、 ：

  • 証明機関はハッキングされています。多くの例の1つとして、 DigiNotar の場合があります。この場合、すべての証明書が取り消されたことを違反が認識される前にCAが数か月間侵害されました。その間、イラン政府はgoogle.com、facebook.com、Twitter.comなどの完全に有効なSSL証明書を偽造しました

  • 不特定の「セキュリティ目的」のためにすべてのトラフィックをオンザフライで解読および再暗号化するZscalerなどの企業プロキシフィルタリングツール。 SOの this question/answer を参照してください

  • 最も一般的なSSL実装（openSSL）のバグは常に発見されています（しかし、時間の経過とともに状況は改善されるでしょうか？）

したがって、大企業はSSLのみに依存することを好みません。

そのような場合、HMACトークンは機密性を提供しませんですが、あなたをスパイしている人は誰も許可しません要求を偽造するそれ以外の場合は、基本認証を介してそれらを渡しただけなら簡単です。

PKIモデルに代わるものは Web of trust です。これは、証明書の信頼性を検証するために単一の機関に依存せず、多くの-既知の信頼できるピアによって提供される意見に依存しますOR-既知であるが必ずしも信頼できるピアではない

ただし、Bitcoin Blockchainのように悪名高い 51％攻撃 の影響を受けるため、このモデルはまだ完全ではありません（分散信頼モデルの例です）

2
Stefano Fratini