サードパーティの認証情報を安全に保存する
ユーザーのメールボックスへのアクセスを必要とするマルチユーザーWebアプリケーションがあるとします（Gmailなどのサードパーティサービス上）。このアクセスは永続的である必要があります。つまり、ユーザーのパスワードを保存する必要があります。これは脆弱点を作成します-誰かがそのようなシステムにアクセスした場合、彼は大量のユーザーのメールボックスを盗む可能性があります。そのようなセットアップでリスクを減らす方法はありますか？例えば。一部のウェブサイトではOAuthトークンはコンシューマキーを必要とするためリスクを軽減でき、制限され、問題が発生した場合は簡単に大量に期限切れになる可能性があります。ただし、これはすべてメールサーバーでは利用できません。したがって、そのような情報をより安全な方法で保存するための良い方法（ある場合）についての提案はありますか？
経験上、このようなサイトが公共のインターネット上にあり、十分に人気がある場合、それは大きなターゲットになり、壊滅的な妥協の可能性が高くなります。この大規模なディスカッションの応答に注意してください（多少異なる目標について）。
先に進むことを選択した場合は、非常に実際のリスクについてユーザーに警告してください。多層防御は必須です-実際のパスワードストレージマシンをWebから切り離し、ファイアウォールを介してアクセスできる非常にシンプルなインターフェースで、見つけられる最も安全なプラットフォーム上に構築し、多くの強化と監視、優れたIDSなどを備えています。等.
あなたが言うように、これは潜在的な弱点です。しかし、それをどのように修正するかは、アプリケーションの実装方法に大きく関係しています。例えばJavaコンテナ内のアプリケーションとして実行される場合、アプリケーションの起動後にトークンをアプリケーションのヒープに書き込むことができます。そこから、メモリスペースに入らずに読み取ることは非常に困難です。 Javaの場合、たとえば、PHPタイプのプラットフォームの場合、これは実現可能なアプローチではありません。おそらく最良の解決策は、Webサーバーの起動時に設定された環境変数を使用することです。これはもっと複雑です。単一のデータベースパスワードを言うのではなく、何千もの潜在的なユーザーのPOPパスワードを維持するための命題-しかし、原則は同じです。共有プラットフォームの場合と同様に、実際にはファイルシステムにアクセスする必要があります（suphpとopen_basedir for php）。
ただし、ユーザーにパスワードの入力を要求すると、この複雑さのほとんどは解消されます。スヌーピングからセッションデータを保護することは、システム全体の設定よりも簡単です。ただし、まだ潜在的な問題が残っています。サードパーティの機能とは無関係にユーザーを認証する必要がある場合、または複数のサードパーティに接続する場合は、ユーザートークンの保存されたデータベースへの暗号化キーの一部としてユーザーのパスワードを使用できます。
しかし、そのようなプラットフォームを保護する方法について尋ねるのではなく、リスクを軽減する方法について尋ねています。ただし、サードパーティの認証メカニズムを制御しない場合は、ユーザー名/パスワード以外のものを使用することはできません。
したがって、フロントエンドでの神のセキュリティの確保からの別の選択肢は、ハニーポットでデータをスパイクすることだけです。ハニーポットへのアクセスが見られる場合は、おそらく妥協。