Java を勉強しているときに、文字列に関連付けられたメモリを手動でクリアすることはできないため、文字列はパスワードを保存するのに安全ではないことを知りました (最終的に gc されるかどうかはわかりません。 gc 物理メモリの内容が本当に消去されたかどうかはわかりません)。代わりに、char 配列を使用することになったので、使用後にそれらをゼロに設定できます。他の言語やプラットフォームで同様の慣行を検索しようとしましたが、これまでのところ関連情報を見つけることができませんでした (通常、セキュリティ上の問題について言及されていない、文字列に格納されたパスワードのコード例が表示されます)。
特にブラウザの状況に関心があります。私は jQuery をよく使用しますが、私の通常のアプローチは、パスワード フィールドの値を空の文字列に設定し、それを忘れることです。
$(myPasswordField).val("");
しかし、それで十分だと 100% 確信しているわけではありません。また、中間アクセスに使用される文字列が安全かどうかもわかりません (たとえば、$.ajaxパスワードをサーバーに送信するために使用する場合)。他の言語に関しては、通常、この問題について言及することはありません (私が特に興味を持っている言語は Python です)。
リストを作成しようとする質問が物議を醸していることは知っていますが、これはほとんど見過ごされている一般的なセキュリティ問題を扱っているため、私見はそれだけの価値があります。私が間違っていれば、JavaScript (ブラウザー内) と Python からだけ知っていただければ幸いです。また、ここで質問するか、 security.SEで質問するか、programmers.SEで質問するかについても確信が持てませんでしたが、タスクを安全に実行するための実際のコードが含まれているため (概念的な質問ではありません)、このサイトが最良の選択肢であると思います。
注：低レベル言語、または文字をプリミティブ型として明確にサポートする言語では、答えは明らかです（編集： @Gabeが以下の答えで示したように、あまり明白ではありません）。私は、「すべてがオブジェクトである」などの高水準言語と、舞台裏で自動文字列インターニングを実行する高水準言語を求めています (そのため、気付かないうちにセキュリティ ホールを作成する可能性があります。十分に注意してください）。
更新：関連する質問の回答char[]によると、 Javaで使用しても防弾（または .NET SecureString、さらに言えば）であるとは限りません.gcが配列を移動する可能性があるため、クリア (SecureString は少なくとも同じ RAM アドレスに固執し、クリアを保証しますが、そのコンシューマー/プロデューサーは依然として痕跡を残す可能性があります)。
@NiklasBだと思います。脆弱性が存在するにもかかわらず、エクスプロイトの可能性は低く、それを防ぐのは難しいため、この問題はほとんど無視されている可能性があります。ブラウザに関するこの問題の参考文献を少なくともいくつか見つけられたらいいのにと思いますが、これまでのところ、グーグル検索は役に立ちませんでした (このシナリオには少なくとも名前がありますか?)。