パスワードの定期的変更について徳丸さんに聞いてみた(1)

高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、パスワードの定期的変更問題についてお話を伺います。徳丸さん、よろしくお願いします。

徳丸: 徳丸です。よろしくお願いします。

高橋: まず、お伺いしたいことですが、パスワードを定期的に変更すべしという根拠には、どのようなものがあるのでしょうか?

徳丸: 大きく分けて2つの理由が挙げられていると思います。一つは、パスワードを定期的に変更すると、パスワードを破って侵入する攻撃の予防になるというもの、すなわち事前の予防策です。もう一つは、パスワードが漏洩した際に、被害を軽減できるというもので、事後の緩和策ということですね。

高橋: もう少し詳しくお願いします。

徳丸: まず、﹁事前﹂の方ですが、オンライン攻撃とオフライン攻撃があります。

高橋: オンライン攻撃とはどのようなものでしょうか?

徳丸: オンライン攻撃は、ネット経由でパスワードを順に試すことですね。文字通り片っ端から順に試すブルートフォース攻撃、辞書攻撃、リバースブルートフォース攻撃、パスワードリスト攻撃などがあります。このうち、ブルートフォース攻撃はオンラインでは現実的ではありません。

高橋: なぜでしょうか?コンピュータが高速になったので大量のパスワードが試せるようになったという記事を読みましたが。

徳丸: オンラインのパスワード攻撃の速度は、攻撃側端末の性能ではなく、攻撃対象サイトの性能に依存します。しょぼいサイトなら1秒間に1個のパスワードしか試せないが、高負荷に耐えるサイトでは、1秒間に1万個のパスワードを試せるかもしれません。

高橋: ﹁バルス﹂のようなものでしょうか?

徳丸: そうそう、バルス…先日のラピュタの放映では、Twitterは14万3199バルス/秒を達成したそうですね…同様にパスワードも秒間10万個試せる…とは限らないのですよ

高橋: なぜでしょうか?

徳丸: 対策しているからですよ。Twitterは、なりすましの価値の高いサイトなので、さまざまななりすまし対策︵参考︶をとっています。私は試していませんが、パスワード試行も対策していると思います。

高橋: もう少し具体的に教えてください。

徳丸: 例えば、同じIDで続けてパスワードを間違えると、そのアカウントを一時的にロックする﹁アカウントロック﹂という方法があります。10回連続してパスワードを間違えると30分ロックするという具合です。10万個のパスワードを試すには約5000時間掛かりますから、約208日掛かります。

高橋: 208日攻撃され続けると怖いですね。

徳丸: さすがにその前に遮断するでしょう。それと、10万個のパスワードは辞書攻撃としては十分ですが、ブルートフォース︵総当たり︶としてはまったく不十分です。

高橋: …と、おっしゃいますと?

徳丸: twitterは最短6文字のパスワードがつけられますが、パスワードの文字種は制限していないので、6文字に限定しても、95^6 = 約7350億通りのパスワードがあり得ます。先のアカウントロックがある条件で総当たりするには、約420万年掛かります。

高橋: なら、辞書攻撃で攻めてくるのでは?

徳丸: twitterは独自の辞書をもっていて﹁password﹂のようなありきたりの単語はパスワードに設定することができないので、辞書攻撃は難しいでしょう。

高橋: そうですか…しかし、パスワードの定期的変更から話がそれていませんか?

徳丸: そうでした。辞書攻撃が短期間に終わるのであれば、パスワードを変更する前に攻撃が終わるので、定期的変更は意味がありませんね。

高橋: では、パスワードの定期的変更の期間、例えば3ヶ月をまたいで攻撃する場合はどうでしょうか?

徳丸: いくらなんでも、サイト側で攻撃を検知して、遮断などの処置をとって欲しいですね。あるいは当該のユーザーに﹁パスワードの辞書攻撃が来ているので対処して欲しい﹂と連絡してくれてもいいでしょう。

高橋: その場合もパスワードを変更するのではないですか?

徳丸: そうです。しかし、﹁定期的に﹂変更するのではなく、﹁攻撃されている﹂ことをトリガーとして変更するので、全然違います。辞書攻撃が来ていることが分かれば、辞書に載っていない、長い文字列をパスワードに設定すれば、辞書攻撃は怖くありません。

高橋: サイト側で対策を取っていない場合、パスワードの定期的変更は意味がありませんか?

徳丸: それが、意味がないのですよ。パスワードを定期的に変更すべしという人の中には、パスワードを変更すると﹁ひらりと﹂パスワード攻撃を避けることができるという人がいますが、それは違います。

高橋: 違うのですか?

