Evernoteも不正アクセスを受ける 37
ストーリー by headless
侵入 部門より
侵入 部門より
Evernoteは同社のシステムがサイバー攻撃を受け、侵入者がユーザー情報にアクセスしたことを明らかにした(Evernote日本語版ブログの記事、
CNET Japanの記事、
本家/.)。
侵入者がアクセスしたユーザー情報にはユーザー名、登録したメールアドレス、暗号化されたパスワードなどが含まれる。Evernoteでは強固なパスワード暗号化を使用しているが、万全を期すため全ユーザーのパスワードを再設定することにしたという。なお、ユーザーが保存したコンテンツにアクセスされた形跡はなく、有償ユーザーの決済情報にアクセスされた形跡もないとしている。詳細についてはEvernote日本語版ブログに掲載されているほか、すべてのユーザーに同内容のメールが送信されるとのことだ。
侵入者がアクセスしたユーザー情報にはユーザー名、登録したメールアドレス、暗号化されたパスワードなどが含まれる。Evernoteでは強固なパスワード暗号化を使用しているが、万全を期すため全ユーザーのパスワードを再設定することにしたという。なお、ユーザーが保存したコンテンツにアクセスされた形跡はなく、有償ユーザーの決済情報にアクセスされた形跡もないとしている。詳細についてはEvernote日本語版ブログに掲載されているほか、すべてのユーザーに同内容のメールが送信されるとのことだ。
まいなびにゅーすによると (スコア:0)
saltをつかったハッシュで暗号してたってことだから
リセットするって事は
saltとその計算式まで漏れたって事かねぇ？
Re:まいなびにゅーすによると (スコア:2)
ネタ元のEvernoteブログには
調査からは、アクセスを試みた人物（またはグループ）が、ユーザ名・Evernote アカウントに登録されたメールアドレス・暗号化されたパスワード等を含む Evernote のユーザ情報へアクセスすることに成功したことが明らかになっております。ただし、パスワード情報にアクセスはされたものの、Evernote で管理している全てのパスワードは一方向暗号化（技術的に言うとハッシュ化・ソルト処理）により保護されています。
としか載ってないですよね．
『今すぐ突破されることはないにしても，安全な方に倒しました』という意味でのリセットと理解して，好感を持ったんですが．
リセットするって事は
saltとその計算式まで漏れたって事かねぇ？
っていうほど 公式発表が疑わしい点があったので？
Re: (スコア:0)
今 MD5 の両方向変換用辞書がオンライン上にあって一方向のハッシュ化だから安全ともえいない感じになってます。
もっとも MD5 を使っていると限らないけどハッシュが何でも要は同じなので。
Re: (スコア:0)
saltはレインボーテーブルを使えなくするためのもので漏れること前提だと思っていたが。
というかパスワードが漏れたのにその他の秘密情報だけ都合よくもれないなんてことありうるの?
Re:まいなびにゅーすによると (スコア:1)
情報は分割されて保存されており漏れたのはそのうち一つだけだった、ってのは
普通にありそうだが。
Re:まいなびにゅーすによると (スコア:1)
理屈で言えばありえるでしょうが、今回はどうかといえば当事者以外わからんでしょう。
で、当事者の一方が漏れてないって言っているのだから、信じるか信じないかの二択では。二者択一っても半々の割合でもなし。
個人的には侵入経緯とか知りたいところ。
「昨今急増している大規模なサービスに対する不正アクセスを鑑みますと」なんて言ってることろからすると、根っこは同じなのかなぁ。
Re:まいなびにゅーすによると (スコア:1)
saltはレインボーテーブルを使えなくするためのもので漏れること前提だと思っていたが。
その通りです。
なので、ソルトの値とハッシュ値から元のパスワードに戻すためにはブルートフォースしか無いです。
ハッシュ値の計算に関して、具体的な記述を見つけていませんが、ブルートフォースによる解析の最短記録は、パスワード長が 8 文字までの NTLM ハッシュ（パスワードの Unicode 表記に対して MD4）を、GPU 25 個を使うクラスタで 5 時間半、という記録はあります。
8文字の全パスワードを5時間半で解析するコンピュータクラスタが登場 - CNET [cnet.com]
仮に、Evernote が使っていたハッシュ値の計算が MD4 だったとして（多分、SHA-1 辺りかな、という勝手な想像はあるけど）、８文字までのパスワードであれば、同様のクラスタで 5 時間半で解読可能、という事になります。
但し、これは、ある一つのハッシュ値に対する解読時間なので、たくさんのユーザの中で、自分のパスワードが解析されるまでの時間はもっと長くなるでしょう。また、当然ですが、9 文字のパスワードであれば、100 倍弱の時間がかかります。10 文字であれば、9000 倍以上の時間がかかります。さらに、ハッシュ値の計算でストレッチングをしてれば、ストレッチングの回数分だけ時間がかかります。
ということで、元のパスワードの長さ次第で緊急度が全然違ってきます。10 文字以上のパスワードであれば、辞書攻撃で破られるような、よほど単純なもので無い限り、数日中に解析される事は天文学的に低い確率になります。
Re: (スコア:0)
5000万ユーザのハッシュされた状態のパスワードが盗まれた。
メールアドレスとかの個人情報も。
saltがわかってれば、あとは、5000万ユーザの中から、パスワードが「password」になってる人はどれ？
って探せば短時間で見つけられると思う。
辞書を元にして、大量の単語をsaltを元にハッシュ化して、それらを5000万のリストから探してもいい。
全員ではないにしろ、少なくないパスワードが漏えいしたと考えていいと思う。
だから、全ユーザのパスワードをリセットする必要が出てしまった。
問題はこれで収まらない。
メールアドレスも漏れていることから、パスワードを使いまわしている人の他のサービスのアカウントも盗まれたかもしれない。
Re:まいなびにゅーすによると (スコア:2)
saltがわかってれば、あとは、5000万ユーザの中から、パスワードが「password」になってる人はどれ？ って探せば短時間で見つけられると思う。
それなら、ハッシュ値すら要らない。アカウント情報だけあれば、正面切って「password」というパスワードを試せば良いだけ。さすがに、同じクライアントから試せば、サーバサイドでロックアウトも可能だから、Botnet を使わないとうまくいかない、とか、効率は悪いだろうけど、いくつか見つけられるでしょう。そんなパスワードを付けているユーザなら、パスワードリセットがあっても、放置するか、結局同じパスワードを設定するか（今回の件で、同じパスワードが設定できるかどうかは知りませんが、いくつかのパスワード変更を繰り返せば、以前のパスワードを設定するのは可能だろうし）。
ソルト付きのハッシュ値でパスワード情報を保存しているのであれば、たとえそれらが漏れても、エンドユーザが安全なパスワードを設定していれば、充分に時間稼ぎはできる。安易なパスワードを付けたユーザを守る方法なんて、無いと思うなぁ。100 回のストレッチングで、パスワード長を１文字長くしたのと同じ効果は得られるけど、それだって、辞書攻撃で破られるようなパスワードには焼け石に水。
#もう、パスワード長は最低 10 文字で良いと思う今日この頃。
Re: (スコア:0)
saltは漏れた場合を想定して振るものだし、出来合いのレインボーテーブルに対しては効果があるでしょう。
とはいえオフライン攻撃のブルートフォースアタックに対しては時間稼ぎにしかならないので、安全側に倒すなら全パスワードをリセットするほか無いと思います。
パスワードの寿命 (スコア:0)
永遠はないよ……。ハッキング(or クラッキング)されるまでが寿命。
短ければ短いほどセキュアとはいえ、運用上は長い方がUIとしてはよい。
Re: (スコア:0)
バカな自分に教えて欲しいのだけど、パスワードを定期的に変えるのって、本当にセキュリティ上有効なんでしょか。
Re:パスワードの寿命 (スコア:5, 参考になる)
パスワードの定期的変更に関する徳丸の意見まとめ - 徳丸浩のtumblr [tokumaru.org]
実際、パスワードはどれくらいの頻度で変えるべきですか？ : ライフハッカー［日本版］ [lifehacker.jp]
Re: (スコア:0)
鰯の頭 [tokumaru.org]。
Re: (スコア:0)
漏洩～行使の間に潜伏期間があるケースでは助けになることもあるでしょうし、
知らず知らず相乗りされてる状態でもシャットアウトできる可能性が出てきますね。
もっと計算機科学的な根拠があるんだと思いますけど、まったく無効と言い切るのは難しそう。
「永遠に変わらないパスと一度変えうるパスのどっちがセキュア？」
という質問からなんとなく帰納的に納得できる人だけ実施すればよいのではないかと。
Re: (スコア:0)
つまり生体認証とか頭おかしいと思っている人は実施すべきであると
Re: (スコア:0)
「パスワードの変更は有効か？」という問いに「無効と言い切るのは難しそう」と答えただけです。
生体認証など変えられないパスワードに関する話はそこに含んでませんよ。
変えることに何か明確なデメリットを思い当たっているなら、変更すべきでないのはすでに明確でしょう。
「変えるべきか変えないべきか」の俎上にそれをのせること自体がナンセンスです。
Re: (スコア:0)
生体認証はパスワードの代わりになるものではなく、IDの代わりになる物だろ
現在のパスワード的な使い方をする実装が誤り
Re: (スコア:0)
効果がゼロではないとしても、パスワードを定期的変更するにもコストが掛かるわけで、そのコストに見合うだけの効果があるの?
覚えてられないから付箋でパスワード貼り付けますたとかなったら目も当てられない。
Re:パスワードの寿命 (スコア:1)
> 効果がゼロではないとしても、パスワードを定期的変更するにもコストが掛かるわけで、そのコストに見合うだけの効果があるの?
メリットとデメリットが相殺されない以上、
「パスワードを定期的に変更する運用が全面的に正しい」って考えも、
「パスワードを定期的に変更しない運用が全面的に正しい」って考えも、
両方とも正しくなく、システムや利用状況や利用者のリテラシーを踏まえて検討すべき課題であり、
抽象的なケースのままで結論を求めようとする思考が一番危険。
Re: (スコア:0)
パスワードを定期変更するのは有効なのかって質問なのに、なんでパスワードを永遠に変更しないって話にすり替えてるの?
Re:パスワードの寿命 (スコア:1)
帰納的にってあるから別ににすり替えでもないだろ
Re: (スコア:0)
定期的なパスワード変更が有効な事例とそうでない事例があるというのが真実だと思います。具体的な事例を言ってもらわないと、定期的パスワード変更が適用が有効かどうか、あるいは、別のよりより対策があるかは見えてこないと思います。
というか、それを事例を想定し、分析することこそがセキュリティの要かなと思います。分析もしないで、何も考えず定義的なパスワード変更すればよいということはありえない。思いつく限り、定期的なパスワード変更に関連する事例としては、つぎのようなものが考えられます。
1) 定期的にプロジェクトに人の参入/退出
定期的
Re: (スコア:0)
> 退出時に複数のアカウント無効手続きが忘れられる
> 不正検知システムを用意した上で、それすらすり抜けた
そんなダメダメな前提まで考えてたらなんだって言えるということですね。情報量0。
Re: (スコア:0)
>そんなダメダメな前提まで考えてたらなんだって言えるということですね。情報量0。
そこで、思考停止をしてよいシステムの管理者なら情報量0でしょうね。
実際、小規模で業務影響の少ないシステムでは考えなくて良い話だと思います。
結局のところ、システム要件・セキュリティ要件によりけりです。
何か事例に対して、議論をすることはできるのですが、
具体的な事例なしにセキュリティで実のある議論をするのは難しいのです。
Re: (スコア:0)
> 不正検知システムを用意した上で、それすらすり抜けた
は程度問題としても
> 退出時に複数のアカウント無効手続きが忘れられる
忘れられるのは駄目でしょう。
アカウント管理ができていないレベルではパスワード定期変更以前の問題だと思います。
Re: (スコア:0)
>> 退出時に複数のアカウント無効手続きが忘れられる
忘れられるのは駄目でしょう。
>アカウント管理ができていないレベルではパスワード定期変更以前の問題だと思います。
すみません。うまく表現できていませんでした。
実際、具体的な事例を挙げてみると、それは定期パスワード変更が
根本の問題解決となるのではなく、実は別の対策で対応できる・・・
といった話があるだろうという話の例です。
| 定期的なパスワード変更が有効な事例とそうでない事例があるというのが真実だと思います。
| 具体的な事例を言ってもらわないと、定期的パスワード変更が適用が有効かどうか、
| あるいは、別のよりより対策があるかは見えてこないと思います。
Re: (スコア:0)
家の鍵を定期的に変えないよりは新しい鍵に変えたほうが泥棒に入られにくい。
ということでは（窓割って入る、ドア破って、壁壊して入る・・・まあいろいろとある手段のうち、玄関から鍵で入るのを防ぐという）。
セキュリティの技術もクラッキングの技術も毎秒向上してるわけですし。
その時々で○○しないよりはマシってのが、この手の話ですから。
Re: (スコア:0)
個人的にはログイン履歴(成功失敗とも)が確認できて、かつ失敗のログをユーザに通知する方が有効期間を設けるより意味があるんじゃないかと思います。
定期的に変更だと例えばパスワードAとB(足りなければCも)を入れ替えて終わりとかやって結局無意味だったりということも間違いなくある。
それと気になるのがネットバンキングなどサーバ側の対応。
連続失敗制限とかやってるのかな？ 使ってるサービスでそういう注意書きを見たことが無い。
同一端末(IPアドレスとCookieの複合とか)からのログイン試行を10回/時までに制限するとか。
そういう対策なしにパスワードの変更を強要するのはお門違いと感じる。
# Googleのアカウントアクティビティは失敗まではわからなかったかな？
Re: (スコア:0)
それと気になるのがネットバンキングなどサーバ側の対応。
連続失敗制限とかやってるのかな？ 使ってるサービスでそういう注意書きを見たことが無い。
私の使っている銀行だと3回失敗でしばらくログインできなくなり、アクセス失敗したよ、ってメールが届きます。
Re: (スコア:0)
3回でサービス停止とかはやってるみたいだけど（例：みずほ）それよりも、やばくなってサービス廃止しちゃうところもあるようです。どことは言いませんが、三菱東京UFJ
ブルートフォースが成立するという前提があって始めて意味を持つ対策 (スコア:0)
攻撃すべき正解候補が現実的な時間内に枯渇してしまうという状況下で、攻撃が成功しないうちに正解候補を初期値にリセットすることで、強度を一定に保ちましょうって話だもん。
すべてのパスワードは確率の問題(=攻撃済みパスワード数/文字種パスワード長)でしか強度を保証しないから、それが時間の経過と共に無視できないほど急激に低下する、言ってみればセキュリティ的に既に詰んでる状況下でシステム運用しなきゃいけない、ある意味無理ゲー状態の想定で始めて意味を持つ対策ね。
パスワードを最大8文字しか受け付けてくれないとか、パスワード何回間
リセットスマスタ！って言っても、現実的には (スコア:0)
旧パスワードでログインして、即新パスワード設定画面になるだけですから、即時ログインしちゃうとやりたい放題の気が。
同じパスワードを新パスワードとして設定できませんが、別のパスワードに設定して、再度元パスワードに設定することもできました。
※リセットさんを希望します
Re:リセットスマスタ！って言っても、現実的には (スコア:1)
ウェブからログインして登録したメールアドレスへワンタイムパスワード発行とかじゃないと先にやられたらおしまいですよね
Re: (スコア:0)
だから、暗号化されたパスワードをクラックできる期待値までに変更してね、
つまり、今すぐパスワード変えるのが有効よ
と言ってるわけだが。
ついにクラウドにも (スコア:0)
中国のスモッグ汚染が…。
さすがに平文化したままでは保存してなかったか。 (スコア:0)
ユーザー名は違えてもあちこちで同じパスワード使ってるのでどこかで漏れ出すと一気に詰むなぁ。