パスワードクラックの手口(1)

f:id:boost-up:20171205232241j:plain

前回までで、パスワード管理の難しさについて一通り確認したところで、その攻撃の手口について見ていきたいと思います。

今回は、最も古典的でありながら、コンピュータの歴史と共に進化し続ける攻撃方法、総当たり攻撃について見てみます。 総当たり攻撃はブルートフォースアタックとも呼ばれます。

総当たり攻撃の考え方

この攻撃はパスワード入力画面という正面玄関から、文字通り総当たりでトライしますので、原理的にはいつか必ず正しいパスワードを突き止めることができます。 コンピュータ、特にCPUの進化に伴い、日々攻撃力を増している攻撃方法です。

総当たり攻撃では、最初にパスワードの複雑性を決めますが、攻撃者の立場からするとここがある意味成否の分かれ目になります。

例えば、パスワードが数字だけからなる場合、一桁の候補は10通りですので、8桁の攻撃を行うためには最大で10の8乗、つまり1億通りの組み合わせをトライすればすみます。

一方、パスワードが半角英数からなると仮定すると一桁の候補は26×2+10=62通りになりますので、8桁の攻撃を行うためには最大で約218兆通りの組み合わせをトライする必要が出てきます。 単純な比較で言っても218,000倍の時間がかかるわけです。※桁数が断定出来ない場合は8桁までのすべての桁数もトライしますので、実際の組み合わせはもう少し多くなります。

攻撃におけるもう一つのポイントは総当たりの順序です。これも攻撃成功までの時間を左右する大きな要素です。 基本的な方法としては、昇順攻撃または降順攻撃があります。例えばあるパスワードが昇順で数えて8割の位置にあるとき、降順では2割の位置に存在することになりますので、最初の判断によって攻撃成功までの時間が大きく変わってきます。

総当たり攻撃の派生形である辞書攻撃

一方、現実にはパスワードを何らかのソーシャルな情報(例えば、趣味嗜好に関する情報、出身、生年月日などに関する情報もしくはそれらを結合した文字列)に関わらせて設定したり、誰しもが考えそうな文字列(passwordやqwertyなど)、あるいは何らかの固有名詞をパスワードに設定しているケースもあるでしょう。

このようなパスワードに対しては、パスワード候補を列挙した辞書に基づいて攻撃を行う辞書攻撃という方法が存在します。

辞書攻撃も広い意味では優先順位を持った総当たり攻撃と考えることができますので、ここでは総当たり攻撃に分類しておきます。

辞書攻撃は、対象となるパスワードの使用者が特定されており、その人物のソーシャル情報やその人物の"癖"などが分かっている場合には特に有効な攻撃方法となります。 では、このような総当たり攻撃を防ぐにはどうしたらいいでしょうか?または、総当たり攻撃に耐えるにはどのようなパスワードが望ましいのでしょうか?

安全なパスワードとは?

繰り返しになりますが、「理論上、総当たり攻撃はいつか必ず正解に辿り着きます」ので絶対安全なパスワードというものは存在し得ません。 そのため、パスワードセキュリティの観点からは、「そのパスワードによって保護されている情報が価値を持つ時間内においては特定できない可能性が極めて高い複雑さを持つパスワード」が望ましいパスワードということになります。

例えば、ある人のWebメールに不正アクセスするのに100年かかるようであれば、普通は100年後にはその人はこの世を去っているはずであり、攻撃が成功した頃にはそこに記載された情報のほとんどが価値を持たなくなっていると考えられます。 さらに、100年後にそのWebメールサービスが存在するかどうかも分かりませんし、攻撃するコンピュータも100年稼働し続けることが必要です。 この場合、パスワードは総当たり攻撃に耐えることが出来る(可能性が極めて高い)と言えるでしょう。

サーバ運営者の義務

他方で、総当たり攻撃を防ぐための対策は利用者ではなくWebサイト運営者がなすべき義務の一つでもあります。 例えば、パスワードのリトライ回数に制限を設けたり、同一のアクセス元からのアクセス頻度に制限を設けるなどの対策により、Webサイトに対する総当たり攻撃は極めて非効率なものとなります。 ※この対策は総当たり攻撃だけでなく、DoS(DDoS)攻撃に対する対策としても重要です。

また、パスワードの検証に意図的に時間をかけるような対策も有効です。パスワード検証に1回に1秒余計にかけるようにするだけで、利用者の利便性への影響を最小限にしつつ、一定時間内の攻撃回数を極端に減らすことができます。

BtoBなどで、利用者が特定可能かつ限定的なWebサービスであればアクセスを許可するIPアドレスをホワイトボックスで指定する方法や、アクセス元PCなどのクライアントを認証し、認証されていないクライアントからのアクセスを拒否する実装も選択肢となります。

ただしこの場合は、許可されたアクセス元に悪意がないことを前提としますので、万が一悪意がある者が利用者となった場合を考えると、Webサービスの内容によっては不十分なこともあるでしょう。