6

この質問の前に、クライアント アプリケーションでパスワードをハード コーディングすることは、多くの理由から悪い習慣であることを認識していると言わなければなりません。その問題を扱う他の質問があります。この質問の範囲はより狭く、制御できないいくつかの理由により、認証資格情報がクライアントアプリケーションのコードに存在する必要があると想定しています。

いくつかの方法が他の方法よりも優れている場合 (たとえば、JPasswordField は文字列ではなく文字配列にパスワードを格納する)、Java アプリケーションでパスワードをハードコーディングする必要がある場合、フェッチされにくくするためにどのような手段を講じることができますか?

アップデート：

アプリケーションの 1 つのインスタンスは、エンド ユーザーが管理者権限を持つリモート PC で実行されます。資格情報は同じネットワーク内のデータベースにアクセスするために使用されるため、実際のパスワードは事前に決定されており、実際のコードに手動で入力する必要があります。

4

6 に答える 6

6

.... Java アプリケーションでハードコーディングする必要がある場合、フェッチされにくくするためにどのような手段を講じることができますか?

手始めに、この悪い決定を下した管理責任者が、これが根本的かつ取り返しのつかないほど安全ではないことを十分に認識していることを確認します1。

次に、あいまいな方法でパスワードを組み立てるナフアルゴリズムを考え出すでしょう。たとえば、2 つのバイト配列を作成してそれらを XOR し、難読化されたバイトコードを配布します。あなたが期待できる最善の方法は、スキルが限られている人がコードからパスワードをリバース エンジニアリングするのを困難にすることです。

(強力なアルゴリズムでパスワードを暗号化しても、あまり役に立ちません。なぜなら、アルゴリズムの選択と復号化キーの両方をコードに埋め込む必要があるからです。パスワードが平文である必要があるポイントのブレークポイント。)

1 ...そして、ジョン・スキートでさえも安全にすることはできないだろう.

いくつかの方法が他の方法よりも優れている場合 (たとえば、JPasswordField はパスワードを String ではなく char 配列に格納します) ...

char 配列を使用してJPasswordFieldなどにパスワードを保持する通常の理由は、悪者がコア ダンプやスワップ ファイルからパスワードを読み取るのを防ぐためです。この場合、心配すべき悪者はシステム管理者アクセス権を持つシメオネであると想定しなければならないため、実際には役に立ちません。彼または彼女は、デバッガーを JVM にアタッチし、char 配列からバイトをキャプチャーするための十分な制御を行うことができます。

于 2012-12-11T13:29:49.957 に答える
1

一般的なガイドラインとして、パスワードは絶対に保存しないでください（もちろん）。

実行時にパスワードを使用できるようにする必要がある場合のベストプラクティス（たとえば、JezHumbleによる継続的デリバリーの本で提唱されている）は、展開/起動時にパスワードを提供することです。このように、パスワードはどこかの安全でないファイルではなく、人々の頭にのみ存在することができます。

あなたの場合、これが実行可能かどうかはわかりませんが、それを目指す必要があります。

于 2012-12-11T12:50:51.270 に答える
1

.class ファイルは簡単に逆コンパイルできるため、機密データ、特にパスワードをクライアント側に保存することは非常に安全ではありません。非対称暗号化を含めることを考えたことはありますか? 公開鍵と秘密鍵のペアなどですか？

于 2012-12-11T15:35:54.137 に答える
1

ランダムな要素を含むチャレンジベースの認証プロトコルを使用できる場合、最も理想的ではない解決策だと思います。

そうすれば、パスワードだけでなく、パスワードを使用して正しい応答を生成するコードでもあり、リバース エンジニアリングが必要になります。

次に、双方向認証にすることもできます。つまり、反対側も同じプロトコル/アルゴリズムを使用し、同じパスワードを使用していることを確認できます。

そして最も重要なことは、パスワードがネットワーク経由で送信されることはないため、盗聴できないことです。

Diffie-Helman 鍵交換は、そのような目的で広く使用されているプロトコルの 1 つですが、本当のセキュリティではなく、あいまいさだけが必要な場合は、いつでも独自の単純な実装を作成できます。まあ、すべてを逆コンパイルしてバイトコードからリバースエンジニアリングできるのであれば、本当のセキュリティは明らかに手の届かないところにありますが、とにかく... :)

于 2012-12-11T12:56:18.087 に答える
0

スティーブンの答えが好きですが、追加します...

ソースコードのセキュリティも重要です。パスワードを難読化するためにどのような方法を使用しても、ソースにアクセスできる人なら誰でも、パスワードがSystem.out.println(password)使用されている場所に簡単に入力してキャプチャしたり、デバッグでコードを実行してコードを停止して変数を検査したりできます。

コンパイルしなくても、にアクセスできる人なら誰でもjarJava プログラムをデバッグ モードで起動し、パスワードが使用されているプログラムを停止して、変数を検査できます。ソース コードでは簡単ですが、jar といくつかのツールだけで実行できます。

プログラムが必要なときに (Web サービス呼び出しなどを介して) 安全なサーバーからパスワードを取得し、そのサーバーにファイアウォールを使用させて、特定の IP のみがアクセスできるようにすることを検討することができます (クライアント マシンの IP が知られている）。それはまだ安全ではありませんが、少なくともそれは何かです.

于 2012-12-11T18:15:41.790 に答える
-1

パスワードをハッシュ化し、必要に応じて暗号化することもできます。この投稿を見てください。役に立つかもしれません。Java - 構成ファイルからのユーザー名とパスワードの暗号化/復号化

于 2012-12-11T12:46:09.777 に答える