ログイン時のパスワード送信に関して

Question

つい先日、個人情報の漏洩事件において、一部情報がログから流出したのではないかという記事を読みました。

そこで、パスワード送信に関して以下のようにふと思いました。
・ログイン時のパスワード送信もまかり間違ってログとして残しているケースもあるのではないか？
・そういったケースも想定して、サーバ側に送出されるパスワードは、パッシュ化されているべきなのではないか？

つまり、現状、パスワード照合は
・ブラウザに入力された生パスワードがサーバに送られる
・サーバでは受け取ったパスワードのハッシュ値と DB 上のハッシュ値を比較

といった手順で行われると思いますが、以下の手順で行うべきではないかという疑問です。
・ブラウザに入力された生パスワードをハッシュ化してサーバへ送出
・サーバでは、受け取ったハッシュ値と DB 上のハッシュ値を比較

ちゃんと調べてないですが、ハッシュ値を送出するようなシステムは見かけたことがありません。
なにか仕組み上の問題点があるのでしょうか？

ちょっと質問するタイミングが適切でないので、セキュリティ系の人の手が空くまで、少し長めにオープンにしておきたいと思います。
ご教示いただけると幸いです。

追記

上記と回答の一部を取り込み整理してみました。
クライアントでのハッシュ化に対してご指摘も続けていただきたいのですが、問題点の解決に対してのご提案もいただけると幸いです。

想定している脅威
・ログ等での生パスワードの流出
・生パスワード流出により、パスワードを使い回した他のサイトへ攻撃される

要件
・サーバ側に生パスワードを渡さない

実現方法
・クライアント側でハッシュ化を行い、サーバ側でそのハッシュ値を使用して検証

問題点
・要するに生パスワードの代わりにハッシュ化されたデータを使うということだから、自サイト内に閉じて考えると、セキュリティ強度は変わらない。（他サイトに対しては意味がある？）
・パスワード登録時に、パスワード強度の検証ができなくなる。（フロントのみではダメか？）
・クライアント側でのみハッシュ化を行う場合、自サイト内では生パスワードの保存と同じ状況になるので、流出時に自サイトへの影響はサーバでのハッシュ化時より大きなものになる。（もう一段階ハッシュ化する？）

頂いた回答は、今のところ、否定的ですが、本人はむしろ手応えを感じております＾＾；
面白いと思った方、ご意見やご指摘いただけるとうれしいです。

#さらに追記
以前、同じような質問があったようです＾＾；
SSLを利用したWebサービスでログインパスワードを安全に保存するには？
質問者が非常に真面目な方のようで、活発な意見交換がなされており、勉強になりました。

Answer 1

クライアント側でハッシュ化して送信し、それをサーバーで保存、これはつまり生パスワードの保存なのではないですか？
保存したものがそのままパスワードとして通用するということですよね？

Comments

[退会済みユーザー]

そうです。。。

あぁ、tamoto さんの言う２次ハッシュ化の必要性が理解できました＾＾；
ありがとうございます。

２次ハッシュ化（？）を前提としてクライアントサイドでのハッシュ化の必要性はいかがでしょうか？

[Zuishin]

パスワードに abc を設定する人がいてもチェックできなくなるということですよね？

[退会済みユーザー]

それってなんか解決方法がありそうな気がするんですけど、無理ですかねぇ？

[退会済みユーザー]

フロントのチェックに任せてしまい。それを回避した登録は自己責任ってことでどうでしょうか？

[Zuishin]

ユーザーが設定したパスワードを暗号化したものを真のパスワードとして使うということですね。

しかし、どちらにしてもパスワードを毎回送ることには変わりないので、通信経路での漏洩を心配するなら、リスクは何ら減らないと思います。クライアント側の漏洩対策にもなりませんし、サーバー側の漏洩対策にもなっていません。つまりセキュリティ面では無意味と言わざるを得ないと思います。

