httpsを介したプレーンテキストは本当に良いアイデアですか？
Httpsを介したプレーンテキストのパスワードの送信は非常に安全で、トラフィックは暗号化されているため、盗聴は事実上不可能です。
ただし、サーバー側では、プレーンテキストのままです。もちろん、パスワードを保存するには適切な暗号化などが必要ですが、監視ツールやロギングなどはどうでしょうか？プレーンテキストのパスワードがログなどに残ることはありませんか？ POSTを使用する場合でも？
通信を監視すると、プレーンテキストのパスワードも表示されます。プレーンテキストの代わりに単純なダイジェストを使用すると、それを見て覚えることが難しくなります。はい、とにかく多くの機密データにアクセスできます。はい、レインボーテーブルを使用してMD5ハッシュを復号化できます。私たちが悪いことをしたいなら、私たちは悪いことをすることができます。しかし、なぜ私と同僚がプレーンテキストのパスワードを見る可能性を許可する必要があるのでしょうか。
人々は複数のオンラインサービスに同じパスワードを使用する傾向があるため、誰かのパスワードを持っていると、その人の私たちのデータだけにアクセスできなくなります。
良いアイデアは時間制限があります。
MD5を使用してパスワードを保護することは、かつては良い考えでした。その後、レインボーテーブルとMD5の衝突が発見されました。だから今は悪い考えです。
HTTPを介してプレーンテキストのパスワードを送信することは非常に悪い考えです。HTTPSを介してプレーンテキストのパスワードを送信することは非常に良いアイデアです比較すると、まだありますあなたが取ることができるより良いアプローチ。
メモリ-一般的なガイドとして、資格情報の送信先のサーバーは安全であると想定する必要があるため、プレーンテキストのパスワードについてはあまり気にしないでください超安全なアプリケーションを開発するつもりがない限り、メモリに保持されます。
Logs-通常、ログにはHTTP POST/UPDATEデータが含まれていません。これは、そのデータが潜在的に非常に機密性が高いためです。暗号化されていないログファイルに保存すると、違法であること-クライアントが支払いを処理するためにクレジットカードの詳細を提出する場合など。
パスワードのみをHTTPリクエスト本文の一部として送信する必要がありますneverサイトのURLに含まれ、HTTPヘッダーにも含まれないことが望ましい。 BASIC HTTP認証 ヘッダーのパスワードフィールドを使用し、基本的にはBase64で保護されています。ただし、これは、パスワードがショルダーサーフィンされるのを防ぐためだけであり、他の何からも保護しません。
Client Side Password Hashing を見ることができます。これは、サーバーに送信される前にクライアント側でパスワードをハッシュすることを含みます-したがって、サーバーでさえ実際のパスワードテキストを保持することはありません（さらにいずれにせよ、ソルトとハッシュを使用してください）が、これはセットアップがより複雑であり、何をしているのか完全に理解していない人にはお勧めできません。
HTTPSを介したプレーンテキストパスワードの送信は安全です。
ロギングについて懸念がある場合は、フレームワークやツールを含む実装全体を確認する必要があります。変数のコンテンツにアクセスする前にデータを取得するAOPコードが存在する場合があります。したがって、コードのロギングはセキュリティ上の問題になる可能性があります。
ハッシュする前に、必ずパスワードにソルトを追加することを忘れないでください。