Hatena::ブログ(Diary)

sshi.Continual このページをアンテナに追加 RSSフィード

プロフィール

sshi

SFと映画と小説とRuby信者(最近はhaskellびいき)です。

 | 

2006-03-29 Wed

[] 「はてなパスワードを生データで管理してる?」のはそんなに駄目なのか?  「はてなはパスワードを生データで管理してる?」のはそんなに駄目なのか?を含むブックマーク

http://d.hatena.ne.jp/ryoko_komachi/20060324/1143502995

はてなDBにはパスワードハッシュ値じゃなくて生のままはいってる!セキュリティ的に大丈夫なのか?っていうお話。何人か非難の声をあげている。

…ええっと、安全じゃない通信路(インターネット)に生のパスワードを流さずに済むダイジェスト系の認証を使おうとしたら、サーバ側には生パスワードがなきゃ無理だよね?認証する通信路の安全性の話に全く触れずに、パスワードの保存の仕組みだけを取りあげるのは何かおかしな話な気がする。勘違いがあったらご指摘ください。

パスワードが流れても大丈夫なように認証を全てSSLで安全な通信路にすれば、ハッシュ値の保存だけで済んで安全っていう議論はありうるけど、そもそもそこまでする必要はあるんだろうか?パスワードDB突破された後に守るべき物が残っているのだろうか。大きな金庫の中に現金とその金庫を開く鍵がはいっているとして、鍵をそのまま入れとくのは危険だからって鍵だけを小さい金庫に入れようとする?大きな金庫が開かれちゃえば現金は持っていかれるのに?

Webベースシステムで(DBから)直接パスワードが盗まれるなんていう事態はかなり最悪の状況で、そんな状況であればサーバ上のデータなんてどういじられても不思議はないと思うんだけどな。パスワードが盗まれることで引き起こされる被害って、はてなサーバにあるデータ以外にあるのかな。ポイント盗難とかも言われてるけど、ポイントデータもサーバで管理してるんだろうからデータ書きかえられちゃえば終わり。非難してる人は何を騒いでいるんだろう。もしかして、他の重要システムと共用してるからパスワードそのものを知られたくなかったってこと?

もし、そうだとすれば、相手が信用できるか信用できないかは別にして、認証相手には何らかの形で絶対パスワードは渡るわけだし、そもそも、ネットに流せばそれだけ漏れる可能性が高まるんだから、重要パスワードはこんなWebシステムと共用しちゃいけない、という話で終わりでしょう。

というか、パスワードの安全性を問題にするなら、パスワードが生で流れるhttpのログイン認証がまだ使えてしまうことを問題にすべきな気がするのですが…

3/30 補足

ちゃんと書いてなかったですが、上での「生のパスワード」ってのは必ずしもDBパスワード文字列そのものが保存されていることを意味しません。「はてな内部でパスワード文字列そのものを取得できる状態」と解釈してください。パスワードは(はてな側が復号可能な)暗号化をされてDBに納められている可能性はあって、リンク先で挙げられている事実からその可能性は否定できません。というか、はてな内部の人しか本当のところはわからないでしょう。

「そもそもダイジェスト系の認証が使われているから生だ!」という主張がなされていたので、それに合わせて書いたのですが、「ダイジェスト系の認証が使われている」からは「はてな内でパスワード文字列そのものが取得できる」しか言えず、DBに文字列そのものが格納されているかどうかはわかりません。って、これだけ指摘すればよかったのかな。まだよくわからん。

もっとも、それもはてなの認証コードにアクセスできる悪意ある人には何の防御にもならないわけですが。

さらに補足