tamoto さんのおっしゃるように、サーバーがユーザーが設定したパスワードを保存していないことが明確になることは利点かなとは思いますが、そこから導きだされた真のパスワードを保存していない証明にはならないので、やはりそれほど意味があるようには思えません。

[Zuishin]

パスワードの漏洩対策なら、例えばこんなのはどうでしょう？

ユーザー側で公開鍵と秘密鍵のペアを二種類作り、公開鍵二つをサーバー側で保存します。
ログインする時にはサーバー側でランダムな文字列を作り、公開鍵のうち一つで暗号化してユーザーに送ります。
ユーザーはそれを解読し、もう一つの秘密鍵で暗号化してサーバーに送ります。
サーバーはもう一つの公開鍵でそれを複合化し、元の文字列と比べ、それらが同一であり、また期限内であればログイン成功とみなします。

ただ、ログインだけは厳重になりましたが、通信が傍受されているという前提があるならば、ログイン以降のやり取りは筒抜けなので無意味となります。結局 HTTPS の信頼性にかかっているということなので、生パスワードを通信してもリスクは変わらないということになりそうです。

[退会済みユーザー]

確かに、そのサービスに閉じた質問としてみたときには、Zuishin さんの言うとおりですね。あんまり意味がなさそう＾＾；

ログによるパスワード流出時の他サービスへの影響、簡単に言えば、パスワード使い回しに対しての対策としては意味があるように思いますが、いかがでしょうか？

[退会済みユーザー]

ご提案の方法、まだ咀嚼できていないので、少し悩んでみますね。
ありがとうございます！

[Zuishin]

逆にパスワードを使いまわす口実を与えるのではないでしょうか？

[退会済みユーザー]

提案してもらった方法は、HTTPS と役割が被るのであんまり意味がありそうにないですね。なんかうまい方法があるとイイんですが。

> 逆にパスワードを使いまわす口実を与えるのではないでしょうか？
現実に使いまわしは横行しているの、よくごぞんじでしょｗ

[Zuishin]

そうですね。やってることはまさに HTTPS ですね。認証時に限るということですが。
パスワードはサーバー側が作って一定時間で廃棄されるので、同じパスワードを長期間使いまわすよりは安全だと思いますが、HTTPS 接続がすでにあるので、確かにそれほど違いはないと思います。

パスワードの使いまわしの横行もよく存じております。ただそれは運営の立場としては「危険ですよ」と啓蒙しており、あくまでユーザーが勝手にやっていることです。ですが「使いまわし対策です。これで使いまわして大丈夫」と出すと、使いまわしの責任の一端を運営が被ることになりますよ。

[退会済みユーザー]

使いまわし対策として、実効性があるのであれば、吹聴してもかまわないと思いますが、実際にはタダの時間稼ぎだから、大丈夫なんて言えないですね。使い回しは何らかのパラダイムシフトが起きない限りなくならないと思うので、管理者からすると面倒なことです。。。

Answer 2

パスワードをなんらかのハッシュの形で送信するアプリケーションはあまりないと思いますが、まったくないわけではなくて、一部のパスワード管理ツールはそういう実装をしているそうです。
TLSを使っていても、HeartBleed脆弱性のようなものを想定すると、漏洩のリスクはあります。通常はそういうリスクは許容して、脆弱性対処をしっかりしましょうということになっているのですが、パスワード管理ツールのマスターパスワードが万が一にも漏洩するとリスクが重大なことと、パスワード管理ツールベンダーと言えども利用者の生パスワードを知り得ないことを保証する（従業員による不正防止等）ために、そのような実装をしているのだと思います。
たとえば、Lastpassはそのような実装をしているのだそうです。私自身はLastpassの実装を詳しく追ったわけではないですが、興味がおありなら調べてみてはいかがでしょうか?

Comments

[退会済みユーザー]

回答ありがとうございます。
全く無いわけではないのですね。

今回の件、今のところ趣味の範囲ですが、非常に興味を持ってやってます。
ご紹介いただいた Lastpass の実装、調べてみます。

