ディスクユニオンからいろいろ漏れた件
漏れました
ディスクユニオンによる顧客情報漏洩、私も喰らってた。
いろんな意味でメチャクチャショックだったので、その記録を残しておこうと思う。
現象
steam
Steamから強制ログアウトされる
ログインを試みるも失敗
パスワード再発行を試みるも、メールアドレスがすでに変更されていて、届かない
最終的にアカウントサポートから復旧してもらう
二段階認証アプリを紹介されたが、独自アプリで見つかりにくいやつだった
マイクロソフト
マイクロソフトアカウントへのログイン試行が報告される
実際には二段階認証があったため大丈夫だった
原因
ディスクユニオンによる顧客情報の漏洩。悪いことに、住所やメールアドレス、電話番号だけでなく、平文のパスワードがそのまま漏洩した。
対策
使い回しパスワードの全変更
後始末と考察
ここからが本題。
なぜパスワードを使い回すのか？
パスワードはほかのサイトと違うものを使いましょう、とよく教育される。それはそうなのだが、同時にパスワードは忘れやすいものでもある。
この矛盾を回避するために、ユーザー側では、共通の文字列をベースにして前後にサイト固有のワードを入れたり（ユーザー側によるソルト方式）、ブラウザ自身に記憶させたり、パスワードマネージャを利用したりと、対策を取る。
しかし、その対策がすべてうまくいくわけではない。むしろ、システムに任せた対策がうまくいかないと考えるからこそ、自分が覚えられるパスワードを使おうとして、使い回してしまう面の方が強いのではないか。
人間の記憶力は、伸ばせと言って伸ばせるものでもない。システムに頼ることはできるが、システムに頼れない場合があることを考えると、低い方のレベルに合わせるしかなくなる。
必要なときにログインできない不安
大規模サイトではこの現象が多いように思う。セキュリティ対応の観点からセッションの有効期間を短めに維持しているため、いますぐ必要なときにログアウトされていて、よりにもよってパスワードが見つからない。
たとえば、ホテルにチェックインするために予約サイトにアカウント登録する。当日は電車が遅れてチェックイン時刻ギリギリだと思うが、いつだったか覚えていない。そんなとき、サイトにログインしていますぐ調べたくなるだろう。
たとえば、人気バンドのライブで本人確認が必要なため、電子チケットを見せなければいけない。そんなとき、ログアウトされていたらどうするか？
パスワードが見つからない不安を解消するために、人間の記憶力という脆弱なものに頼らなければいけない。そして覚えやすいパスワードに逃げてゆく。
デバイスまたぎ問題
パスワードマネージャーは、システムに統合されていないと意味がない。ChromeにはChromeの、FirefoxにはFirefoxのパスワードマネージャーがある現状では、ブラウザをまたぐだけでパスワードマネージャーの意味が消滅する。
ましてそこに、PC/スマホのデバイスまたぎが発生したらどうなるだろうか。デバイスをまたぐとパスワードは入れ直しになる。スマホのキーボードは小さく、パソコンで登録したサイトのパスワードをポチポチ入れ直すのも、なかなかの苦痛。
結果として、実際に利用するタイミングはスマホしか持っていない時なのに、パソコンでアカウント登録したウェブサービスのログインを求められてしまい、ログインできず窮する事態が発生する。
Macのすごいところは、これを標準で解決しているところにある。MacとiPhoneであれば同じキーチェーンを使える。デバイスまたぎは自然と解決されるし、ユーザーにとってはPCをMacに変えるだけでOKなのだ。
パスワード記録されない問題
長い間使っていればいるほど、こちらの方が深刻になる。
ブラウザのパスワードマネージャーはそこそこ優秀で、生成したり入力したパスワードを記録してくれる。しかし、メールアドレスとパスワードがセットでないと、うまく記録されないのだ。
多くのパスワード変更画面は、パスワードしか入力できない。パスワード変更直後は、旧パスワードに紐付いたパスワードマネージャー情報と、アカウントIDを持たないパスワード情報のふたつが別々に保管される。
これを統合しなおすには、ログアウト後、覚えているうちに新パスワードでログインするという機械的作業が必要だ。しかもその際に、パスワードマネージャーがパスワードの変更を検知してくれないとダメだ。前述のようにブラウザをまたいでパスワードを管理している場合、「パスワードマネージャーがある方」で更新しなければいけないのだ。
パスワード変更時にログアウトしていれば、そのパスワードを試す機会がすぐにやってくる。しかし人間とは弱いものなので、パスワードを変更して、それで満足してしまう。いつかもう一度ログインするときには、変更したことすら忘れている。
複数アカウントを一元管理できない問題
実は私はブラウザを使い分けている。これは特定サービスの複数アカウントを、ログイン・ログアウトを繰り返しながらひとつのブラウザで使い回すのが辛いためだ。
一度複数アカウントをひとつのブラウザで使い回す（ログインするたびにアカウントを使い分ける）ことを試したのだが、そのサイトは90日ごとにパスワードを変更させるタイプのものだった。で、アカウントAのパスワードを変更したときはよかったものの、アカウントBのパスワードを変更したときに反映してくれなかった。
これによりログインミスが大量発生し、そのたびパスワードリセットを繰り返す地獄のような運用が発生してしまった。これじゃあ実質ワンタイムパスワードじゃないか……。
そのサービス、今でもパスワードをうまく覚えてくれない。本当に困ったものだ。
登録したサービスを覚えていない問題
これもかなり深刻。
そもそもどのサービスに登録したかを覚えていなければ、パスワードの使い回しを調べる以前の問題だ。有名サイトをしらみつぶしにログイン試行するわけにもいかず、乏しい記憶との戦いを強いられる。
ブラウザのパスワードマネージャーには、パスワードを登録したサイトが記録されている。そこから追うことはできるが、これも複数ブラウザでの戦いになる。もちろん、その機能が入る以前の履歴は追えないし、もう存在しないコンピューターで入力したものは追跡不可能。
最終的には、会員登録完了のメールを全部追う必要がある。こんなときメールを送らずにアカウント登録させるサービスがあると、もう絶望しかない……
iPhoneアプリのパスワードが記録されない問題
パスワード変更作業をしている中でぶち当たった大きな問題がこれ。iPhoneアプリ内で入力するパスワードは、パスワードマネージャーに記録されないのだ。
解決策を調べて拍子抜けしたのだが、Safariでログインすれば記録される、という。
さすがにこれはアホすぎないか？ と思いつつ、皮肉にもAppleにロックインされている人間は、この手順から逃れられない。
こういうちょっとした不信が積み重なった結果、パスワードを生成するという聖杯を飲み込めなくなる。
二段階認証という福音
しかし、「パスワードは漏れるもの」と考えているウェブサービスがある。それらはパスワードだけでのログインを認めず、別の手段での認証を追加してくれる。
SMSやメールで送られてくるワンタイムパスワードを入力して、はじめてログインされるため、ワンタイムパスワードがその瞬間に漏れなければセキュリティは担保される。
とはいえ、パスワードを変更したりしている中で、二段階認証があるサービスとないサービスがあることに気づく。IT系のサービスは真っ先に対応していて、メール・SMS以外にTOTPにも対応してくれている。QRコードをアプリに登録すると、一定時間ごとに更新されるパスワードがアプリに表示されるため、それを第二パスワードとして入力すればログインできる。
TOTPは素晴らしいシステムである。通知もうっとうしくないし、インターネット接続がない状況でも耐えられる。TOTPアプリのアカウント管理さえもっと明確ならば。
……会社用のgmailでログインしたGoogle Authenticatorに、個人で使用しているTOTP認証を紐付けてしまい、退職によってTOTPが使えなくなったことがある。あれに気づいたときの絶望はひどい。TOTPはアプリごと、個人用と会社用でしっかり分けるべき。
イープラスとぴあは二段階認証をつけてくれ
マジで対応してくれ。
先述したように、このサービスはリアル現場で使う機会が非常に多いし、チケット購入は一万円近い金額が軽く吹っ飛ぶ。
すぐログインできなければいけないという不安と、簡単にログインさせてはいけないというリスクが競合するところだ。マジでお願いします。
どちらもアプリ・ウェブがあるので、パスワード記録されない問題にもハマりやすい。
二段階認証の罠
二段階認証も万能ではない。特に「ワンタイムパスワードがその瞬間に漏れなければ」という部分が大問題になる。
メール経由の二段階認証で、かつ攻撃者がメールにログイン可能な場合、ワンタイムパスワードはその場で利用されている可能性が高い。
また、SMS経由の二段階認証では、SMSサービスがダウンするとログインができなくなる。
小さな回避策
上記は技術的な話だが、実際には細かな対策を複数個積み重ねることで、予期せぬ漏洩をカバーできるように思う。もちろんパスワード使い回しはNGな上で、だが。
メールアドレスを使い分ける
gmailだと、メールアドレスの末尾に+をつけることで無限にエイリアスが生成できる。問題は、古いアプリケーションだと+つきのメールアドレスを入力規約ではじく可能性があること。
私の場合、有料のメールボックスサービスを契約したので、そこで物理的にアカウントを増やしていた。
ログインIDをメールアドレスにしない
これはウェブサービス側での仕様に救われた部分があるが、要するに単純な総当たりではログインできないというわけだ。
スマホでもログインする
パソコンでしかログインしていないからこそ、パスワードがスマホで使えない不安に駆られてしまうのだ。それならば、登録時にスマホでもログインを済ませて、パスワードを記録させてしまえばいい。
iPhoneなら、Safariでログインする。
ソーシャルログイン
ソーシャルログインであればパスワードが不要なことがある。そして、万一連携先からソーシャルログイン情報が漏れても、そもそもそれ自体が各サイトごとに発行されるものであるため、必然的に被害は小さい。
それでも、漏れたものは取り戻せない
ここまでやってもセキュリティは万全とは言えない。というか、住所も電話番号も氏名も漏洩してしまったら、それだけで実施可能な攻撃はいろいろあるだろう。
代引き詐欺、出会い系サイトへの大量登録、いたずら電話……。これらは、一度漏洩した限り、甘んじて受け続けるしかない。
逆に考えると、こういうことだ。
住所も電話番号も氏名もウェブのパスワードも漏洩しているとき、どれだけの情報を安全に保管することができるだろうか？
情報セキュリティとはそういうことだと思う。誰も信用できないとき、どこまで信用できるか、ということだ。
もしも平文が漏れていなかったら
追記だけど、ここまで大変なことになったのは、平文パスワードが漏れたためだ。
ほとんどのウェブサイトはハッシュ関数で非可逆の暗号化を施し、そもそもどんなパスワードが入っているか、運営もわからないようになっている。
ハッシュ関数は、どんな入力を入れても決まった文字数の値を返す性質がある。
たとえばmd5関数なら、"hoge"という文字を"c59548c3c576228486a1f0037eb16a1b" に変換してくれる。これはどの環境でも同じ結果になる。
echo hoge | md5sum
c59548c3c576228486a1f0037eb16a1b -だから、パスワード"hoge"をデータベースに持たず、"c595…" だけを持っておけばいい。
ただし、変換後の文字列に一致するべつの入力が存在（衝突）しないかは注意が必要だ。単純な例として出したmd5関数では、ごくわずかに衝突の可能性がある。ハッシュ化する際には衝突の可能性と実行速度など、複数の要素をしっかり考えること。特に一度暗号化してしまうと、元のパスワードがわからなくなってしまうため、やり直しはきかない（厳密には、旧環境のハッシュ比較が成功したときに、入力を新環境で再度ハッシュすれば可能だが……）。
また上に書いたように、ハッシュ関数はどの環境でも同じ結果になるため、「hogeがc595…になる」という変換表を大量蓄積することで、変換前のパスワードを類推することができる。これをレインボーテーブル攻撃という。
これへの対策は、変換前文字列の前後に特定の文字列（ソルト）を挿入すること。ソルトがバレなければレインボーテーブルは通用しない。
……ここまで考えると、漏れていたパスワードがハッシュ化されていたら、攻撃者は一手間必要になり、直接大量アタックをかけることはできなかったはず。