web-dev-qa-db-ja.com

安全なREST APIを送信または保存せずに明確な資格情報

現在、REST APIを設計しており、それを保護することを考えています。
多くのドキュメントを調べた結果、2つのオプションが利用可能であることが明らかになりました。

HMAC認証

HMAC-sha1で事前定義された一連の要素をsecret_keyでハッシュすることにより、リクエストに署名します。検証は、まったく同じプロセスのサーバー側を実行し、結果のハッシュを比較することによって行われます。

私たちの実装は次のようになります：

  • 現在のタイムスタンプを取得する
  • HMACの作成：hmac(full_url + request_body + timestamp + secret_key + token)
  • 署名をそのまま送信：clientId + hmac_signature + timestamp + token

これの主な利点は、secret_keyがリクエストで送信されないことです。これにより、リプレイ攻撃をほぼ防止できます。ただし、欠点として、クライアントの資格情報（secret_key）をそのままの形式でデータベースに保存する必要があります。データベースが危険にさらされた場合、現在のすべてのAPIクライアントの資格情報を取り消すこともできます。

HTTPS認証

APIでSSLを使用すると、個人情報を交換するための安全なチャネルを作成できます。
基本的に同じ情報をHMACでハッシュせずに送信します。

私たちの設計は、OAuth2仕様とまったく同じ（または非常によく似た）ものになります。

HMACと比較すると、ほとんどの仕事をSSLに委任しているため、これには多くの利点があります。また、クライアントはHMACのようにハッシュ用のライブラリを含める必要はありません。最後に、クライアントのsecret_keyが安全に保存されるため、データベースは安全です。

しかし、誰かが1つの要求を巧妙に嗅ぎ取った場合、彼はsecret_keyを盗み、独自の要求の作成を開始できます。

クリアな資格情報を送信せず、クリアな資格情報を保存する必要なくHTTPSの利点を使用する方法はありますか？

私たちの代替設計の1つは、クライアント側で生成された秘密鍵/公開鍵を使用し、それを使用して鍵を交換し、将来の要求のためにsecret_keyを暗号化しました。しかし、多くのブラウザがこの機能を備えていません（<keygen>）そして、それはモバイルアプリケーションにとってかなり煩わしいものです。

tlsauthenticationresthmacapi
3
Cyrbil

コメントで指摘されているように、ssl/tlsは転送中の資格情報を保護します。トラフィックの暗号化は、プロトコルの目的の一部です。プロトコルのもう1つの主な目的：通信相手と直接通信していることの確認。

OPは、sslプロキシが可能であり、モバイルアプリケーションでの動作を確認しています。
ssl man-in-the-middleプロキシが存在することは事実ですが、クライアントは、通信しているサーバーが有効な証明書を提示できなかったことを警告します（クライアントがブラウザーの場合は続行しないでください） ）。

Rest APIが不正なSSL証明書を無視するように構成されている場合（一部は-わかっていますが、作成したものです）、はい、ssl MITMプロキシは実際に資格情報を盗聴できます。これは故意にSSL/TLSプロトコルを覆しています（この場合、SSL/TLSを使用しているとは言えません）。
これが、「自己署名」証明書が開発とテストの目的にのみ使用される理由です。

3
mcgyver5