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

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

ただいまの
回答率

91.34%

  • Webサイト

    790questions

    一つのドメイン上に存在するWebページの集合体をWebサイトと呼びます。

  • セキュリティー

    364questions

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

  • 暗号化

    60questions

    ネットワークを通じてデジタルデータをやり取りする際に、第三者に解読されることのないよう、アルゴリズムを用いてデータを変換すること。

  • Authentication

    45questions

    Authentication(認証)は正当性を認証する為の工程です。ログイン処理等で使われます。

  • ハッシュ

    26questions

    ハッシュは、高速にデータ検索を行うアルゴリズムのことです。

多くのサービスがログイン時に生のパスワードをそのまま送っているが、「サーバー管理者」にパスワードを悪用されることはないのか

解決済

回答 6

投稿 2017/12/06 23:16 ・編集 2017/12/13 12:54

  • 評価
  • クリップ 4
  • VIEW 2,080

ishowta

score 1

多くの登録制のウェブサイト(Twitterとfacebookで確認しました)は、ログイン時のパスワードをformのパラメーターに直接載せています。
しかし、パスワードが直接渡ると、サーバー側で分かりづらかったため追記3:"クラッカー"ではなく"サーバー管理者"に)パスワードが抜き取られる可能性が出てくるので、ユーザーにとっては不安であると思います。
そこで、パスワードをブラウザ側でハッシュ化してから送るような仕組みにすればこの心配は無くなると思うのですが、そのようなことは行われていません。これはどのような理由によるものなのでしょうか。

ハッシュ化することの問題点として、
パスワードが推測されやすい文字列になっていないか確認できない。
というのが考えられますが、
レインボーテーブルなどを使えば最低限のチェックはできるのではないかと考えました。

