不正ログイン発生時の "ユーザーの混乱や不安" を解消するための仕組み - 2023秋
ritou です。
XのTLを見ていたら、Amazonでの不正ログインについての投稿が目に入りました。
いざ被害にあってしまうと"2段階認証も意味ない"みたいな投稿をしてしまうほど、混乱してしまうものです。
混乱したり、不安になってしまったユーザーがサービスを退会してしまわないように、サービス側でできる仕組みを整理しておきましょう。
これまで何が起こったか、今どうなっているのかを確認できる仕組みを提要
これまでの啓蒙が実ったのか、被害にあって実感したユーザーが増えたからなのか、不正ログインが起こったらパスワードを変えるという意識は広まったようです。
2019年にQiitaに投稿しましたが、不正ログインが起こった際に必要なのはユーザーが正しく情報を知ることができる仕組みです。
- 何が起こったのかを知る : セキュリティイベントログ
- 今どうなっているかを知るしくみ : ログインセッションの管理
ログインでいうと「いつ、どこから、どのような認証が行われたのか」をセキュリティイベントログとして残しておくことで、どうやってやられたのかを知ることができます。
クレデンシャルを変更して今後攻撃者にログインされる可能性を減らせたとしても、攻撃者がログインした際のセッションが残っていたら意味がありません。ログインセッションを管理する機能により、攻撃者が利用したセッションが残っていないことを確認できることで安心できるでしょう。
自分が関わるMIXI Mでもこれらの機能を提供しています。
 |
 |
|---|---|
| 図1. MIXI Mのセキュリティイベントログ https://account.mixi.com/security/activities | 図2. MIXI Mのセッション管理機能 https://account.mixi.com/security/sessions |
表現についてはより細かく、どのログインによりどのログインセッションが作成されたのか、みたいなところまで視覚化できると不安解消の手助けになりそうですがまずは個別の情報を公開することが大事でしょう。
不正ログインに強い認証方式を提供
2段階認証を設定してもそれを突破されうる仕組みがあることは知られています。
AiTMという仕組みではSMS OTPや認証アプリを使っていてもフィッシングの被害にあってログインセッションを乗っ取られる可能性があります。これに対抗できる仕組みで実用的なのがパスキーによる認証です。この前書いたMIXI Mにおけるパスキー対応の記事でも説明しています。
パスキーは、認証を要求する際にサービスが指定するドメインやoriginの値が、ユーザーが実際にアクセスしている値と一致するかどうかをブラウザが介入して確認します。このため、フィッシングサイトで正規のサービスのパスキーを利用して認証を突破することは不可能です。よって、これまでの懸念であったAiTM攻撃への対策が可能です。
サービスとしては不正ログインが起こった際は、
- パスキーによる認証の利用
- 2FAでパスキー、セキュリティキーを利用
- パスワード認証の無効化
というふうに認証方式を安全なものへの誘導を行う最大のチャンスでもあります。
ドベネックの桶でしたっけ？セキュリティが弱い、水が漏れそうなところを補修していきましょう。
まとめ
不正ログイン時に必要そうな機能はここ数年であまり変わりません。
なかなかこういう機能にリソースを突っ込めない気持ちもあるかと思いますが、特にパスワード認証についてはサービスが安全な実装をしていてもユーザーのリテラシーに依存するところもありますし、何が起こるかわかりません。ユーザーを不安にさせないための仕組みを用意することで結果としてCS対応のコストも下げられたりしますので、安全な認証方式の実装と合わせて検討してみましょう。
ではまた。
Discussion