どんなサイトにも二要素認証は必須である。特にクレジットカードを入力させられる際に二要素認証が求められないとやだなーと思う。そういうとき、一回きりのチケット購入等の場合にはコンビニ支払いとかにしてしまう。
Webサイトの開発において二要素認証必須にするのは非常にハードルが高いことはわかる。そこらへんを個人開発で非常に協力にサポートしてくれるFirebaseのAuthenticationにおいてもいろんな罠があることが最近読んだ記事に書かれていた。
中身は難しいので本業じゃない人が読むのは辛いと思う。
7つの罠について要約すると以下の通り。
- 自分が使ってほしくないと思っていてもFirebaseが標準で提供している機能があり、それをユーザが勝手に使えてしまう
- 対策: 勝手に使ったかどうかを検証する必要がある
- ユーザが勝手に自分を削除できる
- 対策: 勝手に消えたとき不整合が起きないように頑張る
- 他人のメールアドレスを登録して乗っ取り、フィッシングメールを出せる
- 対策: メールの認証が通ってるか逐一確認する
- 他人のメールアドレスですでにアプリに登録されてるか確認ができる
- 対策: 高頻度な確認をさせないように使用回数を制限する
- メールアドレス、パスワードへのブルートフォース攻撃が可能
- 対策: メールアドレス、パスワードの認証をやらない(Googleアカウント認証とかにする)
- 脆弱なパスワードを許容してしまう
- 対策: 堅牢なパスワードを設定するように制限する
- ユーザがどの認証で通ってきたかちゃんと考慮してない
こういうのは公式のドキュメント化されずらい。開発者自身で「こういった攻撃はありうるか?」を考えてテストする必要がある。もちろんドキュメントを全部読んだ上で。
どんな開発をするときも結局必要となる知識で、公式だから利用者が多いからと考慮してないと後々大きな問題として出てくる可能性が高い。実は大きな問題だと認識されているが、各開発者がめっちゃ常に悩んでいるとか、こっそり直してる最中であるとか公式を問い詰めると出てくる場合もある。
認証周りは本当に地獄だ。かなり難しい。OAuth2.0の仕様とかは読んでいると混乱するし、認証と認可は違うという話は普通の人にはほとんど通じない。
そういった難しさを知っているからこそ、普通のメールアドレス+パスワードの認証がいかにダメなのかを理解している。もちろんOAuth2.0の認証・認可のデータの保存方法も同様にかなり難しいが。そこらへんは質問箱がやらかした件が参考になる。
ともあれ一般に二要素認証を使ってないサイトはあまり使わないほうがよい、という流れに世の中がなると良いなと思う。曲がりなりにも実装しているサイトはセキュリティ意識が高く、必要であると認識できる開発力があることの証左であるからだ。