追記1 質問の重複について:
SSLを利用したWebサービスでログインパスワードを安全に保存するには?(https://teratail.com/questions/49293)
既に同じような質問がありました。重複した質問をしてしまいました。すみません。(何故か議論が途中で途切れているようにみえますが)
追記2 タイトルの修正:
すでに解決した質問ですが、質問内容が伝わりづらかったため、タイトルに対して修正を行いました。
旧題:多くのサービスがログイン時に生のパスワードをそのまま送っているのはなぜか
改題:多くのサービスがログイン時に生のパスワードをそのまま送っているが、「サーバー管理者」にパスワードを悪用されることはないのか
追記4 感想:
ユーザーがサービス毎にパスワードを変えないことに問題があるという回答をいただき、解決済みとしました。
恥ずかしながら、私はサーバー管理者による悪用の対策としてパスワードを使いまわすことの問題点を知りませんでした。
要するにパスワードを使い回すな、ということで、質問文が分かりづらかったので、難しい質問だと捉えられてしまった方はすみませんでした。

しかし、パスワードを使いまわしているユーザーが8割以上いる現状を考えると、
パスワードを使いまわさないように周知すると同時に、
生のパスワードを送らせないためのなんらかの対策があったらいいなと思いました。

サービス側がクライアントサイドでハッシュ化していることを証明するのは無理でしょうが、クライアント側で解決できる問題なので、
例えばブラウザに、
デフォルトで1Passwordなどのツールをユーザーに使わせるようにしたり、
パスワードの入力画面を検出して、パスワードとドメイン名を結合したものをハッシュ化して置き換える、
(これならクライアント内で完結できますし、複数のコンピュータでも問題なく使えるはず)
などのような対策があったらいいのかなと思いました。
  • 気になる質問をクリップする

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

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

    クリップを取り消します

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

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

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

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

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

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

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

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

    質問の評価を下げる

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

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

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

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

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

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

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

    詳細な説明はこちら

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

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

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

回答 6

+12

解決されたようですので、簡単に補足します。

そこで、パスワードをブラウザ側でハッシュ化してから送るような仕組みにすればこの心配は無くなると思うのですが、そのようなことは行われていません。これはどのような理由によるものなのでしょうか。

確かに広く使われてはいませんが、HTTP認証の一種「ダイジェスト認証」としてブラウザ等に実装されています。詳しくは、以下をご覧ください。

Digest認証 - Wikipedia

では、なぜダイジェスト認証がそれほど普及していないかというと、安全性が中途半端だからではないかと推測します。
ダイジェスト認証が安全でない理由を説明します。Wikipediaからダイジェスト認証のダイジェストの求め方を引用しますが…

クライアントが計算するresponseは以下のようにして求められる:

A1 = ユーザ名 ":" realm ":" パスワード
A2 = HTTPのメソッド ":" コンテンツのURI
response = MD5( MD5(A1) ":" nonce ":" nc ":" cnonce ":" qop ":" MD5(A2) )

サーバ側では、MD5(A1) をあらかじめ計算し格納してある。nonce,nc,cnonce,qopとHTTPのメソッド(GETなど)とコンテンツのURIはクライアントから送られてくるので、サーバ側でもresponseの正解を計算できる。

サーバーにはMD5(A1)の計算結果が保存してあるわけですが、これが攻撃者に漏洩すると、攻撃者はダイジェスト認証のハッシュ値(response)が計算できるので、認証を突破できてしまいます。

しかるに、パスワードが漏れやすい経路はどこかですが、(1)通信路、(2)パスワード情報が格納されたDB等、ですから、(2)からパスワードのハッシュ値が漏れるのは、現実に起こりやすいわけです。つまり、ダイジェスト認証は、通信路からの漏洩に対策するものであって、これはTLSを使えば十分安全にできます。
これに対して、大手サイトも用いる一般的な方式ですと、

(1)通信路 : TLSにより暗号化する
(2)パスワードDB : ソルト+ストレッチングを用いたハッシュ

により、いくらでも強固にできるのです。
ということで、独自のハッシュを送信する方法は思わぬ穴が生じやすく、一般的な方法を越えるのは中々難しいのではないかと思います。

投稿 2017/12/07 07:06

編集 2017/12/07 08:54

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2017/12/07 23:12

    Digest認証のことを書こうかと思ったのですが、ウェブからユーザー登録をするシステムの場合、初回の登録時は生のパスワードを送らないといけませんよね。

    キャンセル

+2

回答者の回答が、質問者の質問意図とズレてませんか?

「サーバー管理者」にパスワードを悪用されることはないのか

結論としては、ありえます。
多くの人はパスワードを使いまわしています。
ログインIDがメールアドレスの場合、生のパスワードが保存されていると、容易にそのメールアドレスにログインできます。
もちろん他人のアカウントにログインすることは現在では犯罪です。(過去、罰する法律がない時代がありました)

投稿 2017/12/12 10:27

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2017/12/12 10:35

    意識高い系のエンジニアは、「パスワードはハッシュ化するだろう」と言いますが、世の中には意識低い系のエンジニアが多いのです。
    中小企業の開発したサービスや、外国人の開発したサービスは、パスワードをハッシュ化せずRawで保存されていました。(私が実際に見た話です)

    私はパスワードを毎回変えているので、よく忘れてしまうのですが、「パスワードを忘れた方は」のリンクをクリックすると、メールでRawパスワードが送られてくるサービスは多いですよね。

    キャンセル

  • 2017/12/12 10:41

    「パスワードをメモに書いて置いてあったのを見られる」「ソーシャルエンジニアリングで聞き出される」など、「人間が入力するパスワード」には、技術外の脆弱性も多々存在します。

    パスワード漏洩に対して「不安に思う」のであれば「サービスごとに別々なパスワードを設定する」自衛策は存在する、ということです。

    キャンセル

  • 2017/12/12 11:00

    maisumakunさん

    > パスワード漏洩に対して「不安に思う」のであれば「サービスごとに別々なパスワードを設定する」自衛策は存在する、ということです。

    その回答は質問に対して、頓珍漢だと思います。

    キャンセル

  • 2017/12/12 11:03

    質問:多くのサービスがログイン時に生のパスワードをそのまま送っているが、「サーバー管理者」がパスワードを盗んで他のサービスに使ってしまうことはないのか

    という質問なので、まず最初に「あり得る」と回答するべきではないでしょうか?
    補足として、「サービスごとに別々なパスワードを設定する」だと思います。

    キャンセル

  • 2017/12/12 11:05

    > 意識高い系のエンジニアは、「パスワードはハッシュ化するだろう」と言いますが、世の中には意識低い系のエンジニアが多いのです。

    今時は流石に少ないんじゃないですかね?
    意識低い系のエンジニアは WordPress でサイトを構築しますし、そもそもサービスとして成立するレベルのものは、フレームワークやライブラリを使用するケースがほとんどかと。

    実際にみたのは最近でしょうか?

    キャンセル

  • 2017/12/12 11:06

    私の回答もちょっとずれていると思いますが、その理由は、質問が何度も編集された結果です。質問の編集履歴をご覧いただければと。

    キャンセル

  • 2017/12/12 11:10

    te2jiさん

    コメントありがとうございます。

    意識低い系を侮ってはなりません。今でも普通に存在します。
    最近だと2年前に引き継いだサービスがrawパスワードを保存していました。
    エンジニアは韓国人で、韓国人としては普通のスキルだと思います。
    これは肌感覚ですが、日本人のエンジニアスキルは、世界的にみて意識高い系だと思います。

    また、rawパスワードで保存している多くのサービスが現在もそのまま修正されずに稼働しています。

    キャンセル

  • 2017/12/12 11:13

    まだ結構残っている可能性があるんですね^^;
    面白い情報、ありがとうございます。

    キャンセル

  • 2017/12/12 11:19

    ockeghemさん
    コメントありがとうございます。今、確認したところ、最初の質問から随分と編集されていますね。なるほど。納得しました。

    キャンセル

  • 2017/12/12 12:02 編集

    改題について明記しました。

    キャンセル

  • 2017/12/12 12:16

    ishowta > 👍🏻

    キャンセル

  • 2017/12/12 21:03

    通信やDBだけ守ったところで,それを保存している建物に入られたら元も子もない^^

    客が契約金を出し渋った癖して,期限は動かせないため,無断入退室して開発を行いました.
    日本でも節約意識の高い系がいるのだから,その客が提供するサービスを使う側では対策しようがない.

    近々改元対応案件が出てきそうなので,私と同じ経験を積めるチャンスがあるでしょうね.
    金は固定で,期限も固定.しかし,開発規模は膨大にふくれあがる.
    よくあることですね^^

    キャンセル

+1

パスワードAについてハッシュしたA'をクライアント側で送信したとします。
クラッカーは、元のパスワードは知らずとも、ハッシュ化されたA'でサーバーへログインするリクエストを投げれば、簡単にログインできてしまいます。
ユーザーが、自分で決めた何かのパスフレーズをハッシュして、それをパスワードとして採用しただけのことと同じです。

>レインボーテーブルなどを使えば
これは、ハッシュ化しても復号できてしまう、という「ブーメラン」を示してしまっていますよ。。

パスワード方式は、記憶に頼るもので面倒であるし完全なものでありませんが、カジュアルなハッキングを防ぐ意味では役立っています。家の錠前・鍵も、1000円かからずに簡単にコピーできるものであれ基本的な侵入はだいぶ防げますからね。
強固さを求めるなら、IDとパスワードを入力したらメールやSMSで認証URL等を送る(5分間有効)、など多要素にして、さらに不正なリクエストを検出して遮断するほうが有効かと。この方式は、いくつかのIT系大手サイトで採用されていますね。

投稿 2017/12/12 11:10

編集 2017/12/12 11:19

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

checkベストアンサー

0

サーバー側でパスワードが抜き取られる可能性が出てくるので、ユーザーにとっては不安であると思います。

理想論を言えば、パスワードはサービスごとにばらばらにすべきなので、不安ならぜんぜん違うパスワードを設定すれば、漏洩してもそのサイト以外に影響することはありません。そして、現実問題として、そこまで不安がるユーザーはそもそもサービスに登録しない、という選択肢を取るのではないかと思います。

その問題を除いてセキュリティ的に考えてみれば、クライアントのJavaScriptは公開される以上、「パスワードを直接サーバに送る」より強固なセキュリティを確保することは困難です。

投稿 2017/12/06 23:31

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2017/12/07 07:21 編集

    「クライアントのJavaScriptは公開される以上、「パスワードを直接サーバに送る」より強固なセキュリティを確保することは困難」という説明には違和感があります。私たちは公開されているアルゴリズムでも実用的に使える方式を使っていますよね。

    キャンセル

0

以前、同じような質問をしました。
参考になれば^^

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

まず理解しなくてはいけないのは、Zuishin さんの回答にある

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

です。

ここを押さえたうえで、その先を検討する必要があります。

私はいろいろ考えましたが、「それってようするにHTTPSだよね」って結論で納得しました。

投稿 2017/12/07 01:48

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2017/12/07 03:01

    HTTPS(SSL)はハッシュ化ではなくて暗号化してサーバー側で復号するだけなので目的が全く違いませんか?

    情報ありがとうございます!

    質問が重複してしまいました…同じような質問が無いか探したはずだったのですが、探し方が悪かったようです。リンクを質問に追記しておきます。

    実は内輪で使っていたサイトでこの問題に直面して、クライアントとサーバーで2重にハッシュ化をしていたのですが、先ほど大手のサイトでクライアント側でのハッシュ化がされていないことを知り、このような質問に至りました。

    結局、パスワードを分けていないユーザーが80%近くもいる以上、リンク先にあったように、サイト側も実装をしてセキュリティを2重にするのが良いと考えられますが、社会的な問題にならない限り実装する側としては簡易な実装を選ぶということなのでしょうか。(また、最近はGoogleやTwitterを介してのログイン実装が増えているので、これも向かい風になっているのかもしれません。)

    キャンセル

  • 2017/12/07 09:00 編集

    > HTTPS(SSL)はハッシュ化ではなくて暗号化してサーバー側で復号するだけなので目的が全く違いませんか?

    たしかに、質問の趣旨からすると目的が違ってきてしまいますね^^;

    ただ、ハッシュ化したパスワードが解読不可能であるかと言われると「否」であるので、私の質問の流れでは、ユーザがサービス提供者を信用しないのであれば、それほど違いは無いかと判断しました。

    SNS 認証が増えているのも、そのあたりに対してのエクスキューズだと思います。まぁ、これも「信用ならん/気持ち悪い」って人が多そうなので、悩ましいところですがw

    キャンセル

  • 2017/12/07 11:51

    ハッシュ化前の文字列が推測できないことが(このような目的で用いるときの)ハッシュである条件であり存在意義であると思うのですが、ハッシュ化したパスワードが解読可能であるというのはどういうことでしょうか?

    キャンセル

  • 2017/12/07 12:23

    復元は出来ないですが、解読(解析)は可能です。

    ハッシュ値は、ご存知のように元の文字列を同じ手順でハッシュ化することで、再現することが可能です。つまり、パスワードの文字数が有限である以上、時間はかかりますが、同じ手順を踏めば再現されます。特にサービス提供側には再現するための情報があるので、通常より時間をかけずに再現することが可能です。

    キャンセル

  • 2017/12/07 12:35

    可能というのは現実的な時間内で可能ということですよね?
    通常より時間をかけずに=現実的な時間内に ということでしょうか? アルゴリズムについて詳しくはないのですが、ソルトやストレッチを十分にかければ、情報がある状態でも現実的な時間内で解読するのが不可能になる程度にできるのではないでしょうか

    キャンセル

  • 2017/12/07 13:09

    サービス提供者は、使用したハッシュ関数、適用回数、salt に関して情報を持っているので、試行回数は最低限で済みます。
    特定ユーザの解読であれば、十分現実的な時間で収まります。

    キャンセル

0

私は、サーバ側には生パスワードを送信すべきでないと思います。
「クライアントのJavaScriptは公開される以上、「パスワードを直接サーバに送る」より強固なセキュリティを確保することは困難」であったとしても、クライアント側でハッシュ化するのは意味があると思っています。それは、サーバ側に立った場合、生パスワードを知らないという事実が重要になるケースがあると思うからです。
パスワードが漏れるのはDBであるとは限りません。サーバの至る所で漏洩元になる可能性があるのです。生のPWを送ってしまうと、サーバ側でハッシュする前の段階で、例えばアクセスログなどにPWを出力してしまうなどやらかしてしまうかもしれません。クラッカーはログファイルを入手すればいいわけです。
たしかに、クライアントでハッシュ化しても、結局のところそれはPWと同等であって、セキュリティを確保するのには不十分なわけですが、ハッシュから元のパスワードが推測困難であれば、サーバからの漏洩が疑われたとしても少なくとも生PWを知らないわけですから漏洩元でないことを主張できるわけです。
それと、WebサービスごとにPWを変えるべきというのは理想論ですが、現実はそうしている人は少ないということも認識すべきかと。

投稿 2017/12/12 10:10

編集 2017/12/12 10:13

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2017/12/12 10:31

    サーバサイドに侵入されるのであればWebページを改竄してパスワードを別なところに送信させるような攻撃を仕組むこともできるでしょうし、(クライアントサイドで処理することによって失われる柔軟性の代償として)防げるようになる攻撃の幅はそこまで広がらないと思います。

    あと、ガチガチにJavaScriptで組まれたようなサービスならともかく、ログインでJavaScriptを使うとなると、使えない環境の人はログイン不能となります。

    キャンセル

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

ただいまの回答率

91.34%

関連した質問

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

  • Webサイト

    790questions

    一つのドメイン上に存在するWebページの集合体をWebサイトと呼びます。

  • セキュリティー

    364questions

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

  • 暗号化

    60questions

    ネットワークを通じてデジタルデータをやり取りする際に、第三者に解読されることのないよう、アルゴリズムを用いてデータを変換すること。

  • Authentication

    45questions

    Authentication(認証)は正当性を認証する為の工程です。ログイン処理等で使われます。

  • ハッシュ

    26questions

    ハッシュは、高速にデータ検索を行うアルゴリズムのことです。

  • トップ
  • Authenticationに関する質問
  • 多くのサービスがログイン時に生のパスワードをそのまま送っているが、「サーバー管理者」にパスワードを悪用されることはないのか