HTTPSを介したプレーンテキストパスワード

私は現在、HTTPS（したがってSSL暗号化）で動作するPHP OpenIDプロバイダーに取り組んでいます。
それは間違っている私は、プレーンテキストとしてパスワードを送信するために？理論的にはHTTPSはインターセプトできないため、何も問題はありません。または、これはあるレベルで安全ではなく、私はこれを見逃していますか？

安全。これがウェブ全体の仕組みです。フォーム内のすべてのパスワードは常にプレーンテキストで送信されるため、セキュリティで保護するのはHTTPSまでです。

それでも、GETではなくPOSTリクエストで送信する必要があります。GETリクエストで送信した場合、ユーザーのブラウザの履歴ログまたはウェブサーバーのアクセスログにプレーンテキストで保存できます。

HTTPが無効で、HTTPS のみを使用している場合、実際にはパスワードをプレーンテキストとして送信しているわけではありません。

ハッシュクライアント側。どうして？ちょっとした実験についてお話ししましょう。会社の食堂のコンピューターまで歩きます。ブラウザーを開いて会社のWebサイトのログインページ（https）にアクセスします。F12キーを押し、ネットワークタブをクリックして、ログを確認し、コンソールを最小化しますが、Webページを開いたままにしてログインページを開きます。座ってランチを食べます。従業員が会社のWebサイトにログオンした後、従業員がよく仕事をしてからログアウトします。昼食を済ませ、コンピューターの前に座ってネットワークタブを開き、フォームの本文にすべてのユーザー名とパスワードをプレーンテキストで表示します。

特別なツール、特別な知識、豪華なハッキングハードウェア、古き良きF12のキーロガーはありません。

しかし、ねえ、必要なのはSSLだけだと考え続けてください。悪者はあなたを愛します。

以前の回答にいくつかのメモを付けましょう。

まず、クライアント側でハッシュアルゴリズムを使用することはおそらく最善の方法ではありません。パスワードがサーバー側でソルト化されている場合、ハッシュを比較することはできません（少なくとも、パスワードのハッシュレイヤーの1つでデータベースにクライアントハッシュを格納しない場合は、同じか、悪い）。また、クライアント側のデータベースで使用されるハッシュアルゴリズムを実装したくない場合は、ばかげています。

次に、暗号化キーのトレードオフも理想的ではありません。MITMは理論的には（クライアントにルート証明書がインストールされていることを考慮して）暗号化キーを変更し、独自のキーで変更することができます。

鍵を交換する理論上のサーバーからの元の接続（tlsは考慮しない）：

クライアント要求の公開鍵>サーバーが秘密鍵を保持し、クライアントに公開鍵を生成>サーバーが公開鍵をクライアントに送信

さて、理論的なMITMのatrackで：

クライアント要求の公開鍵> MITMが偽の秘密鍵を生成 >サーバーが秘密鍵を保持し、クライアントに公開鍵を生成> MITMが元のサーバーから公開鍵を受信、今、私たちは偽の公開鍵をクライアントに自由に送信できます。クライアントからリクエストが来たときはいつでも、偽のキーでクライアントデータを復号化し、ペイロードを変更（またはそれを読み取り）して、元の公開キーで暗号化します > MITMは偽の公開キーをクライアントに送信します。

これがTLSで信頼されたCA証明書を持つポイントであり、証明書が有効でない場合にブラウザ警告からメッセージを受信する方法です。

OPへの応答：私の控えめな意見では、遅かれ早かれ誰かがサービスからユーザーを攻撃したいので、プロトコルを破ろうとするので、それはできません。

ただし、できることは、2FAを実装して、人々が同じパスワードでログインしようとするのを防ぐことです。ただし、リプレイ攻撃に注意してください。

私は暗号が得意ではありません。間違っている場合は修正してください。

他のポスターは正しいです。今、あなたは暗号化するために、SSLを使用していることを伝送それはだとき、それが保護されますので、パスワードのを、優れたアルゴリズムと塩と必ずしているハッシュそれを作る安静時すぎ、...

@CodeDogの例には問題があります。

はい、ユーザーはカフェテリアボックスにログインすると思います。企業のカフェテリアからログをキャプチャする場合は、セキュリティ違反です。企業のカフェテリアボックスは、無効にしてセットアップする必要があります。たとえば、条件なし、ロガーなし、リモートアクセスなしなどです。あなたを防ぐために、内部ハッカー。

この例は、コンピュータアクセスセキュリティの良い例であり、ネットワークセキュリティとは実際には関係ありません。これはクライアント側のハッシュの正当化として提供されていますが、コンピューターにアクセスできる場合は、キーストロークロガーを使用してバイパスすることができます。クライアント側のハッシュも関係ありません。@CodeDogによる例はコンピューターアクセスハックであり、ネットワークレイヤーハックとは異なる手法が必要です。

また、前述のように、公共のコンピュータハックは、システムを脅威から保護することで保護されています。たとえば、公共のカフェテリアコンピュータにChromebookを使用します。しかし、それは物理的なハックによって回避されます。営業時間外は、カフェテリアに行き、秘密のカメラをセットアップして、ユーザーによるキーボードプレスを記録します。その場合、カフェテリアコンピュータが壊れているかどうか、またはどのタイプの暗号化が使用されているかは問題ではありません。

物理層->コンピュータ層->クライアント層->ネットワーク層->サーバー層

ネットワークの場合、https / sslレイヤーがプレーンパスワードを暗号化するため、クライアント側でハッシュするかどうかは問題ではありません。したがって、他の人が言及しているように、TLSが安全であれば、クライアントのハッシュは冗長です。