Webサービスにおけるログイン機能の仕様とセキュリティ観点 - Flatt Security Blog
わからん。何がわからんかというと、ほぼ大半の要件は主要なフレームワーク又はフレームワークに一部追記する程度で対策に記載されている内容又はそれ以上のレベルで対応できるわけだが、その上での課題がわからない
読んだ。
入門者向けとしてはある程度基礎的な事が書かれているので、特段それは良いと思うのだけども、ただ、全般的に基本的な実装、極論言えば、主要なフレームワークの認証又は認証プラグインを利用する事や、セキュリティにかかわる設定を施す事で特段の影響はない程度の話ではないかと。
ざっくり見た感じだと、多少実装方法にはよるものの、パターンAの観点１に記載されている「処理時間に差異がある」以外は網羅されているように感じる。
この部分については、確かに一般的なフレームワークでの実装では、そもそも該当するアカウントが存在しない場合は、存在しないという結果を返すため、意図的に存在しない場合に疑似的な処理を実行するように組まないと、確かに処理時間の差異は発生すると思われる。
その上、多くのフレームワークでは、認証機構をそのまま利用する場合、つまり、単純にサービスとして利用する場合は、認証処理（IDとハッシュ文字列を用いた照合）自体を直接呼び出す事自体がないものもあるため、その点についての実装には一考が必要だろうとは思う。
ただ、この点については現実的にどの程度の脅威なのかわからない。
というのも、計算時間によりレスポンスタイムの差を仮に機械的なアクセスにより判断するとする。
通常、レスポンスタイムに与える影響は、アクセス回線や経路の関係性、当該処理を行うノードの状況等と合わせて、実装方法による差異、実装内容により処理工程による差異というものが影響を与えると推測される。
例えば、認証処理に仮に当該アカウントが存在しない場合も、ダミーデータを用いた処理をかませる事で、機械的なアクセスをされた場合に、アカウントの有無に対するレスポンスタイムの差がでないようにという配慮をしたとして、それが、どの程度の差になるのだろうか。
というか、おそらくその差異が当該処理により差がでているものであると判断する為には、少なくとも複数回のアクセスが必要（なぜならば、当該処理における中央値がわからない）なのだが、この場合、そもそも別な対策によりブロックされるべきではないのだろうか。
仮に、その点は置いておくとしても、サービスが余程の潤沢なリソース下で稼働していない限りは、個人的には認証処理のレスポンスタイムによる差でアカウントの有無を判断するという事は難しいのでは？
一般的にこの手の攻撃はチップや装置に対する攻撃時には利用される。
処理時間や処理時のノイズにより採用しているアルゴリズムを推測したり、処理手法を推測することで攻撃手法の選択を行う等がそれにあたる。
ただ、Webサービスの場合、それらとは違い、直接的に応答を得られるわけではないので、応答時間というものは比較的判断要素としては限定的なものとなる。
手元で適当なレンタルサーバ上で単純な認証処理単体の処理時間を検証したところ、概ね30ミリ秒から70ミリ秒程度の時間を要した。
揺らぎが大きいのはレンタルサーバだからだと思われるが、まぁ、こんなものではないかと思う。クラウドサーバでLaravel使ってもレスポンスタイムはそれなりに揺らぎがあるものなので。
当然この時間はアカウントが存在しない場合には処理されない事になるので、この差が平均的に掛かる事から、その程度の差異がレスポンスタイムに生じれば当該アカウント、つまりそのID（例えばメールアドレス）の存在について判断できるとはいえる。
が、話はそう単純ではない。
昨今Webサービスを作るにあたり、何もフレームワークを使わないという事は、リスク以前に手間がかかる。
少なくとも多くの場合、何かしらのフレームワークを使うだろう。
PHPであればLaravelのように、何かしら使う。
で、この場合、データをどのように管理するのかというアーキテクチャーの選択にもよるが、この処理時間、つまり30ミリ秒～70ミリ秒の揺らぎは、おそらく全体に占める割合としては比較的割合が少ないと思われる。
なぜならば、フレームワークは処理を起動するだけでオーバーヘッドが発生し、そのオーバーヘッド自体にも処理の都度一定の揺らぎが生じるため、例えば通常時に200ミリ秒程度で応答を返しているとしても、150ミリ秒程度から250ミリ秒程度の幅が生じることとなり、この揺らぎに重ねて前述の認証処理の差異が加わることとなる。
当然、最大幅はより大きな誤差となるわけだが、処理の都度どの程度の揺らぎが発生するのかというのは状況により異なるので、一定のサンプルを集めない事には判断できない。
認証処理が行われても210ミリ秒（共通処理180ミリ秒＋認証処理30ミリ秒）という事もあれば、認証処理が行われなくても230ミリ秒（共通処理230ミリ秒＋認証処理0ミリ秒）というケースもありうる。
値にすれば1割も処理時間が増加しているではないか！と思うだろうが、揺らぎがそれ以上に生じている状況下では、そもそもその差は揺らぎに吸収されて判断されづらくなるわけです。
その上、前述のとおり判断のためには一定数のサンプルを集める必要があるが、そのためには一定のアクセスを繰り返し、そのシステム自体の性能を推測した上で、どの程度の誤差を閾値として採用するかという判断が必要になるので、そちらのほうがおそらくハードルは高いのではないかと思う。
そもそもどのIDが存在するのかしないのかというのはわからない状況からスタートするので、100回程度のアクセスではおそらく判断できないのではないかと思われる。
通常のフレームワークであればブルートフォース対策として一定期間中の連続ログインに対する対策は含まれているので、100回試行する前におそらくブロックされる。
仮にIPを変更してチャレンジしてくるとしても、どの程度のサンプルが集まればそれが判断できるのかというのはちょっとわからない。
暇になったら一度試してみてもいいかなと思わなくもないが、それでも個人的には回線の状態やインフラ側の事情による影響の方が大きいので、ノイズが大きすぎてあまりその推測は役にたたないのではないかと考えなくもない。
いや、考える意味がないと言っているわけではないし、対応する意味がないと言っているわけでもない。
認証時の応答として、結果に左右されずに一定のものを返す、特に攻撃者に対して推測可能な情報を与えないというのは基本的な対策なので、それは当然として考えれば、やる必要性はあると考える。
ただ、この記事を読んで、なるほどそういったことも考えるべきなのか、という程度のレベルの人であれば、おそらくここで書かれていることの意味は理解できないだろうし、その人に対して、とりあえずフレームワークを使え、以外の余地はないのではないかと思う。
なぜならば、例えばIDaaSを使ったとしても、相手方の実装がそれを適切に対応していることを確認しているとは思えないからだ。
例えば、IDaaSを使ったとして本当にアカウントの存在の有無によりレスポンスタイムに差はないのか、であったり、例えば、ブルートフォースアタックに対してはフロントで対策を講じる必要があるのか、それともバックエンド又は実装フレームワークで対応してくれているのかという事の理解も必要だが、本当にそのような事を考えられるのだろうか。
いや、リクエスト課金されるんだから、全部投げんな糞という議論をされると、結局ID管理を別な場所で行うことになるわけで、意味が分からんことになるように、ちゃんとなぜそのサービスを選択したのかという事が理解できないと、結局事故るのではないかと思うのだが。
個人的にはIDaaSの利用は否定しないが、適切知識や実装ができないと、その状況下でも結局穴ができることに変わりはないので、同じではないのか、と思わなくもない。
