web-dev-qa-db-ja.com

OpenID識別子とOAuthトークンを安全に保存する

OpenIDログインとOAuthトークンをYouTubeで使用するWebアプリを作成しています。現在OpenID IDとOAuthトークン/トークンシークレットをプレーンテキストで保存していますデータベース内のテキスト。

これらの値をプレーンテキストとして保存することは不適切ですか? OpenID識別子に一方向の暗号化を使用することもできますが、それが必要かどうかはわかりません。 OAuthトークンの場合、アプリは一部の用途でセッショントークンの取得に依存しているため、双方向暗号化を使用する必要があります。

OpenID IDを暗号化する必要はありますか?誰かがそれを使用してユーザーのアカウントにアクセスすることはできますか?

57
Matt McCormick

まず、consumer_keyconsumer_secretを持つ登録済みアプリケーションがあります。

ユーザーが登録済みアプリケーションを認証して「許可」すると、次が返されます。ユーザーの「パスワード」と見なされ、アプリケーションがユーザーに代わって動作することを許可するaccess_token

したがって、データベースからユーザーのaccess_tokenだけを取得しても、完全なアクセスのためのconsumer_keyconsumer_secretがない場合はあまり役に立ちません。

サービスプロバイダーは、要求に応じて4つのパラメーターすべてを比較します。保存する前にこれらの4つのパラメータを暗号化し、応答する前に復号化するのが賢明です。

これは、ユーザーに代わってユーザーのリソース所有者を更新または変更する必要があるときです。ユーザーがサイトにログインしたままにするには、セッションを使用します。

28
Feha

OAuthトークンとシークレットはどちらもデータベースに安全に保管する必要がありますが、パスワードの場合と同じように一方向暗号化を使用してそれらを保存することはできません。その理由は、リクエストに署名するには、トークンとシークレットが必要です。

OAuthサーバーを実行している場合も同様です。要求を確認するには、元のトークン/シークレットが必要です。

必要な場合は、AESなどの双方向暗号化アルゴリズムを使用して暗号化し、データベースまたはデータベースのバックアップが侵害された場合のセキュリティを提供することができます。

19
Pelle

ここには2つの考え方があります。

最初の引数は、OAuthトークンをパスワードのように扱う必要があります。データベースにアクセスする人がいたら、すべてのOpenID/OAuthペアを取得して、中間者攻撃を実行します。彼らはあなたのサイトのすべてのユーザーになりすますことができます。

2番目の引数はこれです。誰かがデータベースにアクセスし、中間者攻撃を実行するためにネットワークに十分にアクセスできるようになるまでに、とにかくあなたはうんざりしています。

私は個人的に注意を怠って、暗号化するだけです。これはパスワードの標準的な慣行であるため、少しだけ安心することもできます。

一方、Googleは次のようなアドバイスをしています。

「トークンは、サーバーに保存されている他の機密情報と同じように安全に扱う必要があります。」

ソース: http://code.google.com/apis/accounts/docs/OAuth.html

そして、ウェブ上のランダムな人が特定の実装アドバイスを持っています:

  • 通常のディスクファイル上にある場合は、ファイルシステムの権限を使用して保護し、暗号化されていることを確認して、パスワードを適切に非表示にします
  • データベース内にある場合は、フィールドを暗号化し、キーを適切に保存し、データベース自体へのアクセスを慎重に保護します。 *
  • LDAPにある場合は、同じようにします。

http://brail.org/wordpress/2009/05/01/implementing-oauth-take-care-with-those-keys/

11
Ben Walther

これは文字通り「オープンID」なので、OpenID URLは暗号化しないでください。誰もがその値を知っている必要があります。さらに、URLはデータベースのインデックスである必要があり、データベースのインデックスを暗号化することは常に問題があります。

OAuthトークン/シークレットはシークレットである必要があり、トークンを長期間保存する必要がある場合は、暗号化によってセキュリティが向上する場合があります。私たちのOAuthコンシューマアプリケーションでは、トークン/シークレットはしばらくの間セッションに保存されるだけであり、暗号化しないことを選択します。それは十分に安全だと思います。誰かがセッションストレージを覗くことができれば、彼らはおそらく私たちの暗号化キーも持っています。

0
ZZ Coder

はい、これらはデータベースに保存するときに対称的に暗号化する必要があります(たとえば、CBCモードのAES-256)。これらのトークンを暗号化する簡単な方法は、サービスとしてRESTful APIとして SecureDB の暗号化を使用することです。

開示:私はSecureDBで働いています。

0
Rettel