パスワードを忘れた? アカウント作成
9903032 story
情報漏洩

@PAGESで平文のパスワードを含む全ユーザーの管理情報が流出 41

ストーリー by headless
平文 部門より
無料ホームページサービス「@PAGES」のユーザー管理情報データベースから、平文のパスワードを含む全ユーザー175,297人分の管理情報が流出したそうだ(ユーザ情報流出に関するお知らせ【第2報】ITmediaニュースの記事INTERNET Watchの記事CNET Japanの記事)。

流出したのはパスワードのほか、ユーザー名やメールアドレス、登録日時、登録時のIPアドレスなど。クレジットカード情報や住所、氏名、電話番号などは管理情報として登録されていないため流出していないという。原因としては、ユーザー管理情報データベースにアクセスするためのユーザー名とパスワードが流出し、データが抜き出された可能性が想定されるとのこと。流出したデータは「一般のブラウザではアクセスできない特定の場所」で閲覧可能な状態となっており、該当ファイルを削除することは技術的に困難だという。@PAGESを運営するアットフリークスでは、全ユーザーのパスワードをリセットし、ユーザー管理情報データベースに保存するパスワードを暗号化、ユーザー管理情報データベースにアクセスするためのパスワードを変更したとのことだ。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 「一般のブラウザではアクセスできない特定の場所」という言い方をしていますが、これは少しでも安心感を持たせたいという目的があってこういう言い方になったのでしょうか。
    確かに、普通はツール(意味深)をインストールしてアクセスする場所にありました。
    けれども、私はなんのツールもインストールせず、特別なアドインや拡張機能をインストールしていないFirefoxで流出したデータを含むファイルをダウンロードできました。ある程度の知識があれば、だれでもできると思います。

    ファイルの内容を見た印象は、データベースをセットアップするときに使ったのかなというものでした。
    このファイルを使った人は、その内容(平文でのパスワードを含んでいること)の重要性から、非常に慎重に扱わないといけないと分かってそうなものですけどね。

    メールアドレスの種類が多様だったので、特徴的なものをgrepで抜き出してみました。
    数はユーザ数ですが、発表資料に合わせて重複があってものべで数えています。
    @*.go.jp:16
    @*.lg.jp:6
    @pref.*.jp:4
    @*.city.*.jp:3
    @town.*.jp:1
    @*.ac.jp:890

    .ac.jpが特に多い点が目につきますが、毎年同じ時期に集中してアカウントを取得しているので、情報系の演習で使われたのではないかと推測しています。
    .co.jpは全体の4割程度を占めていて、excite&hotmail&yahooを除くと597ですが、そこから会社のアドレスとその他のフリーメールアドレスとを分別しきれませんでした。
    あと、明らかに有効でないメールアドレスであったり、アフィリエイト業者が取得しているためにアカウントが凍結されたりしているので、有効なアカウント数は発表されたユーザ数よりも少ないと思います。

    • by chuukai (18189) on 2013年08月31日 19時06分 (#2451712) 日記

      ユーザ情報流出に関するお知らせ【第2報】 [atwiki.jp]から一部転載。

      【追記】※流出中のデータは2013年2月27日午後2時54分現在のものです。
      それ以降にパスワードを変更している場合には流出したパスワードでの不正アクセスの恐れはございません。
      また、流出時刻以降にメールアドレスを変更している場合には変更後のメールアドレスは流出しておりません。

      それ以降にパスワードを変更している場合には(変更前のパスワードは流出しているので既に不正アクセスされていたかもしれませんが、変更後のパスワードについては流出していないと考えたいから)流出したパスワードでの不正アクセスの恐れはございません。
      また、流出時刻以降にメールアドレスを変更している場合には(変更前のメールアドレスは流出しているので既に不正アクセスされていたかもしれませんが、変更できたということは変更以降には流出していないと考えたいから)変更後のメールアドレスは流出しておりません。

      ニホンゴムズカシイネ。

      個人的には、@PAGESへの不正アクセスによる被害よりも、メールアドレスが所属しているメールサーバに使いまわされたパスワードで不正アクセスされることのほうが被害甚大だと思っています。

      親コメント
      • by Anonymous Coward

        >メールアドレスが所属しているメールサーバに使いまわされたパスワードで不正アクセスされること

        デフォルトでは@PAGESが生成した5文字程のパスワードが設定されているので、ユーザ側にて使い回しているパスワードへ変更する措置を取っていない限りは、そのような恐れはありません。

        • >5文字程

          今確認したら、生成される文字数は英数字で14字です。
          英数字で14字でないパスワードを数えたら、31317個でした。
          全体で175297個ありますから、少なくとも17.9%はパスワードを変更していることになります。

          >ユーザ側にて使い回しているパスワードへ変更する措置を取っていない限りは、そのような恐れはありません。

          リスト形式のクラックで使うには十分な数だと思います。

          親コメント
          • ちょっと訂正。
            データベース上ではハッシュ化か何かして14字以上にしているようですね。
            逆にいうと13字以下の場合は生のパスワードになっています。
            14字以上の場合にも生のパスワードが含まれていますが、割合としては少ないものでしょう。
            175297個のうち英数字で13字以下のパスワードは31309個ありますから、少なくとも17.9%はパスワードを変更していることになります。

            親コメント
  • 一般のブラウザではアクセスできない特定の場所においてユーザ管理情報DBのデータが閲覧可能な状態です。
    現時点では該当ファイルを削除することは技術的に困難と思料しておりますが、

    やけに遠回しな表現だけど、そういう事だよね。

  • @chs「【お詫び】ユーザ情報流出に関するお知らせ」 [atwiki.jp]

    > ※流出内容
    >ユーザ名
    >パスワード(暗号化済)
    >メールアドレス
    >登録時のIP
    >※影響範囲
    >2013年2月25日 19時36分以前に登録されたユーザ様全員

    >パスワードは単一方向の暗号方式を用いており、
    >暗号化されたパスワードから元のパスワードを推測することはできません。

    こうなると、アットフリークス管理下のサービスでは全てユーザデータの流出を疑う必要があるのではないだろうか。
    少なくとも、ユーザ側は自衛としてそれを前提として動くべきなんじゃないかなと思う。

  • 流出した時点で大量に拡散するから最初に公開した場所なんて無意味射水市
  • by Anonymous Coward on 2013年08月31日 15時02分 (#2451619)

    こういう事件を見るたびになぜパスワードを平文保存するのか理解できないのだが。
    ハッシュ化するのが常識じゃないのか?

    • by Anonymous Coward

      そして慌てて「ユーザーのパスワードの暗号化」とか言われても、またマヌケな実装してんでしょ?と疑わざるを得ない件。

    • by Anonymous Coward

      「IT技術者の人件費は、システムが動かなくなるまで削減され続ける」
      というマーフィーの法則(?)があってもいいと思う。

      そういう組織では技術者は「安かろう悪かろう」なんだよ。

      • by Anonymous Coward

        実際安かろう悪かろうなエンジニアも多いけどな

        • by Anonymous Coward

          そりゃ、やっすい金しか払ってくれない奴等になんて
          モチベーション上がる訳もなく品質の悪いものが納入されるだろ

          • by Anonymous Coward

            まあそれも一面の真実かもしれんけど、
            同じ相手に高い報酬払えば高い品質が得られるわけでもないでしょ。

            安かろう悪かろう。
            悪かろう安かろう。

            • by Anonymous Coward
              同じ相手だって高報酬でこの先仕事くれそうなら保守性高めたりなんだりしますがな
            • by Anonymous Coward

              >同じ相手に高い報酬払えば高い品質が得られるわけでもないでしょ。

              得られる場合は多いと思いますよ。
              システム改修には多くの時間=マンパワーが必要なわけで、
              逆に言うと会社側が明示的にマンパワーを使うことを許可しない
              限り、改修はされません。

              改修にマンパワーを使うことを許可したら、結果的に
              残業代という「報酬」を払うことになります。

      • by Anonymous Coward

        >「IT技術者の人件費は、システムが動かなくなるまで削減され続ける」

        すでに「壊れたダンプカー理論」というのが存在してます。
        http://www.mars.dti.ne.jp/~hirok/xp/col/028.html [dti.ne.jp]

    • by Anonymous Coward

      こういうコメントを見るたび、結構複雑な気分になる。常識なのは確かなのだが。
      個人的にはパスワードよりもその他の個人情報の方が流出の害があるので、パスワードが平文保存されていてもあまり問題はない。
      (パスワードの使い回しは、ユーザーの方が悪いと思っている)
      どちらかというと、住所氏名レベルのものは暗号化して、漏洩の堤防を作ってもらった方が有り難いと言えば有り難い。

      パスワードを平文保存していると、管理者レベルの人に(意識しなくてもうっかり)パスワードを見られてしまうリスクもあるが、
      メアドの類も同様に他人には見られたくない情報なので、取り立ててパスワードばかりを厳重に取り扱ってもらう事が良いとも言えない。

      まあ、パスワードを平文保存しておくメリットは特にないから、ハッシュ化ぐらいやっておけという事なのだろうが・・。

      • by JULY (38066) on 2013年08月31日 17時34分 (#2451680)

        どちらかというと、住所氏名レベルのものは暗号化して、漏洩の堤防を作ってもらった方が有り難いと言えば有り難い。

        エンドユーザの立場としては確かにそうかもしれないけど、元々、特殊な事情がない限り、平文のパスワード(可逆な暗号化処理を処理をしている場合を含む)をシステム側で保持する理由がないのに、それを平文で取得できた時点で、住所、氏名に関するまっとうな保護手段が容易できるわけがない、と思っちゃうなぁ。

        可逆な形でユーザのパスワードを保持するって、サーバサイドにとっては、かなりリスクの高い行為なんだけど。

        親コメント
        • 個人情報もユーザーパスワードで暗号化すればいいのに、ということでは。
          それならパスワードをハッシュ化しておけば、パスワードが判明しない限り個人情報が漏洩することもない。

          とはいえ、運用側としては、請求書送るとか運用上の目的があって個人情報を持っていると思うので、復号できないと困ってしまうのは確か。そうするとバックドアを用意するか、パスワードを復号可能な状態で保存するか、になってしまう……

          そこで考えた。
          個人情報を暗号化したキーを所有するのは管理者のみとする。
          ユーザーは個人情報を「登録」できるが、閲覧できるのは管理者だけとする。
          登録済みの個人情報を修正するには、単純に再登録する。(修正不可。上書きのみ。項目単位での部分的な再登録は許可)
          かつて、パスワードの確認機能を廃して再設定機能のみとしたように、個人情報も確認機能を取っ払って再設定のみ可能としてしまう。
          これならどうだろう。

          親コメント
          • by monaoh (12125) on 2013年08月31日 21時06分 (#2451744)

            個人情報を暗号化したキーを所有するのは管理者のみとする。
            ユーザーは個人情報を「登録」できるが、閲覧できるのは管理者だけとする。

            「のみとする」なんて言葉だけで対策になってないです。
            何らかの問題で両者が漏れて、漏洩するだけでしょう。

            大抵の情報漏洩は、「閲覧できるのは権限のあるユーザーのみとする」システムで起きていますよ。

            親コメント
          • by JULY (38066) on 2013年08月31日 22時31分 (#2451764)

            とはいえ、運用側としては、請求書送るとか運用上の目的があって個人情報を持っていると思うので、復号できないと困ってしまうのは確か。そうするとバックドアを用意するか、パスワードを復号可能な状態で保存するか、になってしまう……

            普通は、

            • 個人情報を暗号化するための鍵は、都度、乱数で生成して暗号化する。
            • その鍵を、ユーザのパスワードから生成する鍵(例えば、パスワードのハッシュ値)を使って暗号化する。
            • 同様に、管理者のパスワードから生成する鍵を使って暗号化する(つまり、鍵を暗号化したデータを2つ保存する)
            • ユーザ、および、管理者がパスワードを変更する場合、変更前のパスワードで一度、復号化して鍵を取り出したあと、変更後のパスワードで再び暗号化して保存する。

            とするかな。確か、Windows で暗号化フォルダを使った時の挙動なんかが、こんな感じだったはず。

            親コメント
          • by Anonymous Coward

            郵便局が住所と氏名をハッシュ化するサービスを提供すれば、IT屋が住所と氏名を管理する必要は全くないですよね。

          • by Anonymous Coward

            いや、運用のためならそういう情報を外部公開しているサーバや同じサーバセグメントに置いておく必要は無いわけで。
            ユーザーが変更する度にトリガーでもかませ、外部から一方通行で参照できない管理セグメントのどっかへ変更を飛ばして
            そちらで管理するとか、やり様はいろいろとある。

            問題は本人がパスワード忘れて復号化も出来なくなってしまった時だけど、そのときは別途サービス側で用意した
            仮パスワードで暗号化したデータで上書きしてしまうとかさ。

            • by Anonymous Coward

              >問題は本人がパスワード忘れて復号化も出来なくなってしまった時

              このときに、そのIDの持ち主は連絡してきた本人とどうやって確認するか?
              が問題では?

              普通、個人情報をある程度比較して一致してたら本人とみ見なすと思うのですが。

    • by Anonymous Coward

      チャレンジレスポンス認証に使いたい場合、とか。

      http://www.ipa.go.jp/security/awareness/administrator/remote/capter6/5.html [ipa.go.jp]

      昔ハッシュしかないのに「APOP対応お願い☆」と言われた困った覚えがある。

      • by Anonymous Coward

        あー、安直すぎですね。実際はこうなのですよ。
        http://www.ipa.go.jp/security/awareness/vendor/programmingv1/b09_01.html [ipa.go.jp]

        3. クライアントプログラムは入力されたパスワードのメッセージダイジェストを計算する。
        4. クライアントプログラムは,3. で計算したメッセージダイジェストと 1. で与えられた「チャレンジ」を合わせたものを元のデータとしてもう一度メッセージダイジェストを計算する。これは「レスポンス」と呼ばれる(注1)。

        • by Anonymous Coward on 2013年08月31日 21時31分 (#2451750)

          4. クライアントプログラムは,3. で計算したメッセージダイジェストと 1. で与えられた「チャレンジ」を合わせたものを元のデータとしてもう一度メッセージダイジェストを計算する。

          この実装だと、サーバー側で持っているハッシュ化された文字列を入手されると、それを使ってサービスにログインできてしまうので、生パスワードを入手されたのと実質同じことになります。ハッシュ化したメリットは、他のサービスでパスワードを使いまわしていても被害が及ばないという程度ではないでしょうか。

          ちなみに、元コメントで触れられているAPOPは、生パスワードとチャレンジ文字列を合わせてレスポンスを生成するプロトコルなので、サーバー側で生パスワードを持つ必要があります。

          UNIX でパスワードをハッシュ化することで安全性が増加していたのは、経路を盗み見るのが困難だったからです。無料サービスで https を使うことが予算的に厳しい場合、ネットワーク上に生パスワードを流すわけにはいかず、チャレンジレスポンス方式を使うことになりますが、その場合、結局サーバー側で保持しているのは「見られたらログインされてしまう文字列」であって、それにハッシュがかかっていたとしても安心できるものではありません。

          親コメント
        • by Anonymous Coward

          それって興味本位のカジュアルクラックは防げるけど、本気のクラックには無意味ですよね。
          でも緩和策としてはアリか。その辺、運用形態とも関わってくるから有効性の評価は難しいな。

    • by Anonymous Coward

      ハッシュ化するにも、ちゃんとsaltを使ってるところは、どれだけあるやら

  • by Anonymous Coward on 2013年08月31日 15時08分 (#2451621)

    こういう流出が増えたように感じるが、ハッカーが日本の企業を狙うようになったのかな?
    IDとパスの組み合わせを他のサイトに流用してアタック掛けて成果が出ることがわかって
    海外組のターゲットが日本に移ったとか

    • by Anonymous Coward
      こんだけ流出してもセキュリティにカネなんてかけたくねぇ。
      って経営者いっぱいいそうだし。
    • by Anonymous Coward

      ホント最近マジで多い。

  • by Anonymous Coward on 2013年08月31日 15時31分 (#2451630)

    同社運営のatwordがメンテナンス中のまま止まっているのはそのせいか(´・ω・`)

    現在、@wordは、セキュリティ上の安全を確保すべく、メンテナンス作業しております。

    誠に申し訳ございませんが、メンテナンス作業が終了するまでお待ちください。

    鋭意修正を行っておりますが、修正の目処が立ちましたら告知させていただきます。

    ご不明な点などございましたら、こちらまでお問い合わせいただけますようお願いいたします。

    そのくせ最新情報が2013/01/31 [atwiki.jp]で止まったまんま。
    @CHS [atwiki.jp]も漏れてますな。

  • by Anonymous Coward on 2013年08月31日 15時54分 (#2451641)

    つまり、こういう事だろ。でもネットは記録が残るから記憶には残らなくても
    それなりのしっぺ返しはあるだろうから安心しちゃいかんよ。

    • by Anonymous Coward

      漏れているのが2月27日以前のデータっていうのは気になるね。
      すでに半年経っていて,実際に漏れたデータが確認されたから漏洩が明らかになったんだろうけど,
      @PAGES がどの時点で把握していて,8月28日の緊急メンテ・公表にいたったのかは興味深い。

  • by Anonymous Coward on 2013年08月31日 18時55分 (#2451707)

    流出問題を受けて、ユーザーのログインパスワードは強制リセットされたんですが、MySQLパスワードはそのままです。
    一方的に変更すると、パスワードベタ書き状態のスクリプトが動かなくなるから避けたんでしょうけど、
    ユーザーがMySQLパスワードを変更する画面も用意されていません。
    MySQLパスワードからの変更なんて最初から想定していないのです。
    ユーザーに公開されている phpMyAdmin にログインすると、ユーザーデータベースのテーブル操作(SELCT/UPDATE...)が可能になります。
    一応クエリ実行で set pasword = 〜 も出来るのです(まあ何でも出来るわけです)が、平文で流れます。
    そもそもここの各種管理ページには https の概念がありません。
    基本無料のサービスなんだものと割り切って使うしかないのかもしれません。

  • by Anonymous Coward on 2013年08月31日 20時33分 (#2451738)

    捕まったというニュースをほとんど聞いたことがないのですが、実際に捕まってないのでしょうか。

    • by Anonymous Coward

      そもそも、被害届とか出てるんでしょうかね??

typodupeerror

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

読み込み中...