kosekiさん(http://d.hatena.ne.jp/koseki/20060330)からトラックバックを貰ってようやく気がついたのだけれど、「パスワードハッシュ値」をパスワードとみなすダイジェスト系の認証をAtom APIとかの軽めの認証に、SSL+Basic認証ポイントのやりとりとか登録個人情報へのアクセスとかの重要な認証に、というふうに使いわければ、サーバ側に置いておくのはパスワードハッシュ値だけで良くなるのか。

もちろん、ダイジェスト系の認証のほうでは、サーバ側に置いてあるパスワードハッシュ値が「生パスワード」と同じことになるので、これが漏れるとダイジェスト系の認証のほうには簡単にアクセスされてしまう。でも、ハッシュ値だけではBasci認証のほうにはアクセスできない。双方の認証を重要度で適切に使いわけられれば、SSLの負荷を抑えつつサーバ側にはハッシュ値しか置かない、という運用ができる。

…ということでいいのかな。ハッシュを二重がけすることの悪影響とかないのかな。ないか。

これが上手くいくなら運用コストもそんなに変わらなさそうだし切り替えてもよいかなあ、という気はしますね。でも、今のはてなに置いてあるデータの質を考えると、切り替えコストとの兼ね合いで現状で十分という判断もありな気がする。

to2yto2y 2006/03/29 22:03 お楽しみは勉強会に取っておけばいいんじゃない
それはそうとして、勉強会の環境手配はどうする?

sshisshi 2006/03/29 23:24 勉強会は本の内容と進め方によるよねえ。練習問題解くのか(あるのか)、担当決めてレジュメ作るか、範囲決めてわかんないとこ質問をぶつけあうだけでいいのか、リアルタイムで話すのか、メールやコメントだけでいいのか、とかとか。
でもどうするにしても、どこかのWikiを確保して、参加者はSkype利用、くらいでだいたい十分なんじゃない?はてなに乗っかるのをヨシとするなら、はてなグループが便利かも。自宅サーバでどうこうとか、そういうことする気はゼロ。
どれも確保しようと思えばすぐとれるから、実際に動くのは本ぱらぱらっと見て進め方決めてからでいいんじゃなかろか。

あ。オンラインホワイトボードの心あたりだけないけど、使うかな?

to2yto2y 2006/03/30 00:34 本の内容によるのはその通りやな。
こっちも環境は公共(?)のありものを使うことしか考えてないです。
ホワイトボードは探してみるか。

hideblohideblo 2006/03/30 13:54 初めまして。
おっしゃられていることは正しいと思うし、問題とされているような針の穴をつつくような揚げ足とりはキライなんで、
いいんじゃない?って思うんですが、
開発者が開発のためにDB見ることありますよね。
そのときにパスワードが素で見えてしまうのはどうなの?
という話もありますよね。
つい最近、ATMの監視してるところがPASSをぶっこぬいたという事件が起きたばかりだし。
それなら、パスワードが入っているTableをユーザ権限で制限してしまえええやん、という方法もありますけど、結局許されている人には見えてしまうんで、まあ、素じゃないほうがいいですよね。変換かけてもデータぶっこぬいて、decodeしてしまえば同じなんですけど。

sshisshi 2006/03/30 22:40 はじめまして。少し補足しましたが、今回の件からは、はてなDBにパスワードそのものの文字列が格納されているかどうかはわかりません。おっしゃるとおり、復号可能な暗号化がなされている可能性はあります。
まー、文字列そのままで保存されてたとしても、悪意ない人がざっと見ただけで覚えられてしまうようなパスワードはそれ自体が弱すぎる、という気はしますが。

hideblohideblo 2006/03/31 13:23 >悪意ない人がざっと見ただけで覚えられてしまうようなパスワードはそれ自体が弱すぎる
それは正解ですね(^^;
そういう話までいくと個人の責任をはてなの責任に摩り替えてるという話にもなりますね。まあ、大半は騒ぎたいだけだと思うんで、そんな話とはさらに無縁だと思いますが(笑)

jesterserajestersera 2007/02/25 21:44 以前登録情報を間違えて登録していて、設定画面から変更できない情報をサポートにメールして修正してもらったことがあります。
その時に本人確認のための情報としてパスワードの先頭3文字を答える必要がありました。
全てではないといえメールという安全ではない方法でそういった情報を流す必要があることと、サポート担当者がパスワードを閲覧可能な状態であることに非常に抵抗を感じました。

sshisshi 2007/02/26 09:44 >jesterseraさん
その運用は気持ち悪いですね…。今でもそうなんでしょうか。
はてな側としては、その程度の扱いで(全部じゃなけりゃメールでも)いいという判断なんでしょうね。上にも書きましたが、httpでの認証はまだ生きてるので、そっちを使うと盗聴され放題でもあるわけですし。

 | 

あわせて読みたい
sshi.Continual 934826 なかのひと RSS feed meter for http://d.hatena.ne.jp/sshi/