OpenIDログインとOAuthトークンをYouTubeで使用するWebアプリを作成しています。現在OpenID IDとOAuthトークン/トークンシークレットをプレーンテキストで保存していますデータベース内のテキスト。
これらの値をプレーンテキストとして保存することは不適切ですか? OpenID識別子に一方向の暗号化を使用することもできますが、それが必要かどうかはわかりません。 OAuthトークンの場合、アプリは一部の用途でセッショントークンの取得に依存しているため、双方向暗号化を使用する必要があります。
OpenID IDを暗号化する必要はありますか?誰かがそれを使用してユーザーのアカウントにアクセスすることはできますか?
まず、consumer_key
とconsumer_secret
を持つ登録済みアプリケーションがあります。
ユーザーが登録済みアプリケーションを認証して「許可」すると、次が返されます。ユーザーの「パスワード」と見なされ、アプリケーションがユーザーに代わって動作することを許可するaccess_token
。
したがって、データベースからユーザーのaccess_token
だけを取得しても、完全なアクセスのためのconsumer_key
とconsumer_secret
がない場合はあまり役に立ちません。
サービスプロバイダーは、要求に応じて4つのパラメーターすべてを比較します。保存する前にこれらの4つのパラメータを暗号化し、応答する前に復号化するのが賢明です。
これは、ユーザーに代わってユーザーのリソース所有者を更新または変更する必要があるときです。ユーザーがサイトにログインしたままにするには、セッションを使用します。
OAuthトークンとシークレットはどちらもデータベースに安全に保管する必要がありますが、パスワードの場合と同じように一方向暗号化を使用してそれらを保存することはできません。その理由は、リクエストに署名するには、トークンとシークレットが必要です。
OAuthサーバーを実行している場合も同様です。要求を確認するには、元のトークン/シークレットが必要です。
必要な場合は、AESなどの双方向暗号化アルゴリズムを使用して暗号化し、データベースまたはデータベースのバックアップが侵害された場合のセキュリティを提供することができます。
ここには2つの考え方があります。
最初の引数は、OAuthトークンをパスワードのように扱う必要があります。データベースにアクセスする人がいたら、すべてのOpenID/OAuthペアを取得して、中間者攻撃を実行します。彼らはあなたのサイトのすべてのユーザーになりすますことができます。
2番目の引数はこれです。誰かがデータベースにアクセスし、中間者攻撃を実行するためにネットワークに十分にアクセスできるようになるまでに、とにかくあなたはうんざりしています。
私は個人的に注意を怠って、暗号化するだけです。これはパスワードの標準的な慣行であるため、少しだけ安心することもできます。
一方、Googleは次のようなアドバイスをしています。
「トークンは、サーバーに保存されている他の機密情報と同じように安全に扱う必要があります。」
ソース: http://code.google.com/apis/accounts/docs/OAuth.html
そして、ウェブ上のランダムな人が特定の実装アドバイスを持っています:
http://brail.org/wordpress/2009/05/01/implementing-oauth-take-care-with-those-keys/
これは文字通り「オープンID」なので、OpenID URLは暗号化しないでください。誰もがその値を知っている必要があります。さらに、URLはデータベースのインデックスである必要があり、データベースのインデックスを暗号化することは常に問題があります。
OAuthトークン/シークレットはシークレットである必要があり、トークンを長期間保存する必要がある場合は、暗号化によってセキュリティが向上する場合があります。私たちのOAuthコンシューマアプリケーションでは、トークン/シークレットはしばらくの間セッションに保存されるだけであり、暗号化しないことを選択します。それは十分に安全だと思います。誰かがセッションストレージを覗くことができれば、彼らはおそらく私たちの暗号化キーも持っています。
はい、これらはデータベースに保存するときに対称的に暗号化する必要があります(たとえば、CBCモードのAES-256)。これらのトークンを暗号化する簡単な方法は、サービスとしてRESTful APIとして SecureDB の暗号化を使用することです。
開示:私はSecureDBで働いています。