じゃらん.netとGREEでも外部サービスから流出したパスワードを使用したとみられる不正ログイン 32
ストーリー by headless
共用 部門より
共用 部門より
リクルートライフスタイルが運営する旅行予約サイト「じゃらん.net」と、グリーが運営するSNS「GREE」が不正ログインの被害にあっていたことを、両社がそれぞれ8月8日に発表した。
じゃらん.netの不正ログインは外部から取得したIDとパスワードを使用したものとみられ、2月と6月に計27,620IDが被害にあっていたという。閲覧された可能性があるのは、ユーザーの氏名、住所、電話番号、メールアドレス、予約履歴。複数のユーザーから自分のIDとパスワードでログインできないという問い合わせがあり、調査の結果不正ログインが8月5日に判明したとのこと。同社では該当するユーザーに対して個別に連絡し、パスワードの変更を依頼している(じゃらん.netからの重要なお知らせ、 INTERNET Watchの記事、 NHKニュースの記事)。
GREEでは8月5日にログイン失敗件数の急増を確認し、調査の結果7月25日から大量の不正ログイン試行が行われていてことが判明したという。不正ログインの件数は39,590件で、ユーザーの氏名、ニックネーム、携帯メールアドレス、都道府県、生年月日、性別などのプロフィール情報に加え、コイン履歴情報が閲覧された可能性があるとのこと。同社では該当するアカウントの利用を一時停止し、ユーザーにメールで連絡している。こちらも他社のサービスから流出したメールアドレスとパスワードを利用したものとみられるとのことだ(プレスリリース、 INTERNET Watchの記事、 NHKニュースの記事)。
じゃらん.netの不正ログインは外部から取得したIDとパスワードを使用したものとみられ、2月と6月に計27,620IDが被害にあっていたという。閲覧された可能性があるのは、ユーザーの氏名、住所、電話番号、メールアドレス、予約履歴。複数のユーザーから自分のIDとパスワードでログインできないという問い合わせがあり、調査の結果不正ログインが8月5日に判明したとのこと。同社では該当するユーザーに対して個別に連絡し、パスワードの変更を依頼している(じゃらん.netからの重要なお知らせ、 INTERNET Watchの記事、 NHKニュースの記事)。
GREEでは8月5日にログイン失敗件数の急増を確認し、調査の結果7月25日から大量の不正ログイン試行が行われていてことが判明したという。不正ログインの件数は39,590件で、ユーザーの氏名、ニックネーム、携帯メールアドレス、都道府県、生年月日、性別などのプロフィール情報に加え、コイン履歴情報が閲覧された可能性があるとのこと。同社では該当するアカウントの利用を一時停止し、ユーザーにメールで連絡している。こちらも他社のサービスから流出したメールアドレスとパスワードを利用したものとみられるとのことだ(プレスリリース、 INTERNET Watchの記事、 NHKニュースの記事)。
CAPCHA (スコア:1)
# yes, fly. no, fry.
もうありますよ (スコア:0)
ヤフーメール（PCブラウザ版）は、不正ログイン騒動の前から、そうでしたよ。
IDとPW入力画面 → ひらがなCAPCHA画面 → IDとPW入力画面（ようやくログインできる）
普通はIDとPW入力と同一画面にCAPCHA入力もあるのでしょうが、CAPCHAを下手にあとづけしたせいで、2回もIDとPWを入力させられるというクソ仕様となっております。
Re: (スコア:0)
ログインシールを設定するとなるの？
Re: (スコア:0)
IPアドレスや試行回数等から怪しいと判断したアクセスに対してのみ表示するとかよくあるからなんとも言えない
Re: (スコア:0)
普通はパスワードがわかってなくて総当たり攻撃するから、それの対策としては有効。
今回のものはパスワードはすでにわかってるから、あとはそれが正しいか(他のサービスで使えるか)確認するだけのもの。
人間の手でやっても十分得るものは大きい。
Captcha導入した方がそりゃセキュリティは向上するけど、代わりに通常ログインに手間がかかる。
Captchaあるだけでもけっこうな障壁になるからなぁ。
ID / パスワードでの認証に限界が (スコア:1)
もう、いっそのこと公開鍵認証に移行するとか、は難しいんだろうなぁ。
例えば、どこかが認証サービスを行って、他のサイトは Twitter の OAuth みたいなかたちで認証するみたいな。
Re:ID / パスワードでの認証に限界が (スコア:1)
OpenIDみたいなシステムで同じユーザーIDとメールアドレスとパスワードを使い回す理由がわからん
覚えることが1つで便利だろうけど、1つ流失したら全部おしまい
Re:ID / パスワードでの認証に限界が (スコア:2)
逆に、同じパスワード入力したら
ブラウザがサイト毎に、個別のパスワードを
自動生成、送信してくれる規格とか出来ればいいと思う。
元パスワードが同じなら、同じサイトには
必ず同じパスワードが生成されて、
元パスワードの逆算は不可で。
各サイトは生成されたパスワードしかわからないから、
漏れても被害がそのサイトのみに限定される。
ワイタイムならぬ、ワンサイトパスワー
Re:ID / パスワードでの認証に限界が (スコア:2)
それに近いのは Mozilla Persona ?
個人的には、ちゃんとOpen ID connectしてくれれば、それでいいんだけどな。
# というかIDプロバイダを固定はしたくない。いざってときがあるし、より安全なのに切り替えがきかないとな
# いまだと、Google/Microsoftで2要素有効がかなりマシかな...
## VeriSignのVIPはもうちょっとがんばって
M-FalconSky (暑いか寒い)
Re:ID / パスワードでの認証に限界が (スコア:1)
私は手作業(自作スクリプト) [srad.jp]でそれをやってます。
っていうものです。
既存のアルゴリズムを使ってるので、Perlの動く環境さえあればどこでもパスワードを再生でき、「プログラムがないからパスワードを再生できない」なんてことにハマらないのが強み。
文字種が限られた場合にどうするかというのが最大の難点ですかね。
上述slashdot.jppasswordの場合、「数字だけ4桁のサイト」に使おうとしたら、「BW9OfhngQYgyEu03CLLUNQ」から数字だけを抜き出すと「903」で一桁足りない。
今は「桁数が足りない場合は繰り返す」というルールで「9039」を使うという統一ルールで運用してますが、運悪く数字が一文字も含まれないパスワードが生成されたらどうしよう、という感じ。
あと、逆に「数字、アルファベット、記号それぞれ1文字以上使うこと」みたいなパスワード文字種に制限をかけてる場合にも使えないのも困ったり。
Re: (スコア:0)
たしか、ドメイン名のハッシュをとって、そのハッシュとパスワードから、ドメインごとに違うパスワードをを生成してくれる拡張機能があったはず。
しかし、攻撃者がパスワードとドメイン名を知っていた場合、元のパスワードが復元できないようにするには、いろいろテクニックが要りそうなもんだけど。
Re: (スコア:0)
それだと結局パスワード管理ツールを入れる方がいいな。
サイトとパスワードを関連させてしまうのは脆弱性になるので、
パスワード管理ツールでパスワードをランダムに生成させて、
親パスワードで一括管理した方が手間は同じでより安全。
Re:ID / パスワードでの認証に限界が (スコア:1)
> サイトとパスワードを関連させてしまうのは脆弱性になるので、
そもそもパスワードを分けてる人は、今のままで問題無い。
パスワードを分けろと言っても聞かない人の場合の話です。
"同じパスワード"というのは最悪の場合の話で、実際は違うパスワード使います。
動作のイメージは、メールのAPOPが一番近いかな。
（ハッシュに使う値はサーバ毎に固定。
認証時だけでなく、パスワード登録時も同様にハッシュ値のみ送るのが異なる）
規格化できてブラウザが対応すれば、ユーザの手間は０。
パスワード管理ツールとはレイヤーが違うので併用も可能。
Re: (スコア:0)
×流失
○流出
# 「～せざろうえない」と同じくらい気になる
Re: (スコア:0)
何か不味い事が起きたときには、そのサイト・アプリ・デバイスを切り離せばおしまい。
Re: (スコア:0)
ようはパスワードを使い回すのもOpenIDでどこでもログインできるようにするのも、
使い回しのパスワード または OpenIDのパスワード が漏れたら全部漏れることに変わりないってことかと。
何かまずいこと、っていうのに気づければいいですけどね・・・気づいた時にはOpenIDで連携してるすべてのサービスがやられてるわけですから・・・
Re:ID / パスワードでの認証に限界が (スコア:1)
だけど今度は、「秘密鍵のパスフレーズを空文字列にする馬鹿が、マルウェアで秘密鍵ファイルを盗まれる」というストーリーが見えてしまった。
秘密鍵は複数のサイトで共通にしておいてもセキュリティ上直ぐに問題じゃないからいいんだけど、空パスフレーズの秘密鍵を盗まれて全部やられるという。
秘密鍵盗まれちゃ駄目だろ。
公開鍵方式暗号って、興味のない人には複雑すぎる仕組みの気がする。
Re: (スコア:0)
otpauthってのがあるからそれが普及すればよくなるかも。
Google認証システムみたいなやつね。
もしかして、被害者は皆同じ？ (スコア:0)
いろんなサービスで同じ、またはほとんど同じパスワードを使いまわしている人たちが、被害に合っているのだとしたら、
ほっといてもいいんじゃない？自業自得/自己責任でしょ。
Re:もしかして、被害者は皆同じ？ (スコア:5, すばらしい洞察)
> いろんなサービスで同じ、またはほとんど同じパスワードを使いまわしている人たちが、被害に合っているのだとしたら、
> ほっといてもいいんじゃない？自業自得/自己責任でしょ。
視点に拠る。
これだけ多くのサービスが社会一般に普及している現状を鑑みると、IDとパスワードの組み合わせを把握しきれなくなるのは当然のこと。それなのにパスワードを紙に書くな、定期的にパスワードを変えろと一般消費者に要求したりする。適切なログイン方法を提供できないサービス運営側なり、コンピュータサイエンスに責任がないとはいえないだろう。
Re: (スコア:0)
使い回せば芋づる式、ブラウザに保存すれば平文保存で丸見えですしね
Re:もしかして、被害者は皆同じ？ (スコア:1)
利用者の使いまわしは「いろんなサービス」ではなく 2か所でもだめでしょう。
「いろんなサービス」は攻撃者が試しているので、1度でも同じパスワードを使ってしまったことがある人が対象になりえますね。
欲しい情報にもよりますが、すべてのサービスでログイン可能な人を探しているわけではないと思うので。
1度くらいならあるって人であれば対象人数は結構増えるかもしれません。
登録したことすら忘れちゃったサービスなども。
# yes, fly. no, fry.
一次流出元はどこ？ (スコア:0)
まず一発目に平文でパスワードを流出させたところがあるとおもうんだけど、
それはどこなんだろう？結局はそこから芋づるみたいな。
今回のじゃらんにせよGREEにせよ、平文で流出させたアホのとばっちりを
受けてしまった感は否めないなあ。
Re: (スコア:0)
平文だったとは限らないと思いますけど
Re:一次流出元はどこ？ (スコア:1)
Re: (スコア:0)
そりゃハッシュ関数通ってたりしたらそのままじゃ使えないけど、辞書攻撃だとかレインボーテーブルだとか幾らでも平文を得る方法はあるわけで…
どちらにせよ、最初にお漏らししたアホが悪い事には変わりありませんが
Re: (スコア:0)
Yahooが有力で、次いでNAVER、OCNって感じかな
俺はサービス毎に全てパスを使い分けてるからなんの問題もないな (スコア:0)
Re:俺はサービス毎に全てパスを使い分けてるからなんの問題もないな (スコア:1)
ローテクだなあ。俺はちゃんとExcelで管理してるぜ。
Re: (スコア:0)
古いなぁ。俺は流行のEvernoteで管理してるぜ。
Re: (スコア:0)
パスワード集のテキストファイルをDropboxに入れてる人は見たことがある
そろそろ流出元を特定しろよ (スコア:0)
これだけ各社が同じように不正ログインされてるんだから、各社が協力して情報交換し、不正ログインされたユーザーの共通点を調べれば流出元の業者がどこか特定できるんじゃないの？
流出したアカウントで、ほとんど全部に共通なサービスがあったらそこが流出元だ。
そこを塞がないと問題は解決しないよ。
あとは全部のサービスでパスワードを変えるかだな。