平文のパスワードを保持する String 変数があるとします。
メモリ ダンプを使用してこのパスワードを読み取る可能性はありますか。(チート エンジンを使用するとします。) 私はこの JVM のことで困惑しています。JVMはこれに対して何らかの保護を提供しますか? そうでない場合、そのような「盗み」を避けるために私が使用する必要がある慣行は何ですか。
実際の脅威はトロイの木馬です。外部パーティにメモリ ダンプのセグメントを送信します。
平文のパスワードを保持する String 変数があるとします。
メモリ ダンプを使用してこのパスワードを読み取る可能性はありますか。(チート エンジンを使用するとします。) 私はこの JVM のことで困惑しています。JVMはこれに対して何らかの保護を提供しますか? そうでない場合、そのような「盗み」を避けるために私が使用する必要がある慣行は何ですか。
実際の脅威はトロイの木馬です。外部パーティにメモリ ダンプのセグメントを送信します。
すでに述べたように、はい、さまざまな方法で誰でもパスワードを抽出できます。パスワードを暗号化してもあまり役に立ちません。アプリケーションによってパスワードが復号化された場合、復号化された形式もある時点で存在し、さらに復号化キー (またはコード) 自体が脆弱になります。暗号化された形式で別の場所に送信された場合、暗号化された形式を知っているだけでトランザクションを偽装するのに十分であるため、それもあまり役に立ちません。
基本的に、「攻撃者」が「送信者」でもある限り、最終的にクラックされることになります。これが、音楽およびビデオ業界が DRM を機能させられない理由です。
Applied Cryptographyのコピーを手に取り、最初のセクション「Cryptographic Protocols」を読むことをお勧めします。実際の仮想通貨の数学に触れなくても、この分野のあらゆる種類の設計パターンを概観できます。
アプリケーションでパスワードを平文のままにしておくと、使用する言語やランタイムに関係なく、誰かがメモリ ダンプをいじってパスワードを読み取ることができます。
このような事態が発生する可能性を減らすには、本当に必要な場合にのみパスワードをプレーン テキストで保持し、それをダンプまたは暗号化します。ここで注意すべきことの 1 つは、JPasswordField が文字列ではなく char[] を返すことです。これは、文字列がいつ消えるかを制御できないためです。また、char[] がいつ消えるかを制御することはできませんが、パスワードを使い終わったら、がらくたで埋めることができます。
これは誰かを止めることはないので、減らすと言います。パスワードがメモリ内にある限り復元できます。また、復号化も成果物の一部である必要があるため、パスワードが公開されたまま解読される可能性があります。
これは Java とは何の関係もありません。まったく同じ問題 (実際に問題がある場合) は、どの言語で記述されたアプリケーションにも存在します。
最近の OS では任意のアプリケーションが互いのメモリを監視することは許可されておらず、権限昇格攻撃は通常、さまざまな攻撃ベクトルに依存しているため、後者は通常問題とは見なされません。
プログラムがパスワードを知っている場合、プログラムを使用する誰もがパスワードを抽出できます。
理論的には、デバッガーに接続するだけで...ブレークポイントを設定して...文字列の内容を読み取ることができます