web-dev-qa-db-ja.com

Facebook、Gmailなどでログインするときにユーザーデータを暗号化する

ログインシステム を作りました。ユーザーは次の方法でログインできます。

  • 通常の電子メール/パスワード(bcrypted)を使用します。
  • facebook、gmailなどのserviceを使用する.

ここまでは順調ですね。次に、機密情報(ftp資格情報)をデータベースに安全な方法で保存したいと思います。これは、最初のユーザーにとって非常に簡単です。ユーザーがメール/パスワードでログインすると、パスワードは1つの(デフォルト)ソルトでハッシュされて認証を確認し、別のソルトでハッシュされて強力なハッシュXを取得します。

次に、このハッシュXをパスワードとして使用して、ユーザーが保存したい機密データを暗号化します。このように、コードとデータベースへのフルアクセスはユーザーのデータを危険にさらしません。 *

本来はパスワードがないserviceでログインするユーザーに対して同様のセキュリティレベルを達成する方法はありますか? サーバー側の面倒で、ユーザーに複雑さを追加しないことを強くお勧めします。これらは私が彼らの問題で見ることができるすべてのオプションです:

  1. すべてのユーザー(Facebook/Gmailなど)でも、パスワードを書いて覚えておく必要があります。これもまた、そもそもこれらのサービスを統合させた原則です。

  2. サーバー側のサイト全体で一意の暗号化パスワードを使用します。コードとデータベースへの完全なアクセスから保護したいので、誰も(開発者/管理者などを含む)がこのプライベートデータにアクセスできません。

  3. ユーザー固有のデータを使用します。たとえば、これはユーザーのFacebookのIDになります。これは、fbで電子メールを検索するだけで取得できるため、安全ではありません。

5

あなたは単一の非秘密情報源から秘密情報を生成することを求めています。これらの正確な条件下では実行できません。 「秘密の源」が必要です。おそらく別のキーで暗号化されている設定ファイルでキーをリスにして試すか、ハードウェアセキュリティモジュール(HSM)を使用して暗号化とキーをホストするなど、一部の側面を別の安全なマシンに移動することができます。ただし、有限のデータセットから再作成可能なシークレットを作成することはできず、攻撃者があなたの特技を複製できないことを期待できます。

2
John Deters

あなたの質問は、「ユーザーパスワードを安全に保存したいが、元に戻せるようにしたい」のようです。これは基本的に、DRMを(サーバーに)実装することを意味します。これは、特に一般的なライブラリのシナリオでは基本的に不可能です。

ユーザーの資格情報を保存するには、個別の切断されたサーバー/サービスが必要です。そのサーバーは、次のようなリクエストを処理するAPIを介してonlyにアクセスできます。

  • 「$ user_idの$ ftp_user_and_passwordを保存」
  • 「$ these_filesを$ user_idのFTPにアップロードします」

それ以外の場合は、サーバーをアプリから完全に切断する必要があります(他の受信リクエストにはアクセスできません)。これは、たとえば、クレジットカードの取り扱いと似ています。


さらに、あなたはあなたの本当の必要性がユーザー提供のFTPクレデンシャルを保護することであると述べました。

他の保護手段に加えて、サーバーで生成した資格情報を使用して、ユーザーにサービスの新しいFTPユーザーを作成するように強制する方がはるかに安全です(「username = my_service、password =で新しいFTPユーザーアカウントを作成してくださいlong_random_string」)。

これは、ユーザーが「一般的な」FTPパスワード(他のアカウントでも使用する可能性が高い)を単に提供するのではなく、悪意のあるサードパーティがデータにアクセスした場合に多くの問題が発生する可能性があることを意味します。すべてのユーザーにサービス固有のFTPユーザーアカウントアクセスの取り消しを依頼します。 (「共通」パスワードを紛失した場合、多くの(確かにゼロを超える)ユーザーは、あまりにも不便であるため、共通(FTP)パスワードを変更しない可能性があります。)

サービス固有のパスワードの保護について考える必要がありますが、最悪のシナリオの方がはるかに管理しやすくなります。

0
Joel L