0

したがって、この質問はセキュリティと暗号化を掘り下げており、多くの人が問題に遭遇していない可能性があります. 答えは理論的なものかもしれません。シナリオの概要を説明しましょう...

  1. Web サイトのフロントエンドは、バックエンド API を介して駆動されます。バックエンドには、 と を使用して一般的な登録フォームを処理するエンドポイントがありusernameますpassword。SSLを使用しています。
  2. バックエンド API は、非同期ジョブ キューを介して登録を処理します。キューはAPI サーバーに応答を返しません。登録をキューに入れるのは、設定して忘れる操作です。
  3. キューに入れられたジョブはワーカーによって取得されます。ワーカーがユーザー アカウントの作成を担当します。これらのワーカーは、パスワードを使用してサードパーティの API 登録呼び出しをトリガーできるように、平文のユーザー パスワードにアクセスする必要があります。

したがって、問題の真の核心は、第三者の目にパスワードを公開せずに、パスワードをサードパーティの API に同期させることです。キューは、グローバル POST データからプレーンテキストのパスワードに直接アクセスできないという問題を引き起こします。つまり、何らかの方法でキューに格納する必要があります。

キューは、ハッシュ化されたパスワードを簡単に保存し、ユーザー テーブルに直接コピーできます。ただし、このソリューションでは、パスワードが既に暗号化されているため、サード パーティの API とパスワードを同期することはできません。私は双方向の暗号化をいじりましたが、パスワードが攻撃者によって解読されやすいままになることを心から懸念しています。

パスワード同期のこのシナリオを処理する安全な方法を考えられる人はいますか?

キューは必須であり、サーバーにアクセスできるすべてのユーザーがこれを読み取ることができると想定されています。パスワードは必ずしも同期する必要はありません。サードパーティ API のパスワードは、パスワードを入力せずにログイン ユーザーを介して安全に復号化する手段がある限り、元のパスワードから派生したものである可能性があります。これは基本的に、SSO をサポートしないサードパーティ API を使用してシングル サインオンをシミュレートするためのものです。

4

1 に答える 1

0

パスワードを同期するには、いくつかの方法があります。

  1. どちらの認証ストアも可逆暗号化を使用するため、各システムは実際の値を抽出して他のシステムに送信できます。
  2. どちらもまったく同じ暗号化を使用するため、暗号化されたテキストを送信すると、両方が理解できるようになります。
  3. 1 つのシステムは、ユーザーが常に認証を行う「マスター」システムであり、「スレーブ」システムは、ユーザーがログインしたという確認応答を受信するだけです。奴隷。
  4. 1 つのシステムは、他のすべてのシステムがアカウントの検証のために呼び出しを行う「マスター」です。LDAP や MyOpenID を使用する場合と同様です。

ユーザーがパスワードを変更したときに、パスワードの変更が適切にレプリケートされるようにするなど、マルチマスター パスワードの同期で遭遇する可能性のある問題は確かにあります。

あなたの場合、ユーザーがサードパーティ API と直接やり取りすることはないようです。それが正しい場合は、ユーザーにシステムに対して認証してもらいます。必要に応じてサードパーティの API パスワードを生成し、アカウントと共に保存し、必要に応じて他のシステムに自動ログインします。プライマリ パスワードは、元に戻せない暗号化で保存できます。ただし、サードパーティは可逆暗号化を使用する必要があります。Queue は初期パスワードを持つ必要はなく、代わりに単に新しいパスワードを生成してローカル アカウントに保存します。

于 2013-03-12T20:41:06.893 に答える