Q&A
まさにです。なぜ、みんなhskさんが言ってる観点について触れないんでしょう。
多くの登録制のウェブサイト(Twitterとfacebookで確認しました）は、ログイン時のパスワードをformのパラメーターに直接載せています。
しかし、パスワードが直接渡ると、サーバー側で**（分かりづらかったため追記３："クラッカー"ではなく"サーバー管理者"に）**パスワードが抜き取られる可能性が出てくるので、ユーザーにとっては不安であると思います。
そこで、パスワードをブラウザ側でハッシュ化してから送るような仕組みにすればこの心配は無くなると思うのですが、そのようなことは行われていません。これはどのような理由によるものなのでしょうか。
ハッシュ化することの問題点として、
パスワードが推測されやすい文字列になっていないか確認できない。
というのが考えられますが、
レインボーテーブルなどを使えば最低限のチェックはできるのではないかと考えました。
追記１ 質問の重複について： SSLを利用したWebサービスでログインパスワードを安全に保存するには？(https://teratail.com/questions/49293) 既に同じような質問がありました。重複した質問をしてしまいました。すみません。（何故か議論が途中で途切れているようにみえますが）
追記２ タイトルの修正： すでに解決した質問ですが、質問内容が伝わりづらかったため、タイトルに対して修正を行いました。 旧題：多くのサービスがログイン時に生のパスワードをそのまま送っているのはなぜか 改題：多くのサービスがログイン時に生のパスワードをそのまま送っているが、「サーバー管理者」にパスワードを悪用されることはないのか
追記４ 感想： ユーザーがサービス毎にパスワードを変えないことに問題があるという回答をいただき、解決済みとしました。 恥ずかしながら、私はサーバー管理者による悪用の対策としてパスワードを使いまわすことの問題点を知りませんでした。 要するにパスワードを使い回すな、ということで、質問文が分かりづらかったので、難しい質問だと捉えられてしまった方はすみませんでした。 しかし、パスワードを使いまわしているユーザーが８割以上いる現状を考えると、 パスワードを使いまわさないように周知すると同時に、 生のパスワードを送らせないためのなんらかの対策があったらいいなと思いました。 サービス側がクライアントサイドでハッシュ化していることを証明するのは無理でしょうが、クライアント側で解決できる問題なので、 例えばブラウザに、 デフォルトで1Passwordなどのツールをユーザーに使わせるようにしたり、 パスワードの入力画面を検出して、パスワードとドメイン名を結合したものをハッシュ化して置き換える、 （これならクライアント内で完結できますし、複数のコンピュータでも問題なく使えるはず） などのような対策があったらいいのかなと思いました。
回答7件
0
解決されたようですので、簡単に補足します。
そこで、パスワードをブラウザ側でハッシュ化してから送るような仕組みにすればこの心配は無くなると思うのですが、そのようなことは行われていません。これはどのような理由によるものなのでしょうか。
確かに広く使われてはいませんが、HTTP認証の一種「ダイジェスト認証」としてブラウザ等に実装されています。詳しくは、以下をご覧ください。
では、なぜダイジェスト認証がそれほど普及していないかというと、安全性が中途半端だからではないかと推測します。
ダイジェスト認証が安全でない理由を説明します。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/06 22:06
編集2017/12/06 23:54
総合スコア11705
0
パスワードAについてハッシュしたA'をクライアント側で送信したとします。
クラッカーは、元のパスワードは知らずとも、ハッシュ化されたA'でサーバーへログインするリクエストを投げれば、簡単にログインできてしまいます。
ユーザーが、自分で決めた何かのパスフレーズをハッシュして、それをパスワードとして採用しただけのことと同じです。
＞レインボーテーブルなどを使えば
これは、ハッシュ化しても復号できてしまう、という「ブーメラン」を示してしまっていますよ。。
パスワード方式は、記憶に頼るもので面倒であるし完全なものでありませんが、カジュアルなハッキングを防ぐ意味では役立っています。家の錠前・鍵も、１０００円かからずに簡単にコピーできるものであれ基本的な侵入はだいぶ防げますからね。
強固さを求めるなら、IDとパスワードを入力したらメールやSMSで認証URL等を送る（5分間有効）、など多要素にして、さらに不正なリクエストを検出して遮断するほうが有効かと。この方式は、いくつかのIT系大手サイトで採用されていますね。
投稿2017/12/12 02:10
編集2017/12/12 02:19
総合スコア728
0
回答者の回答が、質問者の質問意図とズレてませんか？
「サーバー管理者」にパスワードを悪用されることはないのか
結論としては、ありえます。
多くの人はパスワードを使いまわしています。
ログインIDがメールアドレスの場合、生のパスワードが保存されていると、容易にそのメールアドレスにログインできます。
もちろん他人のアカウントにログインすることは現在では犯罪です。（過去、罰する法律がない時代がありました）
追記：
ちなみにですが、もう10年以上も前の話ですが、とある会社のエンジニアは、ログインIDとして使われていたメールアドレスとパスワードで、実際にGMailやYahoo！メールにログインして遊んでいました。私はその光景を見ていて、これは将来、犯罪に使われるなと思っていました。
投稿2017/12/12 01:27
編集2018/12/04 02:14
総合スコア108
意識高い系のエンジニアは、「パスワードはハッシュ化するだろう」と言いますが、世の中には意識低い系のエンジニアが多いのです。
中小企業の開発したサービスや、外国人の開発したサービスは、パスワードをハッシュ化せずRawで保存されていました。（私が実際に見た話です）
私はパスワードを毎回変えているので、よく忘れてしまうのですが、「パスワードを忘れた方は」のリンクをクリックすると、メールでRawパスワードが送られてくるサービスは多いですよね。
「パスワードをメモに書いて置いてあったのを見られる」「ソーシャルエンジニアリングで聞き出される」など、「人間が入力するパスワード」には、技術外の脆弱性も多々存在します。
パスワード漏洩に対して「不安に思う」のであれば「サービスごとに別々なパスワードを設定する」自衛策は存在する、ということです。
maisumakunさん
> パスワード漏洩に対して「不安に思う」のであれば「サービスごとに別々なパスワードを設定する」自衛策は存在する、ということです。
その回答は質問に対して、頓珍漢だと思います。
質問：多くのサービスがログイン時に生のパスワードをそのまま送っているが、「サーバー管理者」がパスワードを盗んで他のサービスに使ってしまうことはないのか
という質問なので、まず最初に「あり得る」と回答するべきではないでしょうか？
補足として、「サービスごとに別々なパスワードを設定する」だと思います。
> 意識高い系のエンジニアは、「パスワードはハッシュ化するだろう」と言いますが、世の中には意識低い系のエンジニアが多いのです。
今時は流石に少ないんじゃないですかね？
意識低い系のエンジニアは WordPress でサイトを構築しますし、そもそもサービスとして成立するレベルのものは、フレームワークやライブラリを使用するケースがほとんどかと。
実際にみたのは最近でしょうか？
私の回答もちょっとずれていると思いますが、その理由は、質問が何度も編集された結果です。質問の編集履歴をご覧いただければと。
te2jiさん
コメントありがとうございます。
意識低い系を侮ってはなりません。今でも普通に存在します。
最近だと2年前に引き継いだサービスがrawパスワードを保存していました。
エンジニアは韓国人で、韓国人としては普通のスキルだと思います。
これは肌感覚ですが、日本人のエンジニアスキルは、世界的にみて意識高い系だと思います。
また、rawパスワードで保存している多くのサービスが現在もそのまま修正されずに稼働しています。
まだ結構残っている可能性があるんですね＾＾；
面白い情報、ありがとうございます。
ockeghemさん
コメントありがとうございます。今、確認したところ、最初の質問から随分と編集されていますね。なるほど。納得しました。
改題について明記しました。
ishowta > ????????
通信やDBだけ守ったところで,それを保存している建物に入られたら元も子もない^^
客が契約金を出し渋った癖して,期限は動かせないため,無断入退室して開発を行いました.
日本でも節約意識の高い系がいるのだから,その客が提供するサービスを使う側では対策しようがない.
近々改元対応案件が出てきそうなので,私と同じ経験を積めるチャンスがあるでしょうね.
金は固定で,期限も固定.しかし,開発規模は膨大にふくれあがる.
よくあることですね^^
te2jiさん
意識低い系サイトを見つけました。ソフトバンクモバイルという会社をご存知でしょうか？
日本の携帯電話の会社で、かなり悪どい商法を行っている会社です。
その会社のサービスで、My Softbankというサイトがあり、【パスワードを忘れた方】のリンクをクリックして、パスワードの確認を行うと、Rawパスワードが表示されます。
面白いですね。
さすがにあそこは生パスワードをそのまま保管ってことはないと思いますが（思いたいですがｗ）何らかの独自実装をしているってことは確かですね。
情報、ありがとうございました！
te2jiさん
> 生パスワードをそのまま保管ってことはないと思いますが
いえ、生パスワードをそのまま保管しているということです。
可逆符号化している可能性もありますが、Rawパスワード表示するようなセキュリティマインドの会社が、わざわざ面倒なことをするとは思えません。
> 何らかの独自実装をしているってことは確かですね。
いえ、それほどの技術力のある会社ではございません。
大手上場企業で働いたことはありますか？NTT DOCOMOという会社をご存知でしょうか？私はこちらで働いていたのですが、エンジニアのスキルはひどいものでした。案外、ベンチャー系の企業にこそ意識高い系のエンジニアが居るものです。
https://togetter.com/li/1313652
上記はRAWパスワードを保存しており、流出した事案です。
東証・大証・名証に1部上場している大阪ガスという企業の子会社だそうですが、大手上場企業に意識高い系のエンジニアが多いという妄想は排除しておいた方が良いでしょう。
昭和を引き摺る上場企業というのは、エンジニアを事務員だと考えているので、そのような企業には意識高い系のエンジニアというのはおりません。
昭和から上場している企業のWebサイトは、ほぼ全てRAWパスワードで保存されていると考えて間違いありません。
これ、なんでハッシュ値の保存に変更しなかったのか、気になりますね。
問い合わせへの対応コストだったのかなぁ。。。
te2jiさん
いえいえ、そんな計算高いコスト意識ではないと思います。
（企業が負うトータルのコストで考えれば、対応するべきでしたが…）
まさに『 意識低い系 』なんですよ。
te2jiさんは、心が優しいか、意識の高いエンジニアの職場しか見ていないんだと思います。
現実は、意識の低いエンジニアが跋扈しており、技術力も足りないので改修することもできないのです。
この手の会社が、技術力の高いエンジニアを雇おうにも、この手の昭和の企業がエンジニアに払う年収は400万円程度（終身雇用・年功序列）なので、意識も技術力も高いエンジニアは雇えないのです。
0
みなさんなぜか、hskさんが言ってる観点について触れてませんが、ブラウザ側でハッシュ化してという仕組みになったとしても、それはサービスとしてハッシュ化後の状態でリクエストを可能にしているということなので、攻撃者にとってはどちらでも同じ。
一応回答を・・・
多くのサービスがログイン時に生のパスワードをそのまま送っているが、「サーバー管理者」にパスワードを悪用されることはないのか
ある。それが普通であり、そのサービスに渡しても良いと思う個人情報を入力すべきである。
パスワードをブラウザ側でハッシュ化してから送るような仕組みにすればこの心配は無くなると思うのですが、そのようなことは行われていません。これはどのような理由によるものなのでしょうか。
全くやる意味がない。なぜなら、ハッシュ化したら、今度はハッシュ化後の文字列を他人に知られてはいけなくなるだけです。
ハッシュ化後の文字列で通信すれば処理が通ってしまうからです。
（追記１のリンク先での回答と同義）
今回のケースを「サービス毎にパスワードを変更する」という答えで締めくくるのは、いささか正確な理解ではないように思います。
サービスに対して、ユーザーが自ら送信する情報について
これは、サービスの人に見せる情報だと思うべきだと思います。もちろんSSLなどを使って、第三者に対して情報が漏洩しないようにはしますが、
基本的に、入力するということは、情報を見せるという行為です。
こと「ログイン」という処理のみに限って言えば、見せない方法があるとすれば、「facebookでログインする」などのソーシャルログインですね。
もちろんこの場合でも、最初にfacebook側には通常通りログインする必要がありますが、新しく利用するサービス側にログイン情報を与える必要はなくなります。
ちなみにサービス管理者が悪だという話で、パスワード問題を議論すると、パスワードどころの話ではないですよ。サービス管理者が悪なら、例えばFacebookなら自由になりすまし投稿できますし、amazonなら自由になりすましてお買い物が可能でしょう。
つまり、サービス側を悪だと仮定すると、なんでも出来ちゃいます。
サービス管理者（開発者）が、パスワードをハッシュ化して保存しているか否かについて
これは、当初の議論とは、ずれた話ですが。
基本的にエンジニアとして、パスワード情報は（ログなどに）出力せず、保管はハッシュ化するのは、至極当たり前の新卒並みの知識ですが、
どの世界にもレベルが低い方がいるように、ITの世界にもいます。
このレベルの話になると、「信用できないようなサービスは利用しない」が正しいかと思います。
サービス毎にパスワードを変更する
サービス毎にパスワードを変更するのは、素晴らしいことですが、
全部のパスワードを違うようにすれば漏れても大丈夫だという議論は、ちょっと乱暴な答えな気がします。
投稿2017/12/15 11:18
編集2017/12/15 11:50総合スコア139
0
私は、サーバ側には生パスワードを送信すべきでないと思います。
「クライアントのJavaScriptは公開される以上、「パスワードを直接サーバに送る」より強固なセキュリティを確保することは困難」であったとしても、クライアント側でハッシュ化するのは意味があると思っています。それは、サーバ側に立った場合、生パスワードを知らないという事実が重要になるケースがあると思うからです。
パスワードが漏れるのはDBであるとは限りません。サーバの至る所で漏洩元になる可能性があるのです。生のPWを送ってしまうと、サーバ側でハッシュする前の段階で、例えばアクセスログなどにPWを出力してしまうなどやらかしてしまうかもしれません。クラッカーはログファイルを入手すればいいわけです。
たしかに、クライアントでハッシュ化しても、結局のところそれはPWと同等であって、セキュリティを確保するのには不十分なわけですが、ハッシュから元のパスワードが推測困難であれば、サーバからの漏洩が疑われたとしても少なくとも生PWを知らないわけですから漏洩元でないことを主張できるわけです。
それと、WebサービスごとにPWを変えるべきというのは理想論ですが、現実はそうしている人は少ないということも認識すべきかと。
投稿2017/12/12 01:10
編集2017/12/12 01:13
総合スコア46
サーバサイドに侵入されるのであればWebページを改竄してパスワードを別なところに送信させるような攻撃を仕組むこともできるでしょうし、（クライアントサイドで処理することによって失われる柔軟性の代償として）防げるようになる攻撃の幅はそこまで広がらないと思います。
あと、ガチガチにJavaScriptで組まれたようなサービスならともかく、ログインでJavaScriptを使うとなると、使えない環境の人はログイン不能となります。
0
以前、同じような質問をしました。
参考になれば＾＾
まず理解しなくてはいけないのは、Zuishin さんの回答にある
クライアント側でハッシュ化して送信し、それをサーバーで保存、これはつまり生パスワードの保存なのではないですか？
保存したものがそのままパスワードとして通用するということですよね？
です。
ここを押さえたうえで、その先を検討する必要があります。
私はいろいろ考えましたが、「それってようするにHTTPSだよね」って結論で納得しました。
投稿2017/12/06 16:48
退会済みユーザー
総合スコア0
HTTPS(SSL)はハッシュ化ではなくて暗号化してサーバー側で復号するだけなので目的が全く違いませんか？
情報ありがとうございます！
質問が重複してしまいました…同じような質問が無いか探したはずだったのですが、探し方が悪かったようです。リンクを質問に追記しておきます。
実は内輪で使っていたサイトでこの問題に直面して、クライアントとサーバーで２重にハッシュ化をしていたのですが、先ほど大手のサイトでクライアント側でのハッシュ化がされていないことを知り、このような質問に至りました。
結局、パスワードを分けていないユーザーが80%近くもいる以上、リンク先にあったように、サイト側も実装をしてセキュリティを２重にするのが良いと考えられますが、社会的な問題にならない限り実装する側としては簡易な実装を選ぶということなのでしょうか。（また、最近はGoogleやTwitterを介してのログイン実装が増えているので、これも向かい風になっているのかもしれません。）
> HTTPS(SSL)はハッシュ化ではなくて暗号化してサーバー側で復号するだけなので目的が全く違いませんか？
たしかに、質問の趣旨からすると目的が違ってきてしまいますね＾＾；
ただ、ハッシュ化したパスワードが解読不可能であるかと言われると「否」であるので、私の質問の流れでは、ユーザがサービス提供者を信用しないのであれば、それほど違いは無いかと判断しました。
SNS 認証が増えているのも、そのあたりに対してのエクスキューズだと思います。まぁ、これも「信用ならん/気持ち悪い」って人が多そうなので、悩ましいところですがｗ
ハッシュ化前の文字列が推測できないことが（このような目的で用いるときの）ハッシュである条件であり存在意義であると思うのですが、ハッシュ化したパスワードが解読可能であるというのはどういうことでしょうか？
復元は出来ないですが、解読（解析）は可能です。
ハッシュ値は、ご存知のように元の文字列を同じ手順でハッシュ化することで、再現することが可能です。つまり、パスワードの文字数が有限である以上、時間はかかりますが、同じ手順を踏めば再現されます。特にサービス提供側には再現するための情報があるので、通常より時間をかけずに再現することが可能です。
可能というのは現実的な時間内で可能ということですよね？
通常より時間をかけずに＝現実的な時間内に ということでしょうか？ アルゴリズムについて詳しくはないのですが、ソルトやストレッチを十分にかければ、情報がある状態でも現実的な時間内で解読するのが不可能になる程度にできるのではないでしょうか
サービス提供者は、使用したハッシュ関数、適用回数、salt に関して情報を持っているので、試行回数は最低限で済みます。
特定ユーザの解読であれば、十分現実的な時間で収まります。
0
ベストアンサー
サーバー側でパスワードが抜き取られる可能性が出てくるので、ユーザーにとっては不安であると思います。
理想論を言えば、パスワードはサービスごとにばらばらにすべきなので、不安ならぜんぜん違うパスワードを設定すれば、漏洩してもそのサイト以外に影響することはありません。そして、現実問題として、そこまで不安がるユーザーはそもそもサービスに登録しない、という選択肢を取るのではないかと思います。
その問題を除いてセキュリティ的に考えてみれば、クライアントのJavaScriptは公開される以上、「パスワードを直接サーバに送る」より強固なセキュリティを確保することは困難です。
投稿2017/12/06 14:31
総合スコア145932
「クライアントのJavaScriptは公開される以上、「パスワードを直接サーバに送る」より強固なセキュリティを確保することは困難」という説明には違和感があります。私たちは公開されているアルゴリズムでも実用的に使える方式を使っていますよね。
クライアントサイドでハッシュ化するということは、「サーバに送信するパスワードの形式が決まってしまう」ということであり、サーバサイドへの情報漏えいのリスクは下がるかもしれませんが、逆に不正ログインに対しては手がかりとなってしまう、という危険を生みます。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/12/07 14:12