徳丸: はい。攻撃側も防御側も相手の手の内がわからない状態なので、﹁たまたま攻撃をかわせる﹂可能性もあれば、﹁パスワードを変更したら、たまたま攻撃に掛かってしまう﹂場合もあります。闇夜にむやみやたらに鉄砲を撃ってくるのを避ける状況を想像してみて下さい。むやみによけても、よけた先で弾に当たるかもしれません。

高橋: でも、しらみつぶしに撃ってくる相手はよけたくなりますね。

徳丸: そうです。なので、﹁しらみつぶし﹂攻撃には、アカウントロックその他の施策で対策することが重要です。また、利用者側でも、辞書に載っているような単語を避けて、長く複雑なパスワードをつければ辞書攻撃は回避できます。

高橋: 辞書攻撃以外の方法に対してはどうでしょうか?

徳丸: リバースブルートフォース攻撃に対しても、パスワードの定期的変更は意味がないですね。リバースブルートフォース攻撃はパスワードを固定してIDの方を変えていくので、1人のIDに対しては攻撃は1度だけです。1つのパスワードを試し終わったら次のパスワードに進みますが、辞書攻撃と同じ理由で、パスワードを定期的に変更しても効果がありません。リバースブルートフォース攻撃も、辞書攻撃同様、パスワードを複雑なものにすることで防げます。

高橋: パスワードリスト攻撃はどうでしょうか?

徳丸: パスワードリスト攻撃に対しては、他のサイトとは別のパスワードをつけることが必要十分な対策で、パスワードを定期的に変更する必要はありません。

高橋: わかりました。次に、オフライン攻撃について教えて下さい。

徳丸: パスワードのオフライン攻撃というのは、保護された形式のパスワードファイルが外部に漏れて、それを解読する行為を指します。

高橋: パスワードの保護というと、暗号化でしょうか?

徳丸: 暗号化する場合もありますが、パスワードの場合は、ハッシュを用いることが多いですね。

高橋: ハッシュというと、MD5とかSHA-1のことですか?

徳丸: そうそう。パスワードの保護用に開発されたハッシュ関数もありますが、MD5やSHA-1のような汎用的なハッシュ関数を用いる場合も多いですね。

高橋: ハッシュでパスワードを保存すると、元に戻せないから保護できるというのは分かりますが、サイト運営者がパスワードを照合する時に困りませんか?

徳丸: パスワード照合の場合も、ユーザが入力したパスワードからハッシュ値を求めて、会員DBに保存されたパスワードハッシュ値と比較します。ハッシュ値同士で照合する訳です。

高橋: そうか、ハッシュなら絶対に元のパスワードに戻される心配はありませんね!

徳丸: それが、そうでもないのです。

高橋: なぜでしょうか?わかった! MD5の脆弱性で元に戻せるのですね!なら、脆弱なハッシュ関数を使わなければよいのでは?

徳丸: そうではありません。MD5には一部弱点が見つかっていますが、ハッシュ値から元の文字列︵平文︶が戻せるほどには弱くなって︵危殆化して︶はいません。

高橋: それではなぜパスワードが分かるのでしょうか?

徳丸: 総当たり︵ブルートフォース︶攻撃を使います。パスワードの文字種や文字数は限られているので、総当たりでハッシュ値を求めていけば、いつかはハッシュ値が一致するパスワードが見つかります。

高橋: でも、お高い︵時間が掛かる︶んでしょう?

徳丸: そうでもないのです。まず、レインボーテーブルと言って予め全てのハッシュ値を計算したものを圧縮したファイルを用いて高速にハッシュ値から元パスワードを算出する方法が考案されました。

高橋: レインボーテーブルは聞いたことがあります。

徳丸: 次に、GPUというグラフィック用のプロセッサが高速演算できることに着目して、ハッシュ値の高速演算をするようになりました。これは約2年前の記事ですが、当時でも1秒間にMD5ハッシュが20億回計算できるとしています。

高橋: ﹁また上野宣か﹂で有名な上野さんの記事ですね。

徳丸: 8桁英数字のパスワードのパターンは218兆通りですから、1秒間に20億回計算できると、約11万秒、すなわち30時間ほどですべてのパターンを試行できることになりますね。

高橋: 丸1日ちょっとですか。これだとパスワードを毎日変更しないと駄目ですね。

徳丸: 今ならもっと高速だから、毎日パスワードを変更しても駄目でしょう。

高橋: 困りましたね。どうすればいいですか?

徳丸: ソルトとストレッチングというものを使います。

高橋: ソルトとはなんでしょうか?

