クライアント側のブラウザでの暗号化と復号化–安全ですか？
専用Webサーバーから自分のPIIを含むファイルをダウンロードする可能性があります。このファイルは、2つの要素を埋めることによって復号化される可能性があります。これら2つの要素は、電子メールとSMSで配信されます。これらの要素の合計は、たとえばbcryptによってハッシュが生成される鍵です。このハッシュは、このファイルからPIIを復号化するためのメインパスワードです。ユーザーには見えません。ユーザーは、これら2つの要素を提供するだけで済みます。すべてのプロセス：2つの要素のスケーリング、ハッシュの作成、復号化。クライアント側のクライアントコンピュータのブラウザ（Java）で実行されます。
私の意見では、それは良い習慣ではなく、安全でもありません。復号化のプロセスはクライアントのコンピューター上で行われます。また、アルゴリズムはクライアントコンピューターに配信されます。これは、Java=で記述されているため、ファイルの復号化に使用される関数について知ることができます。攻撃者はファイルと知識を盗み、ファイルへのアクセスを試みることができます。機密性の主なセキュリティは、bcryptのような強力なアルゴリズムに基づいています。
この事件についてどう思いますか？または多分私はそれについて狂っていて間違っています、そしてこれは良い安全な習慣です。
特定の技術的な実装の詳細のいくつかを脇に置き、あなたが質問または想定したことに焦点を当てましょう：
- クライアント側の復号化は安全ですか？
- 使用されている暗号化を見つけるのは問題ですか？
- 強力なハッシュは強力なセキュリティの鍵ですか？
クライアント側の復号化
すべての復号化をクライアント側に持つことには何の問題もありません。非常に安全な実装の場合、それが実際に望ましい方法です。すべてクライアント側である場合、送信とストレージはすべて本質的に暗号化されます。 「しかし、攻撃者はクライアントからそれを盗むことができます！」はい、しかし彼らはとにかくそうすることができました。 PIIはクライアントマシン全体に存在します。攻撃者がクライアントデバイスにアクセスできる場合は、とにかくすべてのものを手に入れます。
暗号化アルゴリズムを知る
暗号化には「ケルホフの原理」と呼ばれる概念があり、攻撃者がどの暗号化方式が使用されたかを正確に知っていても、すべての暗号化は安全を目指すべきであると提案しています。唯一の秘密は鍵であるべきです。承認されたすべての暗号化アルゴリズムはケルクホフスの条件を満たすため、攻撃者がファイルの暗号化方法を知っていても問題ありません。
キーとしてのハッシュ
キー生成のアイデアの問題は、さまざまな要因と、それらを使用してキーになるハッシュを作成する方法は重要ではないということです。最後の文字列は、ファイルのパスワードです。ファイルを再度開く必要がある場合は、文字列を保存、保存、再利用できます。したがって、キーを「保護」するためのすべての作業が無効になります。あなたはひどく不便なランダム文字列ジェネレータを作成しました。
また、ユーザーが意図的にこれを行うのを防ぐ場合、攻撃者がJavaアプリの独自のバージョンを作成し、すべてのコントロールを単純に削除することを防ぐことはできません。ユーザーにとって非常に困難です。
何をすべきか
標準のJava暗号化ライブラリを使用して暗号化キーをユーザーパスワードで保護するだけで、プロセス全体を簡略化できます。これはオンラインパスワードマネージャーが行うことであり、PIIよりはるかに機密性の高いデータを保護します。