"心当たりの無いメール" の分類と必要な機能
こんばんは、ritouです。
世の中には、"心当たりのないメール"、より正確に言うと "迷惑メールではなく第3者のアクションにより自分に送られてきたものと思われるメール" ってやつが存在するわけで、年末にこれを取り上げます。
まず、この "心当たりのないメール" に関する課題から挙げていきましょう。
心当たりのないメールに関する課題
- どうしようもない : (未登録だから/登録済みだけどログインしても)何もできない
- 誘導されたフォームでたくさんの個人情報を求めらてツラい : 新規登録よりもたくさん情報とるやんけ
- こんな簡単にリンク踏んでいいんか？ : そのサービスやそことID連携してるサービスを装ったフィッシングかもしれない
もう今年は終わりなので来年はこの辺りなんとかしたいですね
心当たりのないメールを受け取るケースとは
まずは、メールを受け取るケースを分類したいところです。
- (1) 新しい登録や共有、招待
- サービス新規登録 : 他人が自身のメアドを誤って入力した結果、自分に届いた
- メールで共有、招待 : 第3者のメアドを誤って入力した結果、自分に届いた、共有/招待機能を用いた攻撃のための入力
- (2) なりすまし?悪用?
- メアドの状態をチェック : サービスにこのメアドが登録済みかどうかを判定するために試行された
- メールを用いた認証 : 誰かが私のメアドを入力した？と言うことは、ログインしようとしている...?
- 見知らぬ履歴 : 誰かが自分のログインセッションで何かしている...?
- （3） 過去に第３者が使っていたメールアドレスへの通知 : 知らないサービスに登録済みになっていた？
- (4) システムのバグ : 「これってもしかして...」「私たちのメアド...」「入れ替わってる〜！？」
- (5) そもそもフィッシング
結構有りますね。
サービスが用意しておくべき機能
(1) 新しい登録や共有、招待 : 無視/破棄で問題ないやつ(無効化できるとより良さそう)
やや気持ち悪いは悪いですが、自分にきたメールによる処理が完了しなかったら問題にはならない場合、無視やメールの破棄で問題ないでしょう。
やや気持ち悪いをすっきりさせたかったり、めっちゃ何通もくるみたいな場合は 問い合わせからの無効化、サービス側判断によるメアド入力環境単位での利用制限などがあっても良さそうです。
(2) なりすまし?悪用?
この辺りは結構大変ですね。未登録状態のサービスからの不審な通知は(1)と同様でしょう。
登録済みの状態から誰かから何かされている気配を感じた場合は、サービス上で(もしくは問い合わせでもいいですが)行動履歴を確認できる機能を用意し、そこに誘導できていることが望ましいでしょう。(参考:ユーザー認証の緊急事態に備えて提供しておきたい、セッション管理とセキュリティイベントログについて - Qiita)
（3） 過去に第３者が使っていたメールアドレスへの通知
「心当たりのない場合は...」からの問い合わせの時に個人情報を要求されて...とかよく聞きますが、それが必要なのはここかなと思います。
これはもうCS対応レベルの話になるので、本人確認が必要で済んでいるアカウントの場合は問い合わせたユーザーが別人であることを検証した上で対象アカウントのメールアドレスの登録解除、別ルートでの登録情報変更や凍結処理などを行う必要がありそうです。
この辺りをストレスなくこなせるようになるためには、問い合わせを行う人は
- eKYC結果の流通
- SSI(Self Sovereign Identity)の考えに基づいた属性情報連携
などを用いて情報提供のハードルを下げることが必要でしょう。
よく考えると地味にめんどくさい部分ですが、まだまだ伸び代はありそうな気がしています。
(4) システムのバグ
これはまぁ...
(5) そもそもフィッシング
これは、内容どうこうよりもついてるリンクなどを踏むUXがダメでしょって話です。(参考:フィッシング対策視点から考えるメールやSMS通知のあり方 - r-weblife)
個人的に最近はSMSやメールの中身にリンクなどを貼るな！って言う考えになってきたので、来年こそ 通知や今回のような通知からのフィードバックについて、リンクを貼らない踏まないようなやり方を探究していきたい ところです。
まずは
- 通知は必要最低限の情報とし、詳細はサービスにログインして通知履歴を確認しろみたいな流れ
- ログインできないけど問い合わせたい場合などに、通知単位の識別子を持たせて記載しておくことも必要そう
と言うあたりを最適化できないかなーというあたりを考え中です。
まとめ
心当たりのないメールを受けとるケースについて分類し、サービスは何を用意しておく必要があるのかを整理しました。
- 単純に破棄/無視すれば良いものもある。メールからのアクションが必要な場合は問い合わせにより無効化できるとさらに良い
- ログイン状態での履歴管理、誘導が必要なケースもありそう
- "別人であること" を検証するための本人確認情報の提供が必要なフローには、新しめの技術や考え方の導入余地がありそう
- 通知、そこからの問い合わせ時も、フィッシングには気をつけた方が良さそう。
良いお年を！ではまた！
Discussion