ヒント、大変助かりました。

Answer 3

こんにちは。

自分はWebの技術者でもないですが、同じ疑問と提案をずっと持っていたので、この質問には注目しています。

個人的な意見の一つですが。
いくら経路をHTTPSで保護しているからといって、そのパイプを生パスワードが通るというのは少し気持ち悪く感じています。サービス提供者がパスワードを適切に扱っていることを完全に信頼しないといけないというのは、利用者としては若干負担があると思います。
しかし、もしクライアントサイドでの一次ハッシュ化を行うとすると、実用上では、サーバ側が指定されたパスワードの健全性を確認することができなくなるというサービスの問題が発生することがわかります。例えばパスワードがただ一文字aであったとしても、ハッシュとしては健全なパラメータに見えてしまいます。こちらは、殆どのサービスでパスワードの検証が行われるため、大きなデメリットに見えます。
また、クライアントから送られてきたハッシュ値が正しくハッシュ関数を通したものであるかを検証することができません。この場合はユーザのパスワードが文字列ではなくなるだけで、運用上は問題ないと思いますが。
最後に、WebUIを介さないアクセスを行う際に、サービスを利用する開発者がパスワードのハッシュ化処理を実装しなければならなくなることです。こちらは利用するハッシュ化関数を公開しておけば、多少実装の手間が掛かる程度でしょう。
どちらにせよ、サーバ側で受け取ったハッシュにソルトを付けて二次ハッシュ化は必須です。サーバで生保存してしまうと平文となんの違いもありません。

個人的には、上記のデメリットを差し引いても、クライアント側での一次ハッシュ化はアリだと考えています。「サーバが決して生パスワードを保存しない」ということをソースコード上に記述できるというのはユーザ目線での安心感が段違いです。

Comments

[退会済みユーザー]

回答ありがとうございます。

> もしクライアントサイドでの一次ハッシュ化を行うとすると、実用上では、サーバ側が指定されたパスワードの健全性を確認することができなくなるというサービスの問題が発生することがわかります。例えばパスワードがただ一文字aであったとしても、ハッシュとしては健全なパラメータに見えてしまいます

確かに！ただ、なんか巧いやり方もありそうな気がします。

> どちらにせよ、サーバ側で受け取ったハッシュにソルトを付けて二次ハッシュ化は必須です。サーバで生保存してしまうと平文となんの違いもありません。

こちらがよく理解できません。
2次ハッシュ化って必要でしょうか？平文保存が NG なのは流出時のリスク回避だと認識しているため、２次ハッシュ化の必要性がよく分かりません。
もう少し説明いただいてよいでしょうか？

> 「サーバが決して生パスワードを保存しない」ということをソースコード上に記述できるというのはユーザ目線での安心感が段違いです。

そうなんですよねぇ。まぁこれで安心する人は、かなり限られていますがｗ安心度合いは段違いですね。

[退会済みユーザー]

Zuishin さんの指摘で、２次ハッシュ化の意図が理解できました。
当たり前ですが、こちらも漏洩対策ですね＾＾；

[tamoto]

はい、その通りです。サーバが受け取ったハッシュをそのまま保存した場合、漏洩したハッシュ値をそのまま使ってサービスに侵入できてしまうことになります。
クライアント側でのハッシュ化による他のメリットは、万が一の経路上での流出の際に「他サービスでのパスワード使い回しによる二次被害」をほぼ回避できるというのもありますね。
健全性チェックは、ユーザの良心に任せてクライアント側チェックしかない気がします。サーバ側でも頑張って調べるなら、「正しいハッシュ文字列を構成している」みたいなあんまり意味なさそうなチェックとか、もっと頑張るなら「頻出パスワードを一次ハッシュ化した辞書を持っておいてマッチングチェック」くらいが精一杯だと思います。

Answer 4

結論から言うと、この実装は最悪です。

