はてなでも他社サービスから流出したパスワードを使用したとみられる不正ログインが発生 29
ストーリー by headless
再度 部門より
再度 部門より
はてなは20日、他社サービスから流出したIDとパスワードを使用したものとみられる不正ログインが発生したことを明らかにした。はてなアカウントでは、2月にも同様の手口による不正ログインが発生している(はてなの日記、
INTERNET Watchの記事、
ITmediaニュースの記事、
インターネットコムの記事)。
不正なログイン試行は16日から始まり、19日18時までに約160万回行われたという。実際に不正ログインされたのは2,398アカウント。このうち、3アカウントではメールアドレスが変更され、Amazonギフト券交換の申し込みが行われたそうだ。ただし、Amazonギフト券交換はスタッフが目視で確認のうえで手続きを行っているため、交換には至っていない。はてなでは「メールアドレス変更時には、変更前のメールアドレスに対しても変更通知メールを送付する」という対策をとっており、ユーザーからいち早く指摘を受けることができたとしている。
このほか、不正ログインを受けたアカウントでは氏名、郵便番号、生年月日が閲覧・変更された可能性があるほか、メールアドレスやクレジットカード番号の下4桁が閲覧された可能性がある。クレジットカード情報でカード番号の下4桁以外の部分や、有効期限などが閲覧された可能性はなく、金銭的な被害は発生していないとのこと。不正ログインを受けたアカウントについてはログイン状態を強制的に停止し、パスワードをランダムな文字列に変更したうえで、パスワードを変更するようにメールで連絡している。ただし、メールアドレスを変更された3人のユーザーに対しては、別の方法で連絡しているとのことだ。
不正なログイン試行は16日から始まり、19日18時までに約160万回行われたという。実際に不正ログインされたのは2,398アカウント。このうち、3アカウントではメールアドレスが変更され、Amazonギフト券交換の申し込みが行われたそうだ。ただし、Amazonギフト券交換はスタッフが目視で確認のうえで手続きを行っているため、交換には至っていない。はてなでは「メールアドレス変更時には、変更前のメールアドレスに対しても変更通知メールを送付する」という対策をとっており、ユーザーからいち早く指摘を受けることができたとしている。
このほか、不正ログインを受けたアカウントでは氏名、郵便番号、生年月日が閲覧・変更された可能性があるほか、メールアドレスやクレジットカード番号の下4桁が閲覧された可能性がある。クレジットカード情報でカード番号の下4桁以外の部分や、有効期限などが閲覧された可能性はなく、金銭的な被害は発生していないとのこと。不正ログインを受けたアカウントについてはログイン状態を強制的に停止し、パスワードをランダムな文字列に変更したうえで、パスワードを変更するようにメールで連絡している。ただし、メールアドレスを変更された3人のユーザーに対しては、別の方法で連絡しているとのことだ。
ちょっと試行回数が多い (スコア:1)
単純なリスト攻撃ってこともないのかな?
取得したリストのパスワードを辞書にして、IDリストxパスワードリストみたいなかけ算になってるとか?
# あと回数に対しての侵入度合いが低いのはリテラシーが高い、わけはないよなぁ...
M-FalconSky (暑いか寒い)
Re: (スコア:0)
はてなからのメールではリスト攻撃って明言してましたけどね。
メールが来るまではてなのアカウント作っていたの忘れてましたよ。
Re:ちょっと試行回数が多い (スコア:3, 興味深い)
配信されたメールでは:
このメールは、はてな全ユーザー様にお送りしています。
今回の不正アクセスは、他社サービスから流出または不正取得された
アカウント情報（IDとパスワードの組み合わせ）を流用された
「リスト型アカウントハッキング（リスト型攻撃）」である可能性が
高いと考えています。
という記載で、ストーリー中のURIにある“はてなの日記” 2014-06-20と事実上同じ案内ですね。
⇒大当たりの数人を除けば“はてなの日記” 2014-06-20を読めば用は足りる。
// 「100%正しい」と明言していないこと以外は (#2625925) の説明の蒸し返しで御免。
この流れなら言える (スコア:0)
うちもうちも、というやつですか
Re: (スコア:0)
>不正なログイン試行は16日から始まり、19日18時までに約160万回行われたという。
事実としてこれほどの大量のアタックがあった状況で、はてなをからかうのが妥当とは思えませんね。
たれこみを読む限りでは適切な対応が取られているように見えます。
Re: (スコア:0)
6Hz以上のアタックを3日間見過ごしたというのは、適切な対応だろうか。
Re: (スコア:0)
> 見過ごした
ソースある？本当にはてな側はログも何も監視してなかったの？
ログイン試行の増大はいろいろと原因が考えられるわけだけど、全く気づかず原因調査すらしてなかったというソースある？
> 適切な対応だろうか
適切であったか適切でなかったか、しきい値みたいな、なんかこうガイドラインみたいなものってあるの？
教えてちょ。
無いなら、適切か否かはただの個人による感想だよね？ツッコミ所じゃないよね？
Re: (スコア:0)
>ただの個人による感想だよね？ツッコミ所じゃないよね？
日本語でヨロシク。
Re: (スコア:0)
犯人はこのなかにいる。他社から・・・という発表をした企業のどれか
Re:この流れなら言える (スコア:1)
往年の劇場型勧善懲悪ドラマ「ハングマン」では衆目に晒された連中同士で「オレじゃないそいつがやったんだ！」と互いに他の非を断罪しあっていました。今回の事案でふと思い出した既視感。
で、結局 (スコア:0)
"他社"って具体的にどこなん？
Re:で、結局 (スコア:2, 参考になる)
ここに最近の不正アクセスの一覧が出てました。
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の件ではひどいパスワードを設定していた人が結構いたようですし、一定の割合で未だに共用パスワードをそのままにしている人がいるんでしょうね。
Re:で、結局 (スコア:1)
パスワードどころかIDやメールアドレスも同じもの使い回ししてたら特定は難しいだろ
＃サービス毎にメールアドレスとか作ってる変態なのでAC
Re: (スコア:0)
＃サービス毎にメールアドレスとか作ってる変態なのでAC
あ、おれも変態だったのかw
＃yahoo.comはyahooというアカウント名を許さないらしいです
Re: (スコア:0)
160万ID以上を持ってるところじゃないかなぁ。
かなり大手のサービスだろうね。
鴨の大群 (スコア:1)
例えば誰かが同じ欠陥のあるA社、B社、C社、D社のサーバからIDとパスワードを40万件づつゲット。
それを一つのリストにしたのかもよ。
小規模向けのシステムに穴があり、そのシステムを使っている小規模事業者だけを集中的に狙えば、メンテの行き届いていないサーバにあたる確率も高いかも。
小規模事業者なら発覚し難い可能性もあるし、たとえ発覚しても小規模事業者なら公表しない/隠ぺいする可能性が高くなる。
リストの全貌を入手できたとして「このID、パスワードはうちから漏れたものじゃないしなあ???」みたいなことになり、自分のところから漏れた実感に欠ける。
一見手間がかかるようだけど、大手を攻略するよりも簡単で安全かもよ。
Re: (スコア:0)
最後まで攻撃があったことを公表しなかったところかも(^^;
自社から漏れたのわかってて、”他社から”と発表しちゃっているところがあるかも知れないけど・・
Re: (スコア:0)
ハンロンの剃刀に従うと、自社から漏れたのがわかってなくて”他社から”と発表しちゃっているところがある可能性のほうが高い。
Re: (スコア:0)
なぜか語られない
または不正取得された
パターン
最近度々書くのだがフィッシングやマルウェアも忘れないであげて。
他社サービスから流出したIDとパスワードを使用したものとみられる不正ログイン (スコア:0)
といってはいるけど、他社サービスのIDのリストが160万件あるだけでも十分開きそうだよな。
定期的なパスワードの変更 (スコア:0)
してたら被害は減ったのかもね。
他で流出したパスワードを使われる前に変更時期が来る可能性が0じゃないって程度だけどね。
最も複数サービスで同一パスワードを使うような奴だと期待できないかもしれないか。
セキュリティリスクってサービス提供会社だけの問題じゃないようなぁと改めて思う。
Re: (スコア:0)
面白いです。
あるいはそろそろ、パスワード認証はやめるべきかもしれませんね。
Re:定期的なパスワードの変更 (スコア:1)
舌紋認証(tongue print)ですかね？
system > LICK HERE. (ディスプレイに、靴の絵が出てくる)
==========================================
投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
Re: (スコア:0)
＞定期的なパスワードの変更
＞してたら被害は減ったのかもね。
たぶん。「他で使っているパスワードと同一のものは使わないでください」が徹底できたほうが被害減ったかも。
# 今のところ被害に合ってないみたいだけど。私も徹底できてないヘタれなのでAC
Re: (スコア:0)
Re: (スコア:0)
パスワード変更でリスクが高まるわけないじゃん。
適切に変更してるぶんにはいいんですよ。
でもそんなの非現実的ってだけ。
パスワードをどうやって作るのがいいのか考えましょう (スコア:0)
せっかくなので、ここで良いパスワードの生成方法を検討したらどうですかね
ITリテラシが高そうな/.jではサービスごとにパスワードを変えてる人が多いでしょうが
どうやって生成し管理するか、面倒ですよね
個人的には今のところ、いくつかの乱数アルゴリズムを組み合わせてURLやサービス名、
ユーザー名、パスワードを設定した年月をシードにしてパスワードを生成するコードをCで書いて
使ってます。
CですがポータビリティはまあまあでLinux、Windows、ARMのAndroidで動くことを確認してます。
利点は、
・サービスごと、設定した年月ごとに異なるパスワードを生成できる
・パスワードをなくしてもシードを再構成できれば同じパスワードが再生成できる
・使っている乱数アルゴリズムと組み合わせ方が漏れなければパスワードの類推は出来ない（自分で書いたコードだから大丈夫）
てな感じでしょうか。他に良いツールやよいやり方を知ってる人がいたら開陳してください
私や皆さんの参考になりますし。
Re:パスワードをどうやって作るのがいいのか考えましょう (スコア:1)
今までにもなんどか [srad.jp] 挙げました [srad.jp]が、私は、
でやってます。
実際には、上述の結果に対し、パスワードが8文字制限だったら先頭8文字の「BW9Ofhng」を使うというのが基本ですが、アルファベットと数字の混在必須とかのルールで、先頭の文字列に数字が無かったら、切り出し位置を変えるとか、サービス名をちょっと変えて見るとか、小手先の技は使ってます。
この方法のメリットは
・サービス名はテキストデータとしてファイルに保管。ハッシュからのパスワード切り出し位置が先頭以外の場合は、切り出し位置などもメモ。パスフレーズは頭の中にあるだけなので、このテキストだけからはパスワードの入手はまず不可能。
まあ、どれかのサービスのIDとパスワードが漏れたら、そこからブルートフォースで「秘密のパスフレーズ」を見つけることは理論上は可能ですが、実質、私一人のIDのためにそこまでやる人はいないでしょう。
・公開されたアルゴリズムだけで作ってるので(パスワード生成プログラムのソースコードを無くしたとかで)パスワード生成手段が失われる心配がない。
(そのかわり、生成手順はどこかに残して置く必要があるわけですが、そういうバックアップの意味もかねて、こういうところにコメントしてたり)
というわけで、漏洩の心配はまずないこと。
最近の難点は、Androidでのパスワード生成方法が面倒なこと。Androidローカルで動くPerlアプリを作るのは面倒なので、自宅サーバにて、上記パスワード生成コードをCGIで動かして、それをhttps経由でアクセスしてます。問題ないはずなんですけど、何となく気持ち悪さがのこります。
Re: (スコア:0)
サービス名、サイトのアドレス、ID、パスワード、登録情報などはテキストファイルで管理。
ID、パスワードはWebブラウザに覚えて貰う。(可能な場合)