HTTPS経由のプレーンテキストパスワード
現在、PHP OpenIDプロバイダーで作業しています（HTTPSで暗号化されているため）。
パスワードをプレーンテキストとして送信するのはwrongですか？理論的にはHTTPSは傍受できないため、何も問題はありません。または、これはあるレベルで安全ではなく、私はこれを見逃していますか？
安全。これがウェブ全体の仕組みです。フォーム内のすべてのパスワードは常にプレーンテキストで送信されるため、HTTPSで保護されます。
GETではなくPOSTリクエストで送信することを確認する必要があります。GETリクエストで送信する場合、ユーザーのブラウザ履歴ログまたはWebサーバーのアクセスログにプレーンテキストで保存できます。 。
HTTPが無効で、only HTTPSを使用する場合、実際にはパスワードをプレーンテキストとして送信していません。
ハッシュクライアント側。どうして？ちょっとした実験についてお話ししましょう。社員食堂のコンピューターまで歩いてください。ブラウザから会社のWebサイトのログインページ（https）を開きます。 F12キーを押して、[ネットワーク]タブをクリックし、ログの保存をオフにし、コンソールを最小化しますが、Webページはログインページのままにしておきます。座って昼食を食べます。従業員が会社のWebサイトにログオンし、作業を終えたらすぐにログアウトするように注意してください。昼食を終え、コンピューターに座ってネットワークタブを表示し、フォーム本文のプレーンテキストですべてのユーザー名とパスワードを確認します。
特別なツール、特別な知識、派手なハッキングハードウェア、古き良きF12キーロガーはありません。
ただし、必要なのはSSLだけだと考え続けてください。悪者はあなたを愛します。
他のポスターは正しいです。 SSLを使用してパスワードのtransmissionを暗号化しているので、適切なアルゴリズムとソルトでハッシュ化して、restのときに保護されるようにしてください。あまりにも...
以前の回答にメモを作りましょう。
まず、クライアント側でハッシュアルゴリズムを使用することはおそらく最善のアイデアではありません。パスワードがサーバー側でソルトされている場合、ハッシュを比較することはできません（少なくとも、同じまたは同じパスワードのハッシュレイヤーのいずれかのデータベースにクライアントハッシュを保存しない場合悪い）。また、クライアント側のデータベースで使用されるハッシュアルゴリズムを実装したくない場合、それはばかげています。
第二に、暗号キーのトレードオフも理想的ではありません。 MITMは、理論的には（クライアントにルート証明書がインストールされていると考えて）暗号化キーを変更し、自分のキーで変更できます。
キーを交換する理論上のサーバーからの元の接続（TLを考慮しない）：
クライアントが公開鍵を要求する>サーバーが秘密鍵を保持し、クライアントに公開鍵を生成する>サーバーがクライアントに公開鍵を送信する
さて、理論的なMITM atrackでは：
クライアントが公開鍵を要求する> MITMは偽の秘密鍵を生成する>サーバーは秘密鍵を保持し、クライアントへの公開鍵を生成する> MITMは元のサーバーから公開鍵を受け取る、今は自由です偽の公開鍵をクライアントに送信し、クライアントからリクエストが来るたびに、偽の鍵でクライアントデータを復号化し、ペイロードを変更（または読み取り）し、元の公開鍵で暗号化します> MITM偽の公開鍵をクライアントに送信します。
これが、TLSで信頼されたCA証明書を持つことのポイントであり、証明書が有効でない場合にブラウザから警告メッセージを受信する方法です。
OPへの回答：謙虚な意見では、遅かれ早かれ、誰かがあなたのサービスからユーザーを攻撃したいと思って、あなたのプロトコルを破ろうとするからです。
ただし、できることは、2FAを実装して、同じパスワードでログインしようとすることを防ぐことです。ただし、リプレイ攻撃には注意してください。
私は暗号技術が得意ではありません。間違っている場合は修正してください。