一般的に、DBにハッシュ化されたパスワードを保存する場合、通常、パスワードに秘密の文字列をつけてハッシュ関数に渡してハッシュ化すると思います。
ブラウザ上で処理するということは、javascriptを使うことになるかと思いますが、これはソースがオープンです。つまり秘密の文字列もオープンになってしまいます。

よって、この実装だと、パスワードを平文で保存しているのと同義で、通常の方法より格段にセキュリティーレベルは低いです。

Comments

[退会済みユーザー]

回答ありがとうございます。

> 秘密の文字列もオープンになってしまいます。

ここがよく分かりません。秘密の文字列がオープンになると問題なのでしょうか？

> この実装だと、パスワードを平文で保存しているのと同義で、通常の方法より格段にセキュリティーレベルは低いです。

平文パスワードの保存がセキュリティレベルを下げているとは思いません。漏洩リスクを考え、ハッシュ化しているものと認識しています。
どういった点でセキュリティレベルが下がるのでしょうか？

[ockeghem]

この回答には賛同しません。質問者の実装がよくない理由はZuishinさんの指摘の通りで、「秘密の情報」が漏れるというのは二次的なものです。そもそも「秘密の情報」という言い方がよくないのですが、パスワードのソルト(Salt)はハッシュ値とともに保存することが一般的で、ハッシュ値が漏洩する局面ではソルトも漏洩するので、むやみに公開するのもどうかとは思いますが、もれたから致命的というわけでもありません。

[CodeLab]

Saltが漏れることで攻撃者にヒントを与えることになります。
ブルートフォースアタックをかける場合、ハッシュ化の方法やソルトがわからない状態であれば、実際にサーバーにアクセスするしか方法がありませんが、これはサーバー側で回数制限などを行うなどでブロックが可能です。しかし、この方法では方法やソルトがバレてしまっているので、ローカルで計算できてしまいます。
ハッシュからパスワードを探すことができてしまいますので、あまり良いこととは思えません。

[退会済みユーザー]

Salt とハッシュ値がセットになっているとローカルでのパスワード検証が可能（というか、今回実装イメージの場合はハッシュ値でログイン可能）ですが、ockeghem さんが書いてくれている通り、Salt だけ漏れても大した影響はありません。ハッシュ値がもれない限りはハッシュ化の方法が漏れても大した影響はないはずです。

もし私の勘違いで、Salt のみの流出でローカルで計算する方法があるのであれば、ご教示いただけると助かります。

Answer 5

クライアント側まで専用アプリのある環境で、通信ごとに異なるnonceを付けてやり取りするなら別ですが、ブラウザで行ってもあまり意味はありません。

というのも、ブラウザに組み込むプラグインでMITB（Man in the Browser、ブラウザ内攻撃）を行う、OS側にロガーを仕込むなど、攻撃の経路はいくらでもあるわけですし、JavaScriptはクライアント側で実行するものである以上、セキュアなコードを実装することができないからです。

Comments

[退会済みユーザー]

回答ありがとうございます。

> ブラウザに組み込むプラグインでMITB（Man in the Browser、ブラウザ内攻撃）を行う、OS側にロガーを仕込むなど、攻撃の経路はいくらでもあるわけですし、JavaScriptはクライアント側で実行するものである以上、セキュアなコードを実装することができないからです。

この観点は、通常のパスワードの利用時にも同じことが言えるのではないでしょうか？ブラウザでハッシュ化することで発生するのでしょうか？

[maisumakun]

いえ、「ブラウザでハッシュ化」という手間を掛けても、これらのリスクの軽減にはならない、という意味合いです。

[退会済みユーザー]

コメントありがとうございます。
ちょっと理解が追いついていないので、少し悩んでみます。
すみません。至らない頭で＾＾；

Answer 6

大変有益な気づきをいくつもいただきました！
皆様、ありがとうございます。

システムの都合で、一名を選ばなければならないため、Zuishin さんに BA をつけましたが、２次ハッシュ化（？）と Lastpass から受けた刺激は非常に大きかったです。

今後ともよろしくお願いします。