徳丸: ソルトは、ハッシュ値を計算する前のパスワードにつけてやる短い文字列です。パスワードに﹁塩をまぶす﹂ようなニュアンスからソルト(salt)と命名されました。ソルトはユーザ毎に異なるように、乱数等を使って生成します。

高橋: ソルトがあると、なぜ良いのでしょうか?

徳丸: LinkedInの事例で説明しましょう。2012年の6月にLinkedInから約650万件のパスワードが流出しました。パスワードはSHA-1ハッシュの形で保存されていましたが、約1週間で540万件の元パスワードを﹁解読﹂したという人物が現れました。

5.4M #linkedin passwords cracked after one week. Only 1M remain... @hacktalkblog @CrackMeIfYouCan @Sophos_News #leakedin
— Jeremi Gosney (@jmgosney) June 14, 2012

高橋: 1週間で540万件というと、ものすごく高速ですね。

徳丸: そうでもないのです。単純なハッシュだと、パスワードが同じであれば全ての利用者でハッシュ値も同じになりますから、利用者が何人でも総当たりの手間は変わりません。

高橋: ソルトがあると違うのですか?

徳丸: はい。ソルトは利用者毎に異なるので、ハッシュ値を求める前に、どのソルトを使うか決めなければなりません。つまり、1人ずつハッシュ値を求めないといけないので、LinkedInの場合で言うと、手間が650万倍になります。

高橋: 650万倍!それはすごいですね!

徳丸: LinkedInが大規模なサイトだからで、利用者が100人のサイトだったら、100倍止まりですが。

高橋: 1日が100日に増えるだけだと、パスワードを定期的に変更したくなりませんか?

徳丸: いや、それもあるのですが、LinkedInの場合でも全員が安心という訳ではありません。最初の1人は1週間程度で解読されてしまうわけですから。

高橋: オバマ大統領もLinkedInに登録されているようですから、そういう著名人は真っ先に解読されそうですね。

徳丸: そうなんです。このため、ストレッチングという方法を使う場合があります。

高橋: ストレッチングとは何でしょうか?

徳丸: ストレッチングとは、ハッシュ計算を何回も繰り返すことです。例えば1万回ハッシュ値の計算を繰り返したものをパスワードのハッシュ値として保存します。

高橋: 1万回も計算するとCPU資源を浪費しそうですね。

徳丸: そうです。しかし、攻撃側も1万倍遅くなりますから、1日強で解析できたものが1万日、すなわち約27年かかることになります。

高橋: 27年掛かれば大丈夫そうですが、攻撃側に対抗策はないのですか?

徳丸: あります。ハッシュ値の計算は並列処理が容易なので、マシンの台数を27倍にすれば、1年で計算が終わることになります。

高橋: 1年で解読されてしまったら、パスワードを定期的に変更する動機になりますね。

徳丸: オバマ大統領ならともかく、あなたのパスワードを知るためにモンスターマシンを1年間占有させるかという疑問がありますが、心配なら利用者側にも対抗策がありますよ。

高橋: 心配なので、ぜひ教えてください!

徳丸: パスワードの桁数を増やすことです。パスワードを1桁増やすとパスワードのパターン数は60倍～90倍程度になりますから、8桁のパスワードではなく12桁のパスワードを使うようにすれば、ハッシュの解読の時間は1千万倍以上掛かります。

高橋: それは良いことを教わりました。今後は、全てのサイトで12桁以上のパスワードをつけます!

徳丸: でも、サイト側の制限で、今でも8桁パスワードまでというところが多いんですけどね。

高橋: …既に長くなりましたので、本日はこれくらいにして、ここまでのまとめをいただけますか?

徳丸: はい。結局﹁事前の予防策﹂として、オンライン攻撃に対しては﹁パスワードの定期的変更﹂は意味がないということです。オフライン攻撃に対しては、サイト側のパスワードハッシュでの保存やソルト、ストレッチングなどの施策、利用者側での長いパスワードの設定で十分な強度が得られますが、パスワードの保存方法は利用者には分からないので、不安は残りますね。

高橋: では、パスワードの定期的変更に意味があるということでしょうか?

徳丸: そうとは限りません。オフライン攻撃が行われているという状況は、既にパスワードのハッシュ値が洩れていると言うことですから、事後対処という意味もあります。既に長くなりましので、﹁事後の緩和策﹂としてのパスワード定期的変更と、結局パスワードは定期的に変更しないといけないのかどうかについては、次回に説明することにしましょうか。

高橋: そうですね。それでは、皆様、次回をお楽しみにぃ!徳丸さん、ありがとうございました～


※注: ここに登場する人物はすべて架空の人物です。文責は徳丸浩にあります。

続きはこちら: パスワードの定期的変更について徳丸さんに聞いてみた(2)