[解決済み] サーバー側に送信する前にパスワードをハッシュ化した方が良いですか？

質問

ほとんどのサイトで、パスワードが HTTPS 上で平文としてサーバーに送信されていることに気づきました。その代わりに、パスワードのハッシュをサーバーに送信した場合、何か利点があるのでしょうか。それはより安全でしょうか?

どのように解決するのですか？

これは古い質問ですが、この重要な問題について私の意見を述べる必要があると感じました。 ここには多くの誤った情報があります。

OP は、HTTP 上でパスワードをクリアで送信することについては言及していません - HTTPS のみですが、多くの人が何らかの理由で HTTP 上でパスワードを送信する質問に回答しているようです。 とはいえ

私は、パスワードは決して平文で保持されるべきではないと考えています (送信は言うに及ばず)。 つまり、ディスク上にも、メモリ上にも保持されるべきではないということです。

ここで回答している人々は、HTTPS が特効薬であると考えているようですが、そうではありません。 しかし、それは確かに大きな助けとなり、あらゆる認証セッションで使用されるべきものです。

オリジナルのパスワードが何であるかを知る必要は本当にありません。 必要なのは、ユーザーによって選択されたオリジナルのテキストに基づいて認証キー(quot;key)を生成する (そして確実に再生成する) 信頼できる方法だけです。 理想的な世界では、このテキストは、不可逆的なソルトを使用してハッシュ化することで、直ちに「キー」を生成する必要があります。 このソルトは、生成されるユーザー・クレデンシャルに固有である必要があります。 このquot;key"は、システムがパスワードとして使用するものです。 これにより、将来的にシステムが危険にさらされた場合、これらのクレデンシャルは自分の組織に対してのみ有効であり、ユーザーが同じパスワードを使用していたとしても、他のどこにも通用しなくなります。

これで鍵は手に入りました。 今度は、クライアントのデバイス上にあるパスワードの痕跡をすべて消去する必要があります。

次に、その鍵をあなたのシステムに転送する必要があります。 鍵やパスワードは決して平文で送信してはいけません。 HTTPS でさえもです。 HTTPS は侵入できないものではありません。 実際、多くの組織が信頼できる MITM になることができます。攻撃の観点からではなく、独自のセキュリ ティ方針を実行するためにトラフィックに対する検査を実行するためです。 これは HTTPS を弱体化させるものであり、それが起こるのはそれだけではありません（例えば HTTP MITM 攻撃へのリダイレクトなど）。 決して安全だと思い込まないようにしてください。

これを回避するために、私たちはキーをワンス オフ nonce でハッシュ化します。 この nonce は、システムにキーを送信するたびに、たとえ同じセッション中に同じクレデンシャルであっても、複数回送信する必要がある場合に一意となります。 認証キーを復元し、リクエストを認証するために、自分のシステムに到着した時点でこの nonce を逆引きすることができます。

この時点で、私は自分のシステムに永久に保存される前に、最後にもう一度不可逆的にハッシュ化します。 そうすれば、SSO などの目的でパートナー組織とクレデンシャルの salt を共有できる一方、自分の組織がユーザーになりすますことができないことを証明することができます。 この方法の最もよい部分は、ユーザーが生成したものを、ユーザーの承認なしに決して共有しないことです。

私が明かした以上のことがあるので、もっと研究してください。しかし、ユーザーに真のセキュリティを提供したいのであれば、この方法が現在最も完全な対応策だと思います。

TL;DR:

HTTPS を使用する。 パスワードごとに一意のソルトを使用して、パスワードを不可逆的に安全にハッシュ化します。 これはクライアント側で行い、実際のパスワードは送信しないようにします。 ユーザーの元のパスワードをサーバーに送信することは、決して OK や Fine ではありません。 元のパスワードの痕跡はすべて消去する。 以下のような ノンス を使用する。 それは多くのレベルでより安全です。(OPへの回答)。