質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.34%

  • セキュリティー

    557questions

    このタグは、コンピューターシステムの安全性やデータの機密性に関連したトピックの為に使われます。

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

解決済

回答 6

投稿 編集

  • 評価
  • クリップ 5
  • VIEW 4,231

te2ji

score 15788

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

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

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

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

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

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

 追記

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

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

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

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

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

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

さらに追記

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

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 6

checkベストアンサー

+7

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/16 12:55

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

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

    キャンセル

  • 2017/05/16 13:09

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

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

    キャンセル

  • 2017/05/16 13:34

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

    キャンセル

+5

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/16 13:23

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

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

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

    キャンセル

+3

こんにちは。

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/16 08:59

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

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

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

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

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

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

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

    キャンセル

  • 2017/05/16 09:13

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

    キャンセル

  • 2017/05/16 17:56

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

    キャンセル

+2

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/16 08:39

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

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

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

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

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

    キャンセル

  • 2017/05/16 13:05

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

    キャンセル

  • 2017/05/24 18:12

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

    キャンセル

  • 2017/05/25 13:04 編集

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

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

    キャンセル

+2

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/05/16 09:23

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

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

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

    キャンセル

  • 2017/05/16 09:25

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

    キャンセル

  • 2017/05/16 09:27

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

    キャンセル

0

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.34%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

同じタグがついた質問を見る

  • セキュリティー

    557questions

    このタグは、コンピューターシステムの安全性やデータの機密性に関連したトピックの為に使われます。