Push Authenticatorの罠

多要素認証とはPasswordのような1次要素だけで認証を完結するのではなく、EmailやSMSのような要素と組み合わせて認証を完結させる手法です。

今では米国のバイデン首相も利用を推奨している世界標準になっています。

よくある手法はSMSに時限付きのコードを送信して、そのコードを入力してコードが正しければ認証を完結させるものがあるかと思います。

この手法はユーザがコードを手入力しなければならないため、ユーザの手間が多くユーザにとってはあまり親切でないかもしれません。

入力している間に新しいコードになってまたやり直し。。。

それの繰り返しでいつまでたっても認証が完結できなくてムッとしたご経験をお持ちの方も多いのではと。

Google Authenticatorのような携帯電話にインストールされたAppに信号が送られてきて”Allow”ボタンをタップするだけで認証が完結できる手法も一般的になってきました。

これであればコードを手入力する手間が省けるので良いですよね。

しかしながらこの手法には大きな罠が隠れています。

先ずこの手法を整理してみます。細かいダイアグラムで申し訳ありません。

Push Authenticatorを利用した多要素認証の流れ

ここでサイバー犯罪者がユーザのID/Passwordを使って不正にサイトにLoginしようとするシーンを想像していみます。

前提としてサイバー犯罪者はユーザのPasswordを盗んでいることとします。

サイバー犯罪者による不正なLogin試行

Bad GuyはUserのPasswordを盗んでいるのでApplicationに1次要素であるPasswordの検証には成功します。

ApplicationはMFA SaaSに2次要素の検証を依頼します。

依頼を受けたMFA SaaSはUserのSmart Phoneに信号を送ります。

UserはSmart Phoneを見て “あれ、これなんだろう? サイトにLoginしようとした覚えは無いんだけどなぁ。まあいっかAllow押しちゃおっと。“ と。

Bad GuyはUserとしてApplicationにLoginしてしまいました。。。

ユーザの根本的な欲求に使いやすさがあると思います。セキュリティの強度がどうとかユーザにはどうでも良いですね。それはセキュリティチームの仕事なので。

いくら使い勝手の良いPush Authenticatorであっても頻繁に信号が送られてきたら”うるさいなぁ”となって、特に意に介さずにAllowを押してしまうかもしれません。

セキュリティチームはこのような罠を念頭に置くべきですね。いくらユーザに注意を促しても事故は0にはできません。