1

PHP アプリケーションがあり、ユーザーのデータがサーバーに到達する前に暗号化する必要があるとします (ユーザーのデータがデータ マイニングされたり、広告のために転売されたりしないことをユーザーに証明するため)。

同様の質問がここで尋ねられました (セキュア Javascript 暗号化ライブラリ? ) は、これがうまくいかないことを暗示していますが、ユーザーの間でプライバシーへの関心が高まっているため、この要件は時間の経過とともに大きくなるだけです.

たとえば、スタンフォード ライブラリ ( http://crypto.stanford.edu/sjcl/ ) を使用する Web フォームには、ユーザーが貼り付ける追加の「長い」パスワード フィールドがあります (おそらく電子メールなどから)。

  sjcl.encrypt(txtPassword, txtFormFieldToBeEncrypted)

暗号化されたデータは PHP ページに送信され、ページが読み込まれるとプロセスが逆になります。

ユーザーが Chrome やフォーム値を記憶する別のブラウザーを使用している場合、これは機能しますか? これは明らかに安全な結果ではありませんが、ホスト サーバーからユーザー情報を非公開に保つのに十分効果的でしょうか?

編集：明確にするために、私は情報をホストサーバーから見えないようにすることにのみ関心があり、このソリューションはサードパーティの攻撃から保護されないことを理解しています

4

4 に答える 4

1

これを行うことは完全に可能です。たとえば、Lastpassはそれに基づいてビジネス モデルを構築しました。サーバーが行うことは、何もできない暗号化されたブロブを保存することだけであり、すべての暗号化と復号化はクライアントで行われます。ブラウザに Javascript の実装を含めます。暗号化されたデータのブロブ全体がクライアントにダウンロードされ、そこでユーザーのパスワードによって復号化されます。サーバーに戻る途中で逆になります。

したがって、あなたの質問がそれが可能かどうかである場合: 絶対に. また、サポートしたいプラットフォームの数だけ同じ暗号化/復号化コードを提供する必要があるため、多くの作業が必要です。また、そのコードが実行されるすべてのコンテキストを保護して、第三者がクライアント側の復号化されたデータにアクセスできるようにするコードを挿入するのを防ぐ必要があります。そのため、サードパーティのコンテンツの挿入を許可せずに、すべてを SSL で処理する必要があります。

于 2013-06-25T13:24:47.187 に答える
1

ブラウザでの JavaScript 暗号化がほとんど常に悪い考えである理由はいくつかあります。

信頼モデルについて深く考える必要があります。ユーザーはサーバーを信頼していますか? そうでない場合、暗号化ソフトウェア自体はサーバーから取得されるため、信頼できる JavaScript 暗号化の希望はありません。ユーザーがサーバーを信頼している場合、データをクライアント側で暗号化する必要があるのはなぜですか? SSL を使用して接続を保護し、サーバーにデータを暗号化してから保存させます。

于 2013-06-25T12:55:57.590 に答える