パスワードを忘れた? アカウント作成
11127579 story
プライバシ

はてなでも他社サービスから流出したパスワードを使用したとみられる不正ログインが発生 29

ストーリー by headless
再度 部門より
はてなは20日、他社サービスから流出したIDとパスワードを使用したものとみられる不正ログインが発生したことを明らかにした。はてなアカウントでは、2月にも同様の手口による不正ログインが発生している(はてなの日記INTERNET Watchの記事ITmediaニュースの記事インターネットコムの記事)。

不正なログイン試行は16日から始まり、19日18時までに約160万回行われたという。実際に不正ログインされたのは2,398アカウント。このうち、3アカウントではメールアドレスが変更され、Amazonギフト券交換の申し込みが行われたそうだ。ただし、Amazonギフト券交換はスタッフが目視で確認のうえで手続きを行っているため、交換には至っていない。はてなでは「メールアドレス変更時には、変更前のメールアドレスに対しても変更通知メールを送付する」という対策をとっており、ユーザーからいち早く指摘を受けることができたとしている。

このほか、不正ログインを受けたアカウントでは氏名、郵便番号、生年月日が閲覧・変更された可能性があるほか、メールアドレスやクレジットカード番号の下4桁が閲覧された可能性がある。クレジットカード情報でカード番号の下4桁以外の部分や、有効期限などが閲覧された可能性はなく、金銭的な被害は発生していないとのこと。不正ログインを受けたアカウントについてはログイン状態を強制的に停止し、パスワードをランダムな文字列に変更したうえで、パスワードを変更するようにメールで連絡している。ただし、メールアドレスを変更された3人のユーザーに対しては、別の方法で連絡しているとのことだ。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 単純なリスト攻撃ってこともないのかな?

    取得したリストのパスワードを辞書にして、IDリストxパスワードリストみたいなかけ算になってるとか?

    # あと回数に対しての侵入度合いが低いのはリテラシーが高い、わけはないよなぁ...

    --
    M-FalconSky (暑いか寒い)
    • by Anonymous Coward

      はてなからのメールではリスト攻撃って明言してましたけどね。
      メールが来るまではてなのアカウント作っていたの忘れてましたよ。

      • by shibuya (17159) on 2014年06月22日 20時17分 (#2625940) 日記

        配信されたメールでは:

        このメールは、はてな全ユーザー様にお送りしています。

        今回の不正アクセスは、他社サービスから流出または不正取得された
        アカウント情報(IDとパスワードの組み合わせ)を流用された
        「リスト型アカウントハッキング(リスト型攻撃)」である可能性が
        高いと考えています。

        という記載で、ストーリー中のURIにある“はてなの日記” 2014-06-20と事実上同じ案内ですね。
        ⇒大当たりの数人を除けば“はてなの日記” 2014-06-20を読めば用は足りる。
        // 「100%正しい」と明言していないこと以外は (#2625925) の説明の蒸し返しで御免。

        親コメント
  • by Anonymous Coward on 2014年06月22日 18時08分 (#2625878)

    うちもうちも、というやつですか

    • by Anonymous Coward

      >不正なログイン試行は16日から始まり、19日18時までに約160万回行われたという。

      事実としてこれほどの大量のアタックがあった状況で、はてなをからかうのが妥当とは思えませんね。
      たれこみを読む限りでは適切な対応が取られているように見えます。

      • by Anonymous Coward

        6Hz以上のアタックを3日間見過ごしたというのは、適切な対応だろうか。

        • by Anonymous Coward

          > 見過ごした

          ソースある?本当にはてな側はログも何も監視してなかったの?
          ログイン試行の増大はいろいろと原因が考えられるわけだけど、全く気づかず原因調査すらしてなかったというソースある?

          > 適切な対応だろうか

          適切であったか適切でなかったか、しきい値みたいな、なんかこうガイドラインみたいなものってあるの?
          教えてちょ。
          無いなら、適切か否かはただの個人による感想だよね?ツッコミ所じゃないよね?

          • by Anonymous Coward

            >ただの個人による感想だよね?ツッコミ所じゃないよね?
            日本語でヨロシク。

    • by Anonymous Coward

      犯人はこのなかにいる。他社から・・・という発表をした企業のどれか

  • by Anonymous Coward on 2014年06月22日 18時50分 (#2625902)

    "他社"って具体的にどこなん?

    • Re:で、結局 (スコア:2, 参考になる)

      by Anonymous Coward on 2014年06月22日 19時29分 (#2625913)

      ここに最近の不正アクセスの一覧が出てました。
      http://mneme.blog.eonet.jp/default/files/huseiakusesujirei-2.pdf [eonet.jp]
      パスワードまで漏れちゃった例はそんなに多くないですね。
      怪しいのは今年5月のeBay, 今年3月の@wiki、昨年10月のAdobeあたりですかね?
      http://www.itmedia.co.jp/news/articles/1311/06/news040.html [itmedia.co.jp]
      Adobeの件ではひどいパスワードを設定していた人が結構いたようですし、一定の割合で未だに共用パスワードをそのままにしている人がいるんでしょうね。

      親コメント
    • by Anonymous Coward on 2014年06月22日 19時01分 (#2625904)

      "他社"って具体的にどこなん?

      パスワードどころかIDやメールアドレスも同じもの使い回ししてたら特定は難しいだろ

      #サービス毎にメールアドレスとか作ってる変態なのでAC

      親コメント
      • by Anonymous Coward

        #サービス毎にメールアドレスとか作ってる変態なのでAC

        あ、おれも変態だったのかw
        #yahoo.comはyahooというアカウント名を許さないらしいです

    • by Anonymous Coward

      160万ID以上を持ってるところじゃないかなぁ。
      かなり大手のサービスだろうね。

      • by Anonymous Coward on 2014年06月22日 23時06分 (#2626021)

        例えば誰かが同じ欠陥のあるA社、B社、C社、D社のサーバからIDとパスワードを40万件づつゲット。
        それを一つのリストにしたのかもよ。

        小規模向けのシステムに穴があり、そのシステムを使っている小規模事業者だけを集中的に狙えば、メンテの行き届いていないサーバにあたる確率も高いかも。
        小規模事業者なら発覚し難い可能性もあるし、たとえ発覚しても小規模事業者なら公表しない/隠ぺいする可能性が高くなる。
        リストの全貌を入手できたとして「このID、パスワードはうちから漏れたものじゃないしなあ???」みたいなことになり、自分のところから漏れた実感に欠ける。
        一見手間がかかるようだけど、大手を攻略するよりも簡単で安全かもよ。

        親コメント
    • by Anonymous Coward

      最後まで攻撃があったことを公表しなかったところかも(^^;

      自社から漏れたのわかってて、”他社から”と発表しちゃっているところがあるかも知れないけど・・

      • by Anonymous Coward

        ハンロンの剃刀に従うと、自社から漏れたのがわかってなくて”他社から”と発表しちゃっているところがある可能性のほうが高い。

    • by Anonymous Coward

      なぜか語られない

      または不正取得された

      パターン
      最近度々書くのだがフィッシングやマルウェアも忘れないであげて。

  • といってはいるけど、他社サービスのIDのリストが160万件あるだけでも十分開きそうだよな。

  • by Anonymous Coward on 2014年06月23日 5時26分 (#2626070)

    してたら被害は減ったのかもね。
    他で流出したパスワードを使われる前に変更時期が来る可能性が0じゃないって程度だけどね。
    最も複数サービスで同一パスワードを使うような奴だと期待できないかもしれないか。

    セキュリティリスクってサービス提供会社だけの問題じゃないようなぁと改めて思う。

    • by Anonymous Coward

      面白いです。

      あるいはそろそろ、パスワード認証はやめるべきかもしれませんね。

    • by Anonymous Coward

      >定期的なパスワードの変更
      >してたら被害は減ったのかもね。

      たぶん。「他で使っているパスワードと同一のものは使わないでください」が徹底できたほうが被害減ったかも。

      # 今のところ被害に合ってないみたいだけど。私も徹底できてないヘタれなのでAC

    • by Anonymous Coward
      定期的なパスワードの変更がセキュリティリスクを高めることは、さんざん指摘されていますよ。
      • by Anonymous Coward

        パスワード変更でリスクが高まるわけないじゃん。
        適切に変更してるぶんにはいいんですよ。
        でもそんなの非現実的ってだけ。

  • せっかくなので、ここで良いパスワードの生成方法を検討したらどうですかね
    ITリテラシが高そうな/.jではサービスごとにパスワードを変えてる人が多いでしょうが
    どうやって生成し管理するか、面倒ですよね

    個人的には今のところ、いくつかの乱数アルゴリズムを組み合わせてURLやサービス名、
    ユーザー名、パスワードを設定した年月をシードにしてパスワードを生成するコードをCで書いて
    使ってます。
    CですがポータビリティはまあまあでLinux、Windows、ARMのAndroidで動くことを確認してます。
    利点は、

    ・サービスごと、設定した年月ごとに異なるパスワードを生成できる
    ・パスワードをなくしてもシードを再構成できれば同じパスワードが再生成できる
    ・使っている乱数アルゴリズムと組み合わせ方が漏れなければパスワードの類推は出来ない(自分で書いたコードだから大丈夫)

    てな感じでしょうか。他に良いツールやよいやり方を知ってる人がいたら開陳してください
    私や皆さんの参考になりますし。

    • 今までにもなんどか [srad.jp] 挙げました [srad.jp]が、私は、

      アルゴリズムは、
      ・サービス名と、パスフレーズを連結した文字列を生成する(パスフレーズ自体は秘密で全サービス共通)
      ・md5 を取って、base64で可視化する。パスワードに使える文字によっては、+/=は取り除く
      というもの。

      サービス名slashdot.jp、パスフレーズpasswordなら、
      MD5 ("slashdot.jppassword") = 056f4e7e19e041883212ed3708b2d435
      なので、これをbase64化して、パスワードは BW9OfhngQYgyEu03CLLUNQ になります。

      実際には、「slashdot.jppassword」って文字列を与えたら、それに対応するパスワードを表示するperlスクリプトを使ってます。
      1linerで「perl -e 'use Digest::MD5; print Digest::MD5->new->add("slashdot.jppassword")->b64digest;'」って感じ。

      でやってます。
      実際には、上述の結果に対し、パスワードが8文字制限だったら先頭8文字の「BW9Ofhng」を使うというのが基本ですが、アルファベットと数字の混在必須とかのルールで、先頭の文字列に数字が無かったら、切り出し位置を変えるとか、サービス名をちょっと変えて見るとか、小手先の技は使ってます。

      この方法のメリットは

      ・サービス名はテキストデータとしてファイルに保管。ハッシュからのパスワード切り出し位置が先頭以外の場合は、切り出し位置などもメモ。パスフレーズは頭の中にあるだけなので、このテキストだけからはパスワードの入手はまず不可能。
      まあ、どれかのサービスのIDとパスワードが漏れたら、そこからブルートフォースで「秘密のパスフレーズ」を見つけることは理論上は可能ですが、実質、私一人のIDのためにそこまでやる人はいないでしょう。

      ・公開されたアルゴリズムだけで作ってるので(パスワード生成プログラムのソースコードを無くしたとかで)パスワード生成手段が失われる心配がない。
       (そのかわり、生成手順はどこかに残して置く必要があるわけですが、そういうバックアップの意味もかねて、こういうところにコメントしてたり)

      というわけで、漏洩の心配はまずないこと。

      最近の難点は、Androidでのパスワード生成方法が面倒なこと。Androidローカルで動くPerlアプリを作るのは面倒なので、自宅サーバにて、上記パスワード生成コードをCGIで動かして、それをhttps経由でアクセスしてます。問題ないはずなんですけど、何となく気持ち悪さがのこります。

      親コメント
    • by Anonymous Coward
      /dev/random (/dev/urandom) から読み出し、文字列化して、パスワードとして使用。
      サービス名、サイトのアドレス、ID、パスワード、登録情報などはテキストファイルで管理。
      ID、パスワードはWebブラウザに覚えて貰う。(可能な場合)
typodupeerror

身近な人の偉大さは半減する -- あるアレゲ人

読み込み中...