アカウント名:
パスワード:
アメブロの騒動、あとからおいついたので現物見てませんが、状況から見てIDとパスワードが平文で保存されてたってことでしょうな。時折サービス登録するとパスワードが平文で送られてきたり「ハッシュしないで保管してるっぽいなー」ってとこがあるんですが、これはなぜなんでしょう?# アメブロの場合は芸能人ブログだけ特別扱いで管理してたのかもしれませんけど
流石にハッシュ後を保存するって教科書レベルの話を知らない開発者が居るとは思えないので、なんか理由があるんだと思いますが……「パスワードは聞けば教えてくれるはずだ」みたいなユーザが多いから?
何らかの理由で「こんな実装したくないのに……」と苦汁を飲んだ開発者が/.Jに居れば、こっそり教えてください:-)
>相手が芸能事務所だけに目に見えない後始末はそら大変でしょうに。「ブログの画像は削除されたが、エクセルデータには、IDとパスワードのほかに、 サイバーエージェントの社員と推測されるメールアドレスのほか、 芸能プロダクションにブログを書いてもらうための営業用の資料も掲載。 「事務所ごと取りに行こう!」「事務所内もしょぼい」「バーター必須であれば」など、 芸能プロダクションについての生々しい評判も掲載されている。」http://www.cyzo.com/2010/01/post_3556.html [cyzo.com]
後始末はすごく大変になりそうな予感。
記事やデザインの更新を第三業者や社内チームが行うのケースは当然ありうるからその場合は平文パスワードを管理し伝えなきゃいけない。ハッシュ云々言ってるコメントはなんなんだ?
そのようなケースでIDを共用するからパスワードを平文で管理する必要が生じるのであって、本人、業者、社内とユーザごとに別のIDを発行するのがセキュリティ上「当然」の姿なんです。
だから別のIDを発行ならわかるがハッシュ云々言ってるコメントはなんなんだ?ハッシュから平文化できるとでも思ってるんだろうか
自己フォローしとこうアメブロに作っていろいろしてみたけど、サーバに平文でパスワードが保存されてるとかはなさそうな気配。# 実態は判らないけど、いきなり平文で送りつけられてきたりしないし、リセットの手順も良くある形。ユーザサイド管理としてアメブロの中の人が作った書類が流出してイタズラ(犯罪だけどね)に使われたってあたりが真相っぽいね。他のコメントにもあったけど、芸能人ブログって金の卵なんだからユーザサイドとは言え杜撰な管理な気がするなあ。
サーバサイドのパスワード管理とユーザサイドのパスワード管理とは明確に異なるけど、その辺がごっちゃになってる人が結構居そうなのも判ってなかなか興味深い:-P
ちなみに「ニコニコ動画」とか「mixi」も数年前は駄目サイトだったけど、今はどうなのかな?# よく使うパスワードでメールボックス検索してみると結構面白い結果になると思うよ:-)
今回漏洩したのは、「運営者側」の「ユーザサイド」な所が問題なのでは。運営者側がそんなものを持っていると、何かあった時に責任問題になっちゃうよ。
流出したExcelファイルはDBから抜いたデータというより、自己流のフォーマットだったらしいので、おそらくシステムに代理更新の機能がなくて、担当者が同じアカウントを使い回す必要があったんでしょう。あと、パスワードをハッシュで保存しているかどうかにかかわらず、担当者の権限ではパスワードにアクセスするのは無理でしょうから、『「パスワードは聞けば教えてくれるはずだ」みたいなユーザ』のためのメモもかねていたのではないかと。
> HTTPのdigest認証
digest認証では、おおざっぱに言えばサーバから送られてきた「パスワードハッシュ」「サーバが生成したランダム文字列」と「クライアントが生成したランダム文字列」をクライアント側で連結した文字列を作り、クライアントはこの文字列のハッシュを(クライアントが生成したランダム文字列と共に)サーバに送ります。サーバ側は「パスワードのハッシュ」は必要ですが、生パスワードを保存する必要はありません。
cram-md5 や apop では、サーバ側に生パスワードの保存が必要なのはその通りです。でも、最近の流行では、apop みたいな認証だけの暗号化なんかは下火で、通信路そのものをSSLを通して暗号化し、認証は生パスワードを流す、というの方向じゃないですかね。
だから、1、なるべく一般公開してないE-mailアドレスを使う。2、生年月日や母の旧姓など、プライベートな質問への答も同時に入力させる。くらいの仕組みは必要なんでしょうね。
ニュースサイトくらいなら平文送付でもいいと思うけど、amazonみたいな通販サイトだとリセット&URL送付の方がいいと思うな。
>2、生年月日や母の旧姓など、プライベートな質問への答も同時に入力させる。
これってセキュリティホールになりやすくないですか?一般人でもちょっと調べればわかりそうだったり、有名人ならそれこそWikipediaに書かれていそうな情報が多そうだし。まぁ、普通はそれを見越して更に自分だけにわかる答えを設定するんだろうけど。こういう設定を求められるといつもちょっといやになる。
以前アメリカの誰だったか要人でこれのせいでパスが漏れた件ってなかったっけ?
ある意味要人なTwitterの管理者のバスワードが昨年漏れてましたね [itmedia.co.jp]。
そういやもう昨年なんだなー。
たいていは質問に正解した時にパスワードが画面に出てくるわけじゃなくて本人のメールアドレスに送信されるから、セキュリティ強度はメールクライアントの管理状態によりますね。
たいていは嘘と言うか、違う答えを入れますけど。それゆえに忘れやすいという欠点があります。
最近は母親の旧姓に好きなフルーツを入れるとかいうふうにしています。(↑もちろんこれも偽情報)
偽の回答を覚えているくらいなら、パスワードも忘れないわな。あなたは本当に「アタマ」がいいんだねぇ‥‥。あ、皮肉じゃなしにマジでマジで。ハハッ(笑
あなたの「好きなフルーツ」が偽情報なのはわかりましたが、そもそも「好きなフルーツ」ってソーシャルエンジニアリングに使えるほど、周囲に知られている情報なのでしょうか。(家族以外に)そう言う話、します?そして、他人のそれを覚えています?
まあ、ここでプライベートな情報をさらしておくと、私の好きな三大フルーツは、桃、蜜柑、バナナですが。
好きな食べものの話って無駄話的にけっこうしてますよ。酒も飲まないし、ギャンブルや合コンや風俗とかも行かなくて趣味以外での適当な話題といえば食べることとか天気の話になっちゃいやすいですね。まぁ、それを覚えているかどうかは対象への興味の度合いや話のインパクトにもよると思いますけど。
確かに他人の好きなフルーツなんてよほど親しい人やよく一緒に食事をする人くらいしか分からないですね。
私の好きな三大フルーツは・・・ビワ、スイカ、柿。たまにこれらの中の一つを一シーズン毎日食べていたという話を周りに何度かしたことがあるので、中には覚えている人がいるかもしれません。
もちろんどれもそのままではパスフレーズには使いませんけど。
問題は再設定の仕組みの方でしょう
>「パスワードは聞けば教えてくれるはずだ」みたいなユーザが多いから?
多いから
「小細工しない単純なハッシュ」って具体的にどういうハッシュなんでしょうか?長さの長短はあるとしても、原理的に、ブルートフォース以外でハッシュからもとに復元(解析)は出来ないと思うのですが、違うんでしょうか。
ただ単にパスワードをハッシュ化しただけなら、パスワードを導き出す方法はあります。
レインボーテーブル [wikipedia.org] とか。
そりゃあらかじめ準備しておく総当たりでしょう。それ使って出す場合、(現実的な時間でアタックが可能とは言っても)「導き出している」とは言わないのでは。
まあ今回は(芸能人ブログに限って言えば)それすらしてないのってどうなのよって話なので、もっと守り方があるのかもしれませんな:-)
ソルトの類を加えない場合じゃない。誕生日攻撃とか可能になるから。パスワードをハッシュ化する場合のソルトの加え方とか結構知らない奴がいて適切にハッシュ化してない場合があったりして・・・# オライリーの本なんかでも細かく解説されてたりするね。知己がいないんで実際は知らないけど、駄目なハッシュ化を使ったシステムは存在するんだろうなぁとは思う。
特にパスワードに使う分には、強衝突耐性に関する脆弱性はさほど有効な攻撃手段になりません。弱衝突耐性はまだまだそれほど簡単に突破できるものではないでしょうから、既存のシステムをあわてて修正するところまでは必要ないのではないでしょうか。
もちろん、これから新たに構築するシステムなら、HMAC-SHA256とかをおすすめするわけですが・・・
普通は、ハッシュから元の文字列を得ることができないまたは得られるが十分長い計算を必要とする「一方向性ハッシュ」というのを使う。
親コメはサーバサイドのパスワード管理の話かと。ユーザーが入力したパスワード → SSLなどでサーバに → hash(入力パスワード)==サーバに保存されているハッシュ化したパスワードで、普通、サーバに平文パスワードは置かないものだと思う。
火消し乙
>お役所仕事なんかだとよくありますね。 モニタ、キーボードの裏なんかに付箋が貼ってあったり。
こないだ某警察署にお邪魔しましたが、なんたら情報管理システム端末の横に「IDは○○ID番号(従業員番号みたいなの)、パスワードは同じ」と書いた紙がデカデカと貼ってありました。そして利用するときは胸に着けていたIDカードの番号を打ち込んでいましたとかいないとか。
いやいや、おれも状況知らないからわかんないけど、パスワードを平文化して保存していると断定できないんじゃない?炎上対策として、芸能人のブログは他の誰かが管理しているのかもしれない。即座にやばそうな記事を消したり、コメントを消したり出来るように。そういう芸能人ブロクの管理者と、芸能人本人の間で、パスワードを取り決めて、運用していたのかもしれない。
俺システム組むときにはハッシュというよりMySQLならAES_ENCRYPTな感じでDB側に暗号化関数があればそれ使うな。ハッシュ使うと管理者もパスワード確認ができなくなってしまうからね。パスワードの再設定になっちゃうからただこれも暗号化文字列ばれたら簡単に複合化されちゃうけどね。
さらっと恐ろしいことを書いてるな。管理者もパスワードが確認できないようにハッシュ化するんだよ?パスワードのような(管理者も含めた)第三者に知られては困る情報を暗号化するだけなら平文とかわりない。
平文で保存しているところなんてそうないんじゃないんですかね。自分が知っている範囲でしかありませんが、「復号化可能な」暗号化をして、DBに格納しているものがありました。
このシステムでは、パスワードの再発行は、DBのパスワードを復号化してメールで送信しています。
なぜ、ハッシュ化しないのか、といえば、それは移行したシステムで、前のシステムのデータがそうだったから、それに合わせている模様です。# 僕は実装者ではないので、詳しくは知りません。
メールアドレスではなく、別にID(自分が任意に決められるものの類いではなく、システムが自動設定するID)を使ってログインするのが旧システムだったので、単純なパスワード再発行ではIDを知れない、とか大人の事情があったんだと思われます。
でも実際の所DBからパスワードのフィールドが丸見えになるのってDBの接続IDとパスワードがクラックされたDBそのものにログインできるようになっている場合がそれこそあるからパスワードを平文とかキャッシュとか暗号化なんてしたところでパスワードカラムの部分を空にされればシステム側からもログイン簡単にされてDBどころかシステムも乗っ取られるよね。
ある意味、パスワードフィールドがみれるようになった時点でDBが乗っ取られている。システム改変される可能性を考慮もしないといけない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
未だに時々パスワードを平文で保存してるところがあるけど (スコア:3, 興味深い)
アメブロの騒動、あとからおいついたので現物見てませんが、状況から見てIDとパスワードが平文で保存されてたってことでしょうな。
時折サービス登録するとパスワードが平文で送られてきたり「ハッシュしないで保管してるっぽいなー」ってとこがあるんですが、これはなぜなんでしょう?
# アメブロの場合は芸能人ブログだけ特別扱いで管理してたのかもしれませんけど
流石にハッシュ後を保存するって教科書レベルの話を知らない開発者が居るとは思えないので、なんか理由があるんだと思いますが……
「パスワードは聞けば教えてくれるはずだ」みたいなユーザが多いから?
何らかの理由で「こんな実装したくないのに……」と苦汁を飲んだ開発者が/.Jに居れば、こっそり教えてください:-)
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:2, 興味深い)
芸能人・芸能事務所という特殊な組織を相手する都合、記事を管理するのは芸能人本人、芸能事務所、そしてサイバー、の三者だと思います。
サーバー側が記事を管理する理由はいくつか考えられます(ネット文化に疎い芸能人および事務所相手にコンサルのごとく対応した際の流れ、など)。
そして、社員などが使える管理画面で、指定した記事を修正するような機能が用意されておらず、
直接ユーザ画面から入って記事をいじる運用になっていた。そのため、
漏れないことを前提にした芸能人用ID・Passリストが社内管理されていた…と。
仮定だけで恐縮ですが。
ともあれ、ユーザからすれば信用度は普通に落ちますし、相手が芸能事務所だけに目に見えない後始末はそら大変でしょうに。
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:3, 興味深い)
>相手が芸能事務所だけに目に見えない後始末はそら大変でしょうに。
「ブログの画像は削除されたが、エクセルデータには、IDとパスワードのほかに、
サイバーエージェントの社員と推測されるメールアドレスのほか、
芸能プロダクションにブログを書いてもらうための営業用の資料も掲載。
「事務所ごと取りに行こう!」「事務所内もしょぼい」「バーター必須であれば」など、
芸能プロダクションについての生々しい評判も掲載されている。」
http://www.cyzo.com/2010/01/post_3556.html [cyzo.com]
後始末はすごく大変になりそうな予感。
Re: (スコア:0)
記事やデザインの更新を第三業者や社内チームが行うのケースは当然ありうるから
その場合は平文パスワードを管理し伝えなきゃいけない。
ハッシュ云々言ってるコメントはなんなんだ?
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:1, 参考になる)
そのようなケースでIDを共用するからパスワードを平文で管理する必要が生じるのであって、
本人、業者、社内とユーザごとに別のIDを発行するのがセキュリティ上「当然」の姿なんです。
Re: (スコア:0)
だから別のIDを発行ならわかるが
ハッシュ云々言ってるコメントはなんなんだ?
ハッシュから平文化できるとでも思ってるんだろうか
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:2)
自己フォローしとこう
アメブロに作っていろいろしてみたけど、サーバに平文でパスワードが保存されてるとかはなさそうな気配。
# 実態は判らないけど、いきなり平文で送りつけられてきたりしないし、リセットの手順も良くある形。
ユーザサイド管理としてアメブロの中の人が作った書類が流出してイタズラ(犯罪だけどね)に使われたってあたりが真相っぽいね。
他のコメントにもあったけど、芸能人ブログって金の卵なんだからユーザサイドとは言え杜撰な管理な気がするなあ。
サーバサイドのパスワード管理とユーザサイドのパスワード管理とは明確に異なるけど、その辺がごっちゃになってる人が結構居そうなのも判ってなかなか興味深い:-P
ちなみに「ニコニコ動画」とか「mixi」も数年前は駄目サイトだったけど、今はどうなのかな?
# よく使うパスワードでメールボックス検索してみると結構面白い結果になると思うよ:-)
Re: (スコア:0)
今回漏洩したのは、「運営者側」の「ユーザサイド」な所が問題なのでは。
運営者側がそんなものを持っていると、何かあった時に責任問題になっちゃうよ。
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:1)
流出したExcelファイルはDBから抜いたデータというより、自己流のフォーマットだったらしいので、おそらくシステムに代理更新の機能がなくて、担当者が同じアカウントを使い回す必要があったんでしょう。
あと、パスワードをハッシュで保存しているかどうかにかかわらず、担当者の権限ではパスワードにアクセスするのは無理でしょうから、『「パスワードは聞けば教えてくれるはずだ」みたいなユーザ』のためのメモもかねていたのではないかと。
-------- tear straight across --------
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:1)
今回の騒動には当てはまりませんが…
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:1)
> HTTPのdigest認証
digest認証では、おおざっぱに言えば
サーバから送られてきた「パスワードハッシュ」「サーバが生成したランダム文字列」と「クライアントが生成したランダム文字列」
をクライアント側で連結した文字列を作り、
クライアントはこの文字列のハッシュを(クライアントが生成したランダム文字列と共に)サーバに送ります。
サーバ側は「パスワードのハッシュ」は必要ですが、生パスワードを保存する必要はありません。
cram-md5 や apop では、サーバ側に生パスワードの保存が必要なのはその通りです。
でも、最近の流行では、apop みたいな認証だけの暗号化なんかは下火で、
通信路そのものをSSLを通して暗号化し、認証は生パスワードを流す、
というの方向じゃないですかね。
Re: (スコア:0)
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:3, おもしろおかしい)
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:1)
パスワードを忘れた場合、ランダム生成した一時パスワードを登録メールアドレスに送付する仕組みも作りました。
こちらで(開発側で)用意したメール文言は「一時的なパスワードです。3日以内にログインして設定し直してね」というものでしたが、これが絶不評。
パスワード変更が面倒だの、期間が3日では短すぎるだの、まあ、出るわ出るわ……。
結局、ユーザの入力したパスワードをそのまま送付する仕組みに変更する事になりました。
(パスワードを平文で流すことよりも、ユーザの利便の方が重要な事らしいです)
notice : I ignore an anonymous contribution.
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:1)
嫌いなあいつのパスワードを1時間毎に書き換えてやることもできちゃう。
というわけで、自分はもっぱら変更するためのURLをメールでお知らせする形ですね。
Re: (スコア:0)
だから、
1、なるべく一般公開してないE-mailアドレスを使う。
2、生年月日や母の旧姓など、プライベートな質問への答も同時に入力させる。
くらいの仕組みは必要なんでしょうね。
ニュースサイトくらいなら平文送付でもいいと思うけど、
amazonみたいな通販サイトだとリセット&URL送付の方がいいと思うな。
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:1)
>2、生年月日や母の旧姓など、プライベートな質問への答も同時に入力させる。
これってセキュリティホールになりやすくないですか?
一般人でもちょっと調べればわかりそうだったり、有名人ならそれこそWikipediaに書かれていそうな情報が多そうだし。
まぁ、普通はそれを見越して更に自分だけにわかる答えを設定するんだろうけど。
こういう設定を求められるといつもちょっといやになる。
以前アメリカの誰だったか要人でこれのせいでパスが漏れた件ってなかったっけ?
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:2)
ある意味要人なTwitterの管理者のバスワードが昨年漏れてましたね [itmedia.co.jp]。
そういやもう昨年なんだなー。
Re: (スコア:0)
たいていは質問に正解した時にパスワードが画面に出てくるわけじゃなくて本人のメールアドレスに
送信されるから、セキュリティ強度はメールクライアントの管理状態によりますね。
Re: (スコア:0)
「あなたの好きな食べ物は?」と云う設問に「うんこ」でも問題無し。
ひょっとして、GmailやYahooメールとかの登録時に、みんな本当の事を入力してるのか?
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:1)
たいていは嘘と言うか、違う答えを入れますけど。
それゆえに忘れやすいという欠点があります。
最近は母親の旧姓に好きなフルーツを入れるとかいうふうにしています。
(↑もちろんこれも偽情報)
Re: (スコア:0)
偽の回答を覚えているくらいなら、パスワードも忘れないわな。
あなたは本当に「アタマ」がいいんだねぇ‥‥。あ、皮肉じゃなしにマジでマジで。ハハッ(笑
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:1)
あなたの「好きなフルーツ」が偽情報なのはわかりましたが、
そもそも「好きなフルーツ」ってソーシャルエンジニアリングに使えるほど、
周囲に知られている情報なのでしょうか。
(家族以外に)そう言う話、します?そして、他人のそれを覚えています?
まあ、ここでプライベートな情報をさらしておくと、私の好きな三大フルーツは、
桃、蜜柑、バナナですが。
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:1)
好きな食べものの話って無駄話的にけっこうしてますよ。
酒も飲まないし、ギャンブルや合コンや風俗とかも行かなくて趣味以外での適当な話題といえば食べることとか天気の話になっちゃいやすいですね。
まぁ、それを覚えているかどうかは対象への興味の度合いや話のインパクトにもよると思いますけど。
確かに他人の好きなフルーツなんてよほど親しい人やよく一緒に食事をする人くらいしか分からないですね。
私の好きな三大フルーツは・・・ビワ、スイカ、柿。
たまにこれらの中の一つを一シーズン毎日食べていたという話を周りに何度かしたことがあるので、中には覚えている人がいるかもしれません。
もちろんどれもそのままではパスフレーズには使いませんけど。
Re: (スコア:0)
問題は再設定の仕組みの方でしょう
Re: (スコア:0)
>「パスワードは聞けば教えてくれるはずだ」みたいなユーザが多いから?
多いから
Re: (スコア:0)
Re: (スコア:0)
「小細工しない単純なハッシュ」って具体的にどういうハッシュなんでしょうか?
長さの長短はあるとしても、原理的に、ブルートフォース以外でハッシュからもとに復元(解析)
は出来ないと思うのですが、違うんでしょうか。
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:2, 参考になる)
ただ単にパスワードをハッシュ化しただけなら、パスワードを導き出す方法はあります。
レインボーテーブル [wikipedia.org] とか。
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:1)
そりゃあらかじめ準備しておく総当たりでしょう。
それ使って出す場合、(現実的な時間でアタックが可能とは言っても)「導き出している」とは言わないのでは。
まあ今回は(芸能人ブログに限って言えば)それすらしてないのってどうなのよって話なので、もっと守り方があるのかもしれませんな:-)
Re: (スコア:0)
ソルトの類を加えない場合じゃない。
誕生日攻撃とか可能になるから。
パスワードをハッシュ化する場合のソルトの加え方とか結構知らない奴がいて適切にハッシュ化してない場合があったりして・・・
# オライリーの本なんかでも細かく解説されてたりするね。
知己がいないんで実際は知らないけど、駄目なハッシュ化を使ったシステムは存在するんだろうなぁとは思う。
Re: (スコア:0)
衝突耐性についてもチェックする必要があったり
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:1)
特にパスワードに使う分には、強衝突耐性に関する脆弱性はさほど
有効な攻撃手段になりません。弱衝突耐性はまだまだそれほど簡単に
突破できるものではないでしょうから、既存のシステムをあわてて
修正するところまでは必要ないのではないでしょうか。
もちろん、これから新たに構築するシステムなら、HMAC-SHA256とかを
おすすめするわけですが・・・
Re: (スコア:0)
Re: (スコア:0)
「パスワードはハッシュして保管するべき」ということを知らない、又は知っていても平文の方が扱いやすいから
ではないでしょうか。
私もこの書き込みを見るまでDBにそのままパスワードが格納されてるもんだと思ってましたから。
きっと常識なんでしょうけど開発者のレベルはピンキリですからね。
Re: (スコア:0)
しかし複合できる権限で入られて根こそぎ
というオチだったりして?
権限は関係ない (スコア:0)
普通は、
ハッシュから元の文字列を得ることができない
または得られるが十分長い計算を必要とする
「一方向性ハッシュ」というのを使う。
Re: (スコア:0)
普通はハッシュ化して保存
ではパスワードを保存してくれと言われたら?
それならばDB自体を暗号化し、正当なアクセス権を持っているユーザのみ複合出来る形式にするのかなと思ったって事
Re: (スコア:0)
複合コンプレックスと命名しよう
Re: (スコア:0)
パスワードはハッシュ値で保存するって本当なんですか?
プログラムでハッシュ値で保存するのはわかりますけど、ユーザーがハッシュ値で保存すると
ハッシュ値からはパスワードを復元できないですよね
その場合は元の平文のパスワードがない限り意味ないことになりませんか?
パスワード保存ソフトを使わない一般ユーザはテキストにIDとパスワード書いて
コピペでログインすることが普通だと思うんですけど・・・
エクセルファイルにパスワードを付けるというはわかります
Re: (スコア:0)
親コメはサーバサイドのパスワード管理の話かと。
ユーザーが入力したパスワード → SSLなどでサーバに → hash(入力パスワード)==サーバに保存されているハッシュ化したパスワード
で、普通、サーバに平文パスワードは置かないものだと思う。
Re: (スコア:0)
備忘録もかねているので担当者の私的管理ファイルを何らかの手段で入手した悪い人が
愉快犯的にそのパスワードで改ざんしたHPで公開したように思えます
Re: (スコア:0)
火消し乙
Re: (スコア:0)
業者としてはユーザパスワードは変更してくれるようにお願いするしかないわけで、実際それをやるかどうかはクライアントさん頼み。さすがに管理パスワードは教えてませんけど。
Re:未だに時々パスワードを平文で保存してるところがあるけど (スコア:1)
>お役所仕事なんかだとよくありますね。 モニタ、キーボードの裏なんかに付箋が貼ってあったり。
こないだ某警察署にお邪魔しましたが、なんたら情報管理システム端末の横に
「IDは○○ID番号(従業員番号みたいなの)、パスワードは同じ」と書いた紙がデカデカと貼ってありました。
そして利用するときは胸に着けていたIDカードの番号を打ち込んでいましたとかいないとか。
Re: (スコア:0)
いやいや、おれも状況知らないからわかんないけど、パスワードを平文化して保存していると断定できないんじゃない?
炎上対策として、芸能人のブログは他の誰かが管理しているのかもしれない。即座にやばそうな記事を消したり、コメントを消したり出来るように。そういう芸能人ブロクの管理者と、芸能人本人の間で、パスワードを取り決めて、運用していたのかもしれない。
Re: (スコア:0)
俺システム組むときにはハッシュというより
MySQLならAES_ENCRYPTな感じでDB側に暗号化関数があればそれ使うな。
ハッシュ使うと管理者もパスワード確認ができなくなってしまうからね。
パスワードの再設定になっちゃうから
ただこれも暗号化文字列ばれたら簡単に複合化されちゃうけどね。
Re: (スコア:0)
さらっと恐ろしいことを書いてるな。
管理者もパスワードが確認できないようにハッシュ化するんだよ?
パスワードのような(管理者も含めた)第三者に知られては困る情報を暗号化するだけなら平文とかわりない。
Re: (スコア:0)
平文で保存しているところなんてそうないんじゃないんですかね。
自分が知っている範囲でしかありませんが、
「復号化可能な」暗号化をして、DBに格納しているものがありました。
このシステムでは、パスワードの再発行は、DBのパスワードを復号化してメールで送信しています。
なぜ、ハッシュ化しないのか、といえば、
それは移行したシステムで、前のシステムのデータがそうだったから、それに合わせている模様です。
# 僕は実装者ではないので、詳しくは知りません。
メールアドレスではなく、
別にID(自分が任意に決められるものの類いではなく、システムが自動設定するID)を使ってログインするのが旧システムだったので、
単純なパスワード再発行ではIDを知れない、とか大人の事情があったんだと思われます。
Re: (スコア:0)
でも実際の所DBからパスワードのフィールドが丸見えになるのってDBの接続IDとパスワードがクラックされたDBそのものにログインできるようになっている場合がそれこそあるから
パスワードを平文とかキャッシュとか暗号化なんてしたところでパスワードカラムの部分を空にされればシステム側からもログイン簡単にされてDBどころかシステムも乗っ取られるよね。
ある意味、パスワードフィールドがみれるようになった時点でDBが乗っ取られている。
システム改変される可能性を考慮もしないといけない。