Webサイトのパスワード認証を狙った攻撃が大きな脅威になっています。
これらの事例のうちいくつか（あるいは全て）は、別のサイトで漏洩したIDとパスワードの一覧表を用いた「パスワードリスト攻撃（後述）」であると考えられています。パスワードリスト攻撃を含めて、パスワードを狙った攻撃が成立してしまう原因は、利用者のパスワード管理に問題がある場合が多く、攻撃を受けたWebサイト側には、直接の責任はないケースが多いと考えられます。
しかしながら、
- 大半の利用者はパスワード管理に興味がない
- パスワード認証を採用している理由は、コスト上の理由、すなわちサイト側の経済的な事情
- インターネットが「とても危険なもの」となるとネットビジネスが成り立たなくなる
ということを考えると、Webサイト側でも、パスワード認証の安全施策を講じる必要性が出て来ます。
このエントリでは、パスワードに対する攻撃手法を紹介しながら、その対策について紹介していきます。
ブルートフォースアタック(Brute force Attack)
ブルートフォースアタック（総当たり攻撃）とは、その名の示すように、パスワードを力任せの総当たりで試す方法です。下図は、ログインIDをtanakaで固定して、パスワードを4文字英小文字全てのパターンを試す場合を図示したものです。
英子文字4文字のパスワードのパターンが何通りあるかというと、26 ^ 4 = 456,976通りです。1秒間に10個のパスワードを試せたとして、この全てのパターンを試すには、約13時間で終了することになります。これは現実的な脅威ですので、通常は以下で対処をします。
現状よく使われている8文字英数字（大文字と小文字を区別）のパスワードですと、(26 + 26 + 10) ^ 8 = 218,340,105,584,896 パターンありますので、先ほどと同じ条件だと、
218,340,105,584,896 ÷ 10 ÷ 3600 ÷ 24 ÷ 365 = 692,352 年
約69万年を要することになります。平均するとこの半分で破られることになりますが、十分な強度ですね。
先に紹介したgooは、かつては4文字のパスワードを許容していたようです。現在でもその痕跡をヘルプ画面に見つけることができしました。
4. ログインパスワードの設定
gooIDに対応するログインパスワードを設定します。gooIDでご利用いただけるサービスを利用するにはgooIDとログインパスワードの両方が必要になります。ログインパスワードは英数字の４文字以上のものを使う必要があります。このパスワードは大切に保管し、忘れないようにしてください。
gooID登録・変更・削除 – gooヘルプより引用（強調は引用者）
脆弱性診断の実務では、「4文字の(短い)パスワードをつけることができる」ということを脆弱性だと指摘する事業者もありますが、本来は「たとえ短いパスワードをつけられたとしても、短いパスワードが原因で不正アクセスされたら利用者の自己責任」ということで、狭義の脆弱性ではないと考えます。
しかし、前記のような事情があるため、近年では利用者のつけるパスワードに積極的に介入するサイトが増えています。ちなみに、gooの現在のパスワードポリシーは、「8文字以上～32文字以下で、英字・数字・記号のうち、いずれか2種類の文字種を必ず混在」となっています。
辞書攻撃
ブルートフォースアタックはあまりに効率が悪く、成功確率も低いことから、「利用者がパスワードとして使いがちな単語」を辞書として登録しておき、パスワード試行する方法が考案されました。これが辞書攻撃(Dictionary Attack)です。
辞書攻撃のイメージを以下に示します。ここでは、ログインIDをtanakaで固定して、パスワードとしてpassword、qwerty、123456…など、「使いがちなパスワード」を順に試していきます。
「辞書」のサイズはさまざまでしょうが、数十から数千くらいと推測されます。ペネトレーション検査等では数千以上の「大きな辞書」を使いますが、実際の攻撃では、1つのIDでちょっと試して、だめだったら次のIDで試した方が効率的のような気がします（攻撃対象が誰でも良い場合）。
辞書攻撃の対策としては、
アカウントロックがあります。パスワードの失敗が連続して数回～十数回失敗した場合、当該のアカウントをしばらく（30分～1時間程度）ロックするというものです。
アカウントロックは有効な防御策ではありますが、利用者が「password」や「123456」などの非常に悪いパスワードをつけている場合まで防御できるわけではありません。通常、辞書攻撃は、利用頻度の高いパスワードから順に試すからです。利用者が、とても弱いパスワードを設定している場合、ロックがかかる前にパスワード試行が成功する可能性が高くなってしまいます。
リバースブルートフォースアタック
攻撃対象の利用者が誰でも良い場合、辞書攻撃に用いる辞書のサイズは小さいほうが効率が良いと書きましたが、その究極形として、「1語しかない辞書」を使う攻撃を考えます。たとえば、辞書に「password」1語だけが載っているとして、パスワードはpassword固定で、ログインIDの方法を次々に変えながらパスワード試行する形となります。このような攻撃をリバースブルートフォースアタックと呼びます（下図）。
リバースブルートフォースアタックは、日本で逮捕者が出た事件があります。
調べでは、○○容疑者は昨年１１月、「総当たり攻撃」用プログラムを使って検索した９人分のＩＤでジェット証券のＨＰに不正に接続した疑い。 同社ではパスワード（ＰＷ）入力を複数回間違えると、アクセスできなくなるが、ＰＷを適当な４けたに固定し、ＩＤだけを変える手口を使っていたため、ロックされなかった。
(2007/03/15 13:06)
産経WEB http://www.sankei.co.jp/shakai/jiken/070315/jkn070315007.htm
リンク先削除済みのため、2chより孫引き
上記にもあるように、リバースブルートフォースアタックは単純なアカウントロックが有効でないため、対策が難しくなります。
リバースブルートフォースアタックの場合、固定したパスワードは、利用頻度の高いパスワードが使われると予想されます。このため、利用者のパスワード設定時に、パスワード辞書による確認をするサイトが出てきました。従来から、文字種や文字数をチェックするサイトは珍しくありませんが、たとえこれらのポリシーを満たしたパスワードであっても、「password」や「123456」などの弱いパスワードは辞書で確認して弾いてしまうというものです。
この試みの先駆的な例としては、twitterがあります。また、最近確認したところでは、facebookやGoogleも、辞書によるパスワードチェックをしているようです。下図は、facebookのパスワード変更画面にて、「password1」というパスワードを設定しようとしてエラーになっている様子です。
「辞書にある単語はパスワードとして使えません」というエラーメッセージが表示されているので、辞書による確認をしていることが明らかです。
本来は、この種の「弱いパスワード」を避けることは利用者の責任ですが、サイト運営者側で、弱いパスワードを排除する動きが進んでいます。
ジョーアカウントへの攻撃
ユーザID(ログインID)と同じパスワードを使っているアカウントのことを俗に「ジョーアカウント（Joe account）」と呼ばれます。もっとも脆弱なパスワードと言われる一方で、ジョーアカウントという名前がついているくらいですから、一定の割合で使っている人がいると言われます。ジョーアカウントへの攻撃のイメージを下図に示します。
ジョーアカウントへの攻撃を避けるには、パスワード設定時に、ログインIDと同じパスワードをつけさせないようにチェックすることが確実です。こちらは、従来から実施しているサイトが多いですね。
パスワードリスト攻撃
冒頭にも紹介したように、現在問題となっているパスワード試行攻撃がパスワードリスト攻撃です。これは、攻撃対象とは別のサイトから得たIDとパスワードの一覧（パスワードリスト）を、別のサイトで試してみるという攻撃方法です。一定の割合で、1つのパスワードを使い回しているユーザがいることから、効率よくパスワードを破ることができると思われます。パスワードリスト攻撃の事件例については、『
eBook Japanの発表資料に見るパスワードリスト攻撃の「恐ろしい成果」と対策』に詳しく説明しましたので参照下さい。
下図は、パスワードリスト攻撃を模式的に説明したものです。左側のピンクのDBが、脆弱性をもつサイトの会員DB、右側の水色のDBが、攻撃対象の会員DBです。
攻撃者は、まず左側の脆弱なサイトをSQLインジェクション等で攻撃して、会員DBからIDとパスワードの一覧（パスワードリスト）を抜き取ります。次に攻撃者は、このパスワードリストに載っているIDとパスワードを、攻撃対象に順に試していきます。下図では、ログインID: yamadaが、パスワード qw3z として一致しているため、ログインに成功する様子を示しています。
攻撃者にとってパスワードリスト攻撃を用いる動機と背景は以下のようなものだと推測されます。
- 攻撃対象サイトには価値の高い情報や、金銭的な利益を得る手段がある
- 攻撃対象サイトにはSQLインジェクション等の脆弱性は見あたらない
- 攻撃対象と利用者が重なる「脆弱なサイト」があり、そこからIDとパスワードの一覧が入手可能
- 両サイトで、同じIDとパスワードを使っているユーザが一定確率で存在する
パスワードリスト攻撃は、2010年後半から主にオンラインゲーム業界で報告され、「リスト型アカウントハッキング」と呼ばれています（「パスワードリスト攻撃」はIPAの使っている呼称です）。以下はガンホーのリリースの引用です。
【重要】アカウントハッキングにご注意ください。
2010/11/16
既に報道されておりますが、オンラインゲームを提供している他サービス会社においてIDおよびパスワードを始めとする会員情報の一部が不正アクセスの影響により流失したとの情報を確認いたしました。
これにより、不正に入手したIDおよびパスワードのリストを利用した「リスト型アカウントハッキング」が行われる可能性がございます。
【重要】アカウントハッキングにご注意ください。 - ガンホーゲームズ－無料で遊べるオンライン遊園地！より引用（強調は引用者）
パスワードリスト攻撃は、オンラインゲーム以外にも一部攻撃が行われていたようですが、ここに来て一挙に攻撃の報告例が増えている状況です。パスワードリスト攻撃については、ここまで説明してきた「対策」が有効ではない点が悩ましいところです。
パスワードリスト攻撃の対策
冒頭で説明したように、パスワードリスト攻撃を受けて不正アクセスされた場合でも、攻撃を受けたサイトの責任とはいえません。この問題については、株式会社ラックＣＴＯ専務理事の西本氏による寄稿『
危険な「パスワード使い回し」 不正アクセス防ぐのは消費者自身』も参考になります。しかしながら、これも冒頭に説明したように、ネットの安全性が崩れると、ネット上のビジネス自体が立ち行かなくなるという事情もあるため、サイト側での防御も進んできています。以下、パスワードリスト攻撃を含むパスワードに対する攻撃への防御策について説明します。
(1)2段階認証（2要素認証）
2段階認証とは、IDとパスワードの認証に加えて、もう一つの認証手段を追加するものです。パスワードが漏洩しても、2段目の認証を求めることで、不正アクセスを防ぎます。従来からネットバンキングなどではワンタイムパスワードのトークンなどで対応している銀行がありましたが、ネットサービスでも採用するところが増えています。
以下は、Googleで2段階認証を有効にして、IDとパスワードで認証した直後の画面です。
コードを入力というプロンプトが表示されているので、ここで「確認コード」を入力します。確認コードを得る方法としては、携帯電話のキャリアメール、スマートフォン向けのアプリ、音声電話が用意されています。以下は、iPhone上で動くGoogle認証システムというアプリケーションの画面です。
6桁の数字が3つ見えていますが、上から、Googleアカウント用のもの、LastPassというパスワード管理ソフトの確認コード、Microsoft(live.com)ようのものです。この例では、「258803」をWeb画面上に入力することになります。
また、確認コードの入力欄の下に「このパソコンでは今後、コード入力ウィンドウを表示しない」というチェックボックスがありますが、これをチェックすることにより、同じブラウザからのログインであれば、確認コードなしで認証するようになります。Cookieに認証済み端末であることを保存するのでしょうね。
2段階認証を採用しているサイトの例として、以下があります。
- Google
- facebook
- ヤフー!
- Dropbox
- Microsoft (live.com)
- Apple （米国より展開中）
- twitter（テスト中）
- Evernote（対応を表明）
(2)リスクベース認証
2段階認証は、パスワードリスト攻撃だけでなく、
フィッシングなど他のパスワードに対する攻撃にも有効な強力な認証方式ですが、利用者の負担が少し大きいという課題があります。このため、2段階認証を少し緩めた方式としてリスクベース認証があります。これは、普段はパスワードのみの認証だが、通常と違う状況で認証を試みた場合、パスワード以外の情報を求めるというものです。
※17:20追記:
フィッシングに対してはリスクベース認証や2段階認証の効果は限定的ですので、「フィッシングなど」を削除し、「他のパスワードに対する攻撃」に改めました。フィッシングに対しては、中間者攻撃により、トークンを含めて利用者に入力させる攻撃が原理的に可能です。
※追記終わり
状況の変化を何で判断するかですが、一般的に以下が用いられるようです。
- 従来と異なる端末（ブラウザ)
- ISP（特に地域）
- ログインの時間帯
- ブラウザ（User-Agent）
- 不自然な行動（東京でログインした5分後に大阪でログインした等）
また、追加の情報としては以下が用いられます。
- 登録済みメールアドレスに送信したトークン（6桁程度の乱数）
- facebookの“友達当てクイズ”
- 「秘密の質問」に対する答え
- 事前に登録した「合い言葉」
個人的には、トークンがお勧めです。「友達当て」は本人にも分からない場合や、攻撃者がたまたま知っている可能性があります。「合い言葉」は、固定の文字列なので漏洩リスクがあるからです。追加情報としてトークンを使う場合、2段階認証に近い形になりますが、
- 平常時はパスワード認証と変わらないので利用者の負担が軽い
- 2段階認証と比べて、リスク判定処理が加わる分、実装の負担が重い
という違いがあります。
リスクベース認証は、近年オンラインバンキングの認証強化手段として採用する銀行が増えています。三菱東京UFJ銀行（
説明）、みずほ銀行（
記事）、りそな銀行（
説明）、ゆうちょ銀行（
説明）など主要行を始め、地銀などでも導入が進んでいるようです。
しかし、最近、リスクベース認証に用いられる「ワンタイムパスワード」が、ウイルスによって盗聴される事件が起こっているようです。
しかし、今年になり、ワンタイムを使った被害が確認された。被害に遭った複数の利用者のＰＣから、ワンタイムを盗み取る機能を持つウイルスが見つかったという。利用者の知らないうちにワンタイムが使われ、送金されていた。
朝日新聞デジタル：ネット口座不正送金、急増 使い捨てパスワードで被害もより引用
PC内にウイルスが入っているという時点で深刻な事態であり、Webアプリケーション側での被害軽減策は非常に難しいのですが、ワンタイムパスワードを受け取る端末をPCとは別にする（携帯電話など）ことや、ハードウェアトークン（ワンタイムパスワード生成器）を用いることで、被害に合いにくくすることは可能です。
(3)ログイン処理の監視
報道されている事件の多くが、パスワードの攻撃によってサーバー負荷が急増したことにより異常に気づいたとされています。このため、以下をリアルタイム監視することにより、攻撃を早期に発見して、被害を最小限に食い止められる可能性があります。
- パスワード試行の回数
- パスワード間違いの回数
- パスワード間違いの率
しかしながら、負荷を急増させたのは攻撃側が功を焦った印象もあり、「ゆっくり攻撃」した場合、なかなか攻撃に気づけないという可能性もあります。ログイン処理の監視はぜひ実施した方がよいとは思いますが、攻撃発見の決め手とはならないと考えます。
(4)ログイン履歴の確認機能
利用者が、自分のログイン履歴を確認することにより、異常がないか確認するというものです。以下はヤフー!の提供しているログイン履歴の一部です。画面のさらに右側には、アクセス元（逆引きホスト名）、認証形式（再認証、ワンタイムパスワードなど）、入力IDが続きます。
(5)パスワードの保護
万一のパスワード情報の漏洩に備えて、パスワードを安全な形で保存することも重要です。最低でもソルトつきハッシュ、できればストレッチングを加えてパスワード情報の漏洩に備えましょう。詳しくは、拙稿「
本当は怖いパスワードの話」を参照ください。
対策のまとめ
ここまで説明したパスワード認証の安全施策をいったんまとめます。
- パスワードに使える文字種と文字数を増やす
- アカウントロック
- パスワードの辞書チェック
- ジョーアカウントのチェック
- 2段階認証
- リスクベース認証
- ログイン処理の監視
- ログイン履歴の確認機能
- ソルト、ハッシュ、ストレッチングによるパスワードの保護
このフルセットを全部実現するのは中々大変そうです。2要素認証やリスクベース認証を実現する商用製品もありますが、それなりの費用が掛かります。
そこでお勧めしたいのが、外部の認証プロバイダを活用するというアイデアです。
外部認証の勧め
ここまで説明してきたように、パスワード認証の安全性を高める施策は色々あるものの、それらをフルセットで実装することはかなり大変です。つまりコストが掛かります。このため、既にこれらを実装済みの外部認証ブロバイダを利用することも､有力な対策と考えられます。
以下は、
ガンホーのログイン画面ですが、引用画像の下半分に「ID連携（OpenID）を利用する」とあるように、ガンホー独自の認証システムだけでなく、GoogleやYahoo!などの外部認証プロバイダを利用できます。
OpenID対応サイトの中には、OpenIDでもログインできるが独自のIDとパスワードの登録も必要な場合が多いのですが、ガンホーの場合はガンホーにパスワードを登録しなくてもOpenIDだけで会員登録できます。これを一歩進めて、独自のパスワード登録を捨てて、OpenIDのみに対応するという考え方もあります。すなわち、「OpenIDでログインできるサイト」には以下の3種類があることになります。
- OpenIDを使う場合でも独自のIDとパスワードの登録が必要なサイト(remember the milkなど)
- 独自のIDとパスワードもあるが、OpenIDを使う場合は、独自のIDとパスワードの登録は必要ないサイト（ガンホーなど）
- OpenIDのみに対応しており、独自のパスワード管理をしていないサイト(旧ATNDなど)
現在はまだ多くありませんが、OpenID（など外部認証）のみのサイトの場合、パスワードを独自に管理しないので、パスワード漏洩のリスクもありませんし、パスワードのハッシュ値での保存や、パスワード変更、パスワードリセットなどパスワード管理の機能も認証プロバイダにすべて任せることができます。
まとめ
パスワードに対する攻撃の急増を受けて、Webサイト側でとれる対策についてまとめました。
繰り返しますが、パスワード認証の機能設計で、本当に必須の要件は以下だけです。
- 安全なパスワードをつけられること（例: 8文字のパスワードを設定できる）
- SQLインジェクションなどの脆弱性をなくすこと（要件以前の当然の内容）
前述のように、8文字英数字のパスワードでも、利用者の工夫次第では十分安全なパスワードをつけることができます。このため、上記以外の要件はすべて「オプション」であり、これらがないから直ちに脆弱性というわけではありません。
しかしながら、「パスワード管理は利用者の責任」というタテマエだけでは、ネットの安全性を保つことはできなくなってきているのが現状です。みなさまのWebサイトの安全性強化のために、本稿で紹介したようなセキュリティ機能の強化をお勧めします。
あわせて読みたい
