パスワードをサーバー側に送信する前にハッシュする必要がありますか？
ほとんどのサイトがパスワードをプレーンテキストとしてHTTPS経由でサーバーに送信することに気付きました。その代わりにパスワードのハッシュをサーバーに送信した場合、利点はありますか？より安全ですか？
これは古い質問ですが、この重要な問題について意見を述べる必要があると感じました。ここには多くの誤報があります
OPは、HTTPを介してパスワードを明確に送信することを決して言及しませんでしたが、HTTPSのみを使用していますが、何らかの理由でHTTPを介してパスワードを送信するという質問に回答しているようです。それは言った：
パスワードをプレーンテキストで保持する（送信するだけで）べきではないと考えています。つまり、ディスクやメモリに保存されないことを意味します。
ここで応答する人々は、HTTPSは銀の弾丸であると考えているようですが、そうではありません。ただし、これは確かに大いに役立ち、認証されたセッションで使用する必要があります。
元のパスワードが何であるかを本当に知る必要はありません。必要なのは、認証を生成する（そして確実に再生成する）信頼できる方法ですユーザーが選択した元のテキストに基づく「キー」。理想的な世界では、このテキストは、不可逆的な塩を使用してハッシュ化することにより、すぐに「キー」を生成するはずです。このソルトは、生成されるユーザー資格情報に固有でなければなりません。この「キー」は、システムがパスワードとして使用するものになります。このように、システムが将来侵害された場合、これらの資格情報は自分の組織に対してのみ有用であり、ユーザーが怠けて同じパスワードを使用した他の場所では役に立ちません。
キーがあります。次に、クライアントデバイスのパスワードのトレースをクリーンアップする必要があります。
次に、そのキーをシステムに取得する必要があります。キーやパスワードを「平文で」送信しないでください。 HTTPS経由でもありません。 HTTPSは不可解ではありません。実際、多くの組織は、攻撃の観点からではなく、トラフィックの検査を実行して独自のセキュリティポリシーを実装することで、信頼できるMITMになることができます。これはHTTPSを弱くし、それが起こる唯一の方法ではありません（たとえば、HTTP MITM攻撃へのリダイレクトなど）。安全だと思い込まないでください。
これを回避するために、1回限りのナンスでキーをハッシュします。このナンスは、システムにキーを送信するたびに一意です。複数回送信する必要がある場合、同じセッション中の同じ資格情報であっても同じです。独自のシステムに到着したこのナンスを元に戻して、認証キーを回復し、リクエストを認証できます。
この時点で、あなたのシステムに永続的に保存される前に、最後にもう一度不可逆的にハッシュします。そうすれば、SSOなどの目的で資格情報の塩をパートナー組織と共有できますが、独自の組織がユーザーになりすますことができないことを証明できます。このアプローチの最大の利点は、許可なしにユーザーが生成したものを決して共有しないことです。
私が明かした以上に多くの研究がありますが、ユーザーに真のセキュリティを提供したい場合、この方法が現在ここで最も完全な応答であると思います。
TL; DR：
HTTPSを使用します。パスワードごとに一意のソルトを使用して、パスワードを不可逆的に安全にハッシュします。クライアントでこれを行います-実際のパスワードを送信しません。ユーザーの元のパスワードをサーバーに送信することは決して「OK」または「Fine」ではありません。元のパスワードのトレースをクリーンアップします。 HTTP/HTTPSに関係なく nonce を使用します。多くのレベルではるかに安全です。 （OPへの回答）。
HTTPS経由であるため、ハッシュなしでパスワードを送信することは間違いなく問題ありません（HTTPS経由ではプレーンテキストではありません）。さらに、アプリケーションがコンテンツの安全性を保つためにHTTPSに依存している場合、HTTPSで送信する前にパスワードをハッシュすることは役に立ちません（つまり、攻撃者がワイヤ上のデータを暗号化解除できる場合、とにかくねじ込まれます）
いいえ、実際にはこれは脆弱性になります。攻撃者がデータベースからハッシュを取得できる場合、そのハッシュを使用して、クラッキングする必要なく認証できます。どのような状況でも、ユーザーまたは攻撃者がハッシュパスワードを取得することはできません。
パスワードをハッシュすることの全体的なポイントは、セキュリティの層を追加することです。攻撃者がSQLインジェクションまたは安全でないバックアップを使用してデータベースからハッシュとソルトを取得できる場合、ブルートフォースでプレーンテキストを見つける必要があります。 John The Ripper は、ソルトパスワードハッシュを解除するために一般的に使用されます。
Httpsを使用しないと、OWASPトップ10に違反します。 A9-Insufficient Transport Layer Protection
EDIT：実装でsha256(client_salt+plain_text_password)を計算してから、サーバー側で別のハッシュを計算する場合sha256(server_salt+client_hash)これは深刻な脆弱性ではありません。ただし、それでもリクエストを盗聴してリプレイする可能性があります。したがって、これは依然としてWASP A9の明らかな違反です。ただし、これはまだセキュリティ層としてメッセージダイジェストを利用しています。
Httpsのクライアント側の置き換えに私が見た最も近いものは、 javascriptのキー交換のdiffie-hellman です。ただし、これはアクティブなMITM攻撃を防ぐため、技術的にはOWASP A9に違反します。コードの作成者は、これがHTTPSに完全に置き換わるものではないことに同意しますが、何もないよりもクライアント側のハッシュシステムよりも優れています。
攻撃者は単純にハッシュを送信し、パスワードを忘れてしまう可能性があるため、ネットワーク経由でハッシュを送信すると、ハッシュの目的が完全に無効になります。一言で言えば、クリアテキストでハッシュを使用して認証するシステムは広く開かれており、ネットワークスニッフィング以外の何ものでも妥協することはできません。
平文のパスワードは（HTTPSを使用している場合でも）決してクライアントから離れません。サーバーが実際のパスワードを知る必要がないため、クライアントを離れる前に不可逆的にハッシュする必要があります。
ハッシュしてから送信すると、複数の場所で同じパスワードを使用する怠usersなユーザーのセキュリティ問題が解決します（私は知っています）。ただし、ハッカーはハッシュを送信してサーバーに受け入れさせるだけであるため、データベースにアクセスした（または他の方法でハッシュを取得できた）ハッカーとしてのアプリケーションは保護されません。
この問題を解決するには、もちろん、サーバーが受信したハッシュをハッシュし、1日で呼び出すことができます。
私が作成しているソケットベースのWebアプリケーションの問題への私のアプローチは、クライアントへの接続時にサーバーがソルト（ハッシュの前に追加されるランダムな文字列）を生成し、ソケット変数に保存してから、このハッシュを送信することですクライアントに。クライアントは、ユーザーのパスワードを取得してハッシュし、サーバーからソルトを追加し、サーバーに送信する前にすべてをハッシュします。次に、サーバーに送信され、このハッシュとハッシュ（DB内のハッシュ+ソルト）が比較されます。私が知る限り、これは良いアプローチですが、公平を期すために、私はトピックについてあまり読みませんでした。
HTTPS経由のクリアテキストパスワードをHTTP経由のハッシュ化されたパスワードに置き換える場合は、トラブルを求めています。 HTTPSは、通信チャネルを開くときにランダムな共有トランザクションキーを生成します。 （比較的）短期的なトランザクションに使用される共有キーをブルートフォースすることにほとんど制限されているため、これを解読するのは困難です。ハッシュをスニッフィングし、オフラインにしてレインボーテーブルで検索するか、長時間にわたって強引に強制することができます。
ただし、HTTPS経由で送信される基本的なクライアント側のパスワード難読化（ハッシュではない）には何らかの価値があります。誤解しない限り、この手法は実際にいくつかの銀行で使用されています。この手法の目的は、パスワードを盗聴から保護することではありません。むしろ、表示されるすべてのHTTPS GET/POSTリクエストを取得するだけの愚かなスパイツールやブラウザプラグインがパスワードを使用できないようにすることです。ユーザーセッションからキャプチャされた400MBのランダムなGET/POSTトランザクションである悪意のあるWebサイトからキャプチャされたログファイルを見ました。 HTTPSのみを使用したWebサイトはログにクリアテキストのパスワードで表示されますが、非常に基本的な難読化（ROT13）のあるWebサイトもすぐに使用されないパスワードで表示されると想像できます。
HTTPダイジェストを使用-HTTP経由でもパスワードを保護します（ただし、HTTPS経由のHTTPダイジェストが最適です）
ウィキペディア：
HTTPダイジェストアクセス認証は、Webサーバーが（HTTPプロトコルを使用して）Webユーザーと資格情報をネゴシエートするために使用できる合意された方法の1つです。ダイジェスト認証は、基本アクセス認証の暗号化されていない使用に取って代わることを目的としており、ネットワーク上でパスワードをプレーンテキストで送信することなく、ユーザーIDを安全に確立できます。ダイジェスト認証は基本的に、暗号解析を防ぐためにナンス値を使用するMD5暗号化ハッシュのアプリケーションです。
リンク： http://en.wikipedia.org/wiki/Digest_access_authentication
「実際の」使用方法を確認するには、phpMyIDを参照します。これは、httpダイジェスト認証を使用するphp openidプロバイダーです http://siege.org/phpmyid.php
..または http://php.net/manual/en/features.http-auth.php のphp authサンプルから開始できます
HTTPダイジェストrfc： http://www.faqs.org/rfcs/rfc2617
私のテストでは、すべての最新のブラウザーがサポートしています...
免責事項：私はセキュリティの専門家ではありません。希望で投稿しています。他の人は自分の立場を過度に慎重または改善可能であると批判し、そこから学びますそうは言っても、クライアントを離れるときのハッシュは、データベースに入れる前にバックエンドでハッシュする必要がないことを強調したいだけです。
両方を行う
両方を行うのは：
乗り継ぎでハッシュすることは、トランスポートの脆弱性をカバーするのに役立ちます。SSL接続が危険にさらされた場合でも、生のパスワードを見ることができません。許可されたユーザーになりすますことができるという点では重要ではありませんが、ユーザーがパスワードをメールと関連付けて読み取られるのを防ぎます。ほとんどの人はベストプラクティスに従っていないため、多くのアカウントで同じパスワードを使用しているため、これは訪問者にとって深刻な脆弱性となります。
誰かが何らかの方法でデータベースからパスワードを読み取ることができた場合（これは、SQLインジェクションと考えられます）、APIを介してユーザーになりすます特権アクションを実行することはできません。これは、ハッシュの非対称性によるものです。 DBに保存されているハッシュを知っていても、それを作成するために使用された元のキーを知らないため、認証ミドルウェアが認証に使用します。これは、常にハッシュストレージをソルトする必要がある理由でもあります。
確かに、データベースから必要なものを自由に読み取ることができれば、他の多くの損害を与える可能性があります。
ここで強調したいのは、クライアントから出発する前にキーをハッシュすることに決めた場合、それだけでは十分ではないことです-バックエンドハッシュはより重要であり、これが理由です：クライアント、passwordフィールドの内容が表示されます。これがハッシュであろうとプレーンテキストであろうと、問題ではありません。彼らはそれを逐語的にコピーして、許可されたクライアントになりすますことができます。 （@ user3299591で説明されている手順に従わない限り、実行することをお勧めします）。一方、DBカラムをハッシュすることは必要であり、実装はまったく難しくありません。
Httpsサーバーに接続している場合は、サーバーとブラウザー間のデータストリームを暗号化する必要があります。データは、送信前および受信後はプレーンテキストのみです。 ウィキペディアの記事
SSL/TLSはnonceに取って代わりませんか？ SSL/TLSはリプレイ攻撃からも保護するため、この付加価値はありません。
パスワードをハッシュし、暗号化されていないチャネルを介して送信することは、実際には安全性が低くなります。クライアントでハッシュアルゴリズムを公開します。ハッカーはパスワードのハッシュを盗聴し、それを使用して後でハッキングすることができます。
HTTPSでは、暗号化された2つのチャネルを使用するため、ハッカーが単一のソースからパスワードを取得することを